Logical Reality Design: Web Design and Software Development

Thoughts on

March 18, 2014

Over the last couple of weeks, a startup called has been making the rounds, promising a much simpler take on PGP. A more humane interface on GnuPG, visual design by a renowned artist, even a web interface for your crypto. Fantastic, right?

Yeah, I can't get on board. And I really hope you won't either.

Admittedly, OpenPGP needs an interface that doesn't take a week of research to understand. Starting with "What's OpenPGP? Is that like the PGP 6.0? And GPG is different, right?" And then using any of the existing tools requires that you really understand the whole protocol, maybe back to the basic maths underneath. So where probably everyone in a mature digital society should be using cryptographic tools, the reality is that only the particularly paranoid (that is, international journalists and cypherpunks) really do.

So there's definitely an opportunity for everyone to benefit. And Keybase is capitalizing on that opportunity. If you don't know what I'm talking about, the site is here.

Here's the problems I see with Keybase:

You Don't Roll Your Own - And You Don't Have To

First, they're reinventing well known parts of OpenPGP. A public directory of publicly auditable keys? Allow me to introduce PKS (an example server) - a decentralized system for distributing public keys. Associating your key with a public identity? For email addresses (oh, wait, those are also globally unique user ids...), we match up user ids on the key. For other accounts, there's a system called "annotations." This is all built into PGP, and people, paranoid, technical people have been using it for decades.

And that's not a "well, they got there first" sour grapes complaint. There's a principle in computer security that you don't invent your own crypto. Which is exactly what Keybase is doing. They're using GnuPG under the hood, certainly, but they're distributing keys and associating them with public identities over a brand new, unreviewed protocol. That's troubling.

So it should be possible to write an all OpenPGP implementation that does everything that Keybase does on the command line ... without the central Keybase service.

That's Not Authentication

But the next problem is: should we do that? Keybase's pitch is that rather than use a web of trust (which is a tricky concept) let's pair up our public keys with public identities so that we can see that @yourfriendontwitter is also the owner of this particular public key. That's a cool idea - now we can skip that whole perl-mediated key-signing geekfest and use Web 2.0 tech to identify one another, right?

The limits on that identification are two-fold: First, the certainty with which we know that e.g. tweets are sent by their purported senders is limited by the security of Twitter. (I think there's heavy irony to how much the Keybase "Verifying myself" toots look like "you've been hacked" spam.) Second, all we are actually learning about the holder of the key is that they can also tweet as @yourfriendontwitter - not that they're actually your friend on Twitter, if you see what I mean.

I think there's a reason that the Keybase example pages use as examples messages about meeting up for drinks - you probably shouldn't trust a key you identified via Twitter about matters more weighty than you'd themselves discuss on Twitter.

Ultimately, I don't think you can bootstrap a secure system on the foundation of insecure systems. And the Keybase foundations right now are Twitter, Github, and your personal site.

By contrast, the goal with PGP is that you can extend the human trust of meeting someone face-to-face to communications on line. When someone who's key you've actually signed as a result of them presenting it to you in person signs an email with it later, you can trust that email as if they'd said those words to you in person. Otherwise, it could be anyone.

If They're Not Doing This Right...

Beyond that comes my biggest concern. The keybase founders (and I think it's pretty irrelevant that they're coming from OkCupid) are asking you to centralize your public key into their closed source service rather than use the existing infrastructure. Even better, they're suggesting that you do your cryptography in Javascript in the browser. And they admit that people should be suspicious of that, without addressing that suspicion. They even suggest that you should upload your private key to their servers. (Just for the record, you should never put your private key into anyone else's possession.) They claim that your key will be secure - because it will be secured with their own special blend of encryptions. But remember what we said about rolling their own crypto? There's no way to avoid the fact that triplesec is exactly that.

As an analogy, if you went to a new bank, and they started talking about "vig" instead of APR, or the locksmith who came to your house was "Bondo-ed," or your doctor told you medical science has no way of knowing where the heart is you'd start to wonder if you should do business we them, right? That's how the Keybase pitch sounds to me.

The best light I can see that in is that they're well meaning, but simply unqualified to design and run a cryptographic system. I imagine two undergrads starting a bank in their dorm room. But I worry that this is a social engineering attack on a grand scale - that they know exactly what they're doing: they're using a slick interface to draw in an initial group of tastemakers, until they have the Facebook of online security (with all the connotations of "having to be on Facebook"). Meanwhile, they're collect key pairs and subvert the meaning of authenticating a public key to the point where they can have severe impact on secure communications down the line.

Even if the founders well meaning, there's always the possibility that they make an exit, and the next owner of Keybase is evil. Imagine your personal communications being read by your least favorite corporate or governmental entity. Wasn't that exactly why we were using PGP in the first place?

Where do we go from here? I think Keybase does have a point: The user experience of public key cryptography is abominable.

It's a tricky subject though, because slick GUIs are really difficult for the any one user to verify that it's doing what it says it's doing and nothing more (like uploading your key somewhere...) But the command line has gotten a lot less scary to a lot more people, thanks to a raft of powerful web tools. In a related move, command line tools have gotten much more friendly than they were back when gpg was written.

So I'm proposing a set of curated shell scripts that wrap gpg to do a small set of common tasks. Ideally, they should cover the most useful subset of gpg operations, and be simple enough that anyone interested should be able to review them and satisfy themselves to their innocuity.

I need help though - I only use one platform for my computing, and I'd want to be sure that the scripts ran as close to everywhere as possible. Also, I have a bad habit of using words like "innocuity," so I could definitely use help with the documentation.

Update I've actually started the set of shell scripts. There's a public repository here for the interested. I would love to see contributions. (N.b. the code is public domain.)

  1. Matěj Cepl Said,

    Nobody still explained me what’s so terribly wrong with
    Also, there is always a possibility that those two hackers are actually not sophomores, but working out of their offices in Ft. Mead, Md.

  2. Judson Said,

    Enigmail is important inasmuch as it makes GPG easy to use with email, which is a related, but different concern.

    I’m not aware of any attacks on Enigmail, although I don’t use it so I could have overlooked something.

    Regardless, the promise and the goal of stong, public encryption is that anyone can be secure, even from the folks at Ft. Mead.

  3. Daniel Serodio Said,

    Very interesting post, these are legitimate concerns, I hope they respond to it. The idea of uploading your private key is indeed chilling.

  4. Zed B. Said,

    I’ve used gpg. And I agree wrapping the interface would help. I also attempted to sign up for after seeing a few people on Twitter ‘identify’ themselves with it. So far no word back from They seem pretty exclusive, which certainly smells more like salesmanship than security to me.

    Sign me up to help curate some shell scripts and write documentation.

  5. George Said,

    I can tell you haven’t used the service and are basing your assumptions on what you perceive the service to be rather than what it is.

    They’re not rewriting crypto. The crypto hasn’t changed. It’s still GNU Privacy Guard under the surface. This includes encryption, decryption, and KEY MANAGEMENT.

    They’re simply providing a directory. For example, I may not know somebody’s Email address because I mainly communicate with them via Twitter or GitHub. Now I can send them an encrypted message by searching the Keybase Directory.

    And that’s all it is — a directory. Sure, there’s JavaScript crypto to make it more user friendly, but nothing forces you to use it. If you’re comfortable with the command-line and the switches for GPG, go right ahead and use that. If you’re not, there’s a keybase command-line wrapper for GPG that makes several tasks all the more easier.

    But you’re still using GNU Privacy Guard.

    I don’t particularly like the fact that Keybase wants me to upload my Private Key, but it’s optional, and I haven’t. I don’t trust JavaScript crypto. Especially for Key Management. Maybe if they come out with a signed Browser Plugin I might reconsider. Maybe.

    Oh, and all those new keys created by Keybase? They’re being pushed up to those same public key servers that you talk about at the start of your post.

  6. Erik Doernenburg Said,

    When I saw keybase I was torn. On the one hand I share many of your concerns and I find it objectionable that they even provide a feature to upload your private key. On the other hand I think it does help in one specific niche: Let’s say you do open source work, you’ve got your email address published, and now someone wants to send you an encrypted mail. The sender could go to the standard servers and download your key, but in that case would have no way to verify it’s actually your key. With keybase they get a proof that that key is linked to the Github account that they are aware of.

    It’s still not clear whether even in this scenario keybase makes sense: What is the likelihood that an attacker is determined enough to place a key with my address on the public servers and successfully plays man-in-the-middle on all incoming mail? Is that more likely than being compromised…? Also, if we feel we can bootstrap off of Github, why not publish a gist with your fingerprint…?

    By they way, I’ve come to dislike signing PGP keys; it doesn’t scale and you’re leaking — actually publishing — valuable information, namely the social graph of the holders of the keys. This made me interested in alternative ways to verify key authenticity.

  7. spellnazi Said,

    s/their/there/ in the second paragraph of “You Don’t Roll Your Own – And You Don’t Have To”

  8. Andrew from Canada Said,

    Thanks for this, well written. But I’ll still probably get an account to play with the technology. Perhaps if their service was open source and publicly funded, free, etc?

  9. edwin Said,

    Easy integration SSH keys and OpenPGP would be a good start. AFAIK the next version of GnuPG should make it easier to have SSH subkeys.

  10. Judson Said,


  11. Judson Said,

    Subkeys in GPG for SSH would be interesting. The most current version of OpenSSH also allows for using certificates for server and user authentication – although, as far as I know, you have to distribute user revocation lists manually.

    There’s nothing that stops you from attaching an SSH pubkey to an OpenPGP key as an annotation, though.

  12. Judson Said,

    Even if the service was open source, I’d be leery. Fundamentally, anyone who suggests that I should hand over my private key – in any form – loses my trust completely. And there’s nothing new here apart from that.

    My recommendation: install gnupg, and play around with that technology.

  13. Judson Said,

    Keep in mind that there does exist a completely different way to verify key identity – it’s just usually used in the PGP space: central (or “certificate”) authority.

    On the other hand, one of the nice things about the OpenPGP model is that it’s very flexible. There’s no reason that a group of PGP users couldn’t anoint a central authority to sign keys for them. They wouldn’t have to publish their signatures on the authoritative signature, and the authority could even delegate signing powers. The authority key wouldn’t represent a person, and wouldn’t ever be used for anything else. It could be done. Of course, the authority key would become, over time, a very valuable target. I certainly wouldn’t undertake to become a general trust authority in any case – I couldn’t bear the responsibility.

    As far as leaking information goes: using any centralized system, including and especially PKS, leaks information not just about which keys know who, but even information about when certain documents were received. You could manage keys entirely via email, and rely on a pure web of trust, but that hasn’t gotten us very far.

    The other alternative would be to set up some sort of peer-to-peer gossip system, but that would be quite and undertaking.

  14. Judson Said,

    I spent a lot of time with Keybase and it’s documentation before I even considered writing this post.

    Using GPG isn’t itself a magic bullet. It provides a set of amazing, powerful assurances, but they’re all predicated on certain assumptions. I believe that Keybase subverts a number of those assumptions, and I think that’s dangerous. Namely, it encourages the idea that personal identity authentication via online identity is tenable. Which it may be, for some purposes.

    And if you aren’t comfortable with GPG and command line switches, you’re way less likely to get that Javascript crypto and uploading your keys is a bad idea.

    On the other hand, I didn’t know (it’s nowhere in the docs I was reading) that Keybase uploads keys to PKS. That’s decent of them.

  15. Daniel Kahn Gillmor Said,

    you can already use an authentication-capable OpenPGP subkey as your SSH key. The monkeysphere project (which i am a contributor to) is designed to streamline that process. It also allows for you to identify SSH servers via the OpenPGP network of identity certifications.

    So if you run a machine foo.example, you can certify its key and publish it to the public keyservers, and when you give your friend Alice a shell account on it, her monkeysphere-enabled ssh client can tell her that “ssh://foo.example was certified by your friend Judson”

    It seems to me like keybas would have done better to just recommend a standard format for people to identify themselves by their github or twitter handles in the User ID, and then encourage people to publish their public keys via a github gist or their fingerprints via a tweet or in their twitter user profile. (of course, these github- and twitter-attested proofs are still only as secure as your actual control over your twitter account or your github account, as you mentioned above — so third-party certification would still be useful)

    This would let people continue to use the public keyservers, it would make control over the github and twitter identities first-class citizens within the OpenPGP user ID space, and it would let keybase-users interoperate with non-keybase users more simply.

    I fully agree with the need for a UI overhaul, fwiw, and i’m glad that they’re pushing on that. i just don’t see the merit of combining that with twitter and github, or with private key storage on someone else’s servers.

  16. Judson Said,

    I’ve followed the monkeysphere project with some interest for a while now. Thanks for the quick primer!

    I think that to make it a business, they have to have a value proposition of some kind, and centralizing a registry is the start of that.

    Regarding tying Twitter and Github (or any other public identity + content platform), I have a sketch of something in the github repo I just put up. Adding tools for it to the set of scripts would be easy (affirm/verify) but I’m still concerned about the underlying assumption that internet identities are valid bootstraps. Maybe if they were tied to a “casual/marginal” trust signature, and there were warnings on the label?

  17. Kevin Said,

    In my humble opinion this post is mostly FUD with a small sprinkling of legitimate concerns. You have fundamentally misunderstood several aspects of the platform. I repeat what a guy speculated above: I can tell you probably didn’t even bother to try it before writing this.

  18. Judson Said,

    I’d invite some substantive comment, then. What aspects do you believe I’ve misunderstood?

Add A Comment