Keybase: Mostly Painless Public Encryption

Public encryption is great. It is a mature technology an an industry standard. The problem is, no one is actually using it. Or rather, whenever it is used, it is abstracted away, and hidden behind layers of misdirection. Why? Because it’s annoying.

Yes, you heard it right. It’s not hard. There is nothing inherently hard about generating private and public key pairs. There is also nothing inherently difficult about managing them. It’s just annoying because the tools we have aren’t all that great, the integration with mail clients has been shitty for years and actually keeping track of your keys is a pain in the ass.

I recently looked at my key-chain and realized that it contained about a dozen public keys that I have not used or even thought about in years. Were any of these keys still valid? Were the emails they were keyed to still in service? There was no way for me to know any of it. In theory, if you generate a new key pair, you can revoke the old key and push that information to the key servers. In practice however, private keys get lost, or worse – you forget their pass phrases, leaving you no means to generate the revocation certs. I know that there are probably five or six different public keys floating out there with my name attached to them – and I have managed to lose or get locked out of each and every one of them.

Key servers, as useful as they might be, are not an authoritative. Firstly, they are polluted with thousands of defunct keys that may never be revoked, because they were generated by teenagers going though their 1337 h4x0r stage, and then promptly forgotten few years later. Secondly, anyone can publish a public key. The only identifying information that is attached to a public key is a name and an email – the two things everyone knows about you already, and only one of these is semi-unique. Emails is slowly fading away as a unique identifier anyway.

There is really no easy way to verify validity of a public key found on a key-server, other than asking the alleged owner directly. And if you have to ask someone about the key, they might as well just send it to you right there and then, making key servers completely superfluous and unnecessary.

Wouldn’t it be awesome, if there was a modern web service or database, where you could sign up, register your public key, and have it tied to your online identities that are actually relevant: like your twitter, github and your personal blog for example? Well, someone just made exactly that and named it keybase.io.

Keybase.io

If you follow me on Twitter you have probably seen me tweetign up a storm about it in the past few weeks. It was mostly praise, because I really like the service. It’s not perfect, but I really think it is a step in the right direction. That direction being: making public crypto more accessible, and less of a pain in the ass to use. Keybase aims to bring modern UX to the land of cryptography.

I know, I know – it sounds like sacrilege. For decades the mantra of security community has been: good Crypto is hard to develop and therefore it should be hard to use. So a lot of people hate on Keybase just for attempting to make it a bit less painful and, dare I say it, fun.

Let’s say you want to confidentially tell that dude who writes Terminally Incoherent that he is so wrong he should immediately kill himself (or as we know it in our industry “the standard tech community greeting” – this is usually how developers say hello to each other) , but you do not have his public key… Nor do you know his stupid name, or his stupid email – you only know his stupid URL where he posts all the wrong things, actively giving you cancer, and ruining your community. What do you do? You go to Keybase and type in “terminally” in the search box:

Keybase makes finding public keys painless and easy.

Bam! My name comes right up. You can click on it, and you will be taken to a neat profile page that lists, among other things my full name, twitter handle, github account, any web sites I cared to register and also my public key’s fingerprint:

Keybase Profile

You might ask, why should you choose to trust Keybase to be the authoritative public key directory. After all, it is just a random project threw together by some nerds, and they have nice modern layout and hand drawn artwork on their site meaning they are probably some silly hipster designers and not Real Developers™. Well, you shouldn’t. Keybase doesn’t want to be a key authority – they want to be a public directory. Which is why they require you to prove the ownership of the accounts and websites you register with it by posting or uploading a signed payload message. That message is to remain on our account and/or server and be publicly accessible. This means that if you ever lose control or ownership of one of the sites and services, you can remove it from Keybase, and if you get locked out of Keybase account you can just delete all your proofs. An account without working proofs – or worse, with proofs that are marked as invalid will then set off red flags for anyone searching the database.

But it does more than that. It actually makes sending encrypted messages dumb easy. If you want to send me encrypted hate mail (please, please, please do not send me hate mail) you don’t need a GPG client installed. You don’t need to generate a key pair. In fact, you don’t need to know anything about public encryption. All you need to know is that there is a big “encrypt” button on my Keybase profile. You can click on it, type our insults into the box, hit a button and you will get a nice, pretty block of ciphertext you can now paste into email, comment box, or print out on a piece of paper, photograph it on a wooden table, and fax me the photograph.

Keybase makes generation of encrypted messages super easy.

I’m pretty sure anyone can do this. Decrypting the message might be a bit less complicated. You can do it the hard way, using your GPG client of choice. Keybase does provide a really neat command line client which, by my estimation is about 615% more intuitive than the standard gnu gpg client which it wraps around, so you can use that. And, if you are not too paranoid, you can choose to trust Keybase with a copy of your private key (they promise they’ll encrypt it real hard) so that you can decrypt stuff in your browser.

That last part is a bit risky. If Keybase is ever compromised, or has to comply with some governmental coercion then your private key is forfeit. You can mitigate some of the risk by choosing a strong pass phrase which Keybase does dot store in their database, which is a pretty good practice. So if you are willing to put the safety of your encrypted communication in their hands, you do have an option to make things super intuitive and easy. If you choose not to trust them, everything still works very smoothly: you just need to drop down to the command line to decrypt or sign messages. Encryption remains painless and web based though.

While this might seem like an extended infomercial, it isn’t because Keybase is still in closed beta. But, I do have invitations and I can hook you up. Basically my whole reason of posting this blog is to find takers for these invites that are burning a hole in my virtual pocket, and to gain new followers. Right now I only follow few people and have even fewer people following me so I feel inadequate. My e-ego needs stroking guys, so get on Keybase and fucking follow me right now. And let me know if you need an invite.

I’m sure as hell not giving them my private key, but the rest of the stuff sounds good. Additionally, I would pay money for an email client that supports GPG and works seamlessly with Gmail (including interacting with labels and filters).

GPGTools works okay with the Mail app… But the Mail App, just like all email clients in existence doesn’t really understand labels.

I think part of this has to do with the fact that the most reliable way to interact with Gmail is via IMAP, and when you do that, Google pretends that the labels are folders. A true integration with labels and filters would require you to go through the Gmail API and I’m guessing that’s somewhat crippled too, because Google prefers people to use their webmails so they can get eyeballs on adds.

the problem with keybase.io: i have to trust keybase.io (or anybody in between me and Keybase) that they show me the right pub-keys.
with control over this server i could:

Show Alice her correct Key, but show Bob a wrong one.
So when Bob sends a encrypted Message to Alice, he would use the wrong key, what would mean interceptable communication. Eve could even re-encrypt the message with the right key and forward it to Alice.

So if i want to be perfectly sure? I would need to verify your key over another medium (as in: not this internet-connection that could be bugged).
If i do this, then keybase has no longer any worth. If i don’t, then i must rely on keybase and my connection beeing secure.

@ Wesley:
well i was speaking of encrypting it _for_ alice to decrypt with alice’s private key. For that you only need the public key. Of course, you couldn’t sign as bob.

the matter of giving users a way to upload private keys is just another thing…
ok, it “should” be encrypted and somewhat secure (if the key isn’t “1234”). But really?

The last big problem i have with keybase is that the software by them needs node.js and should be installed via npm. Things you plainly will never see on computers i controll.
that wouldn’t be a problem if they had small bash-scripts for everything (they have for some things like registration and signing auth-messages for twitter/github/whatever).
but they lack this for “tracking” (thats signing keys afaik?)

…and keybase.io is no real keyserver that i could use with existing software. But that’s just a missing feature.

Yeah, the thing could potentially be abused quite a bit. It’s interesting how increasing UX tends to decrease the actual security of a system by generating use cases where system would be easy to abuse, or by introducing a third party with implied trust. :(

But, it’s the most interesting thing I have seen being done with public encryption as of late. So as long as we are cautious and keep in mind the risks, I have no problem supporting what they are doing. :)

Oh, and NodeJS is already installed most machines I own because I use Grunt, Bower and Yeoman a lot. So I actually did not think of that as a downside. Ruby, Python and Node are usually the three things I install immediately upon booting up a new machine. :)

If I got a message from Bob that was plaintext after sending him an encrypted message, I would be suspicous as hell. That doesn’t stop keybase from reading my message, but it stops a total man in the middle attack.

Installation isn’t a problem from me, being on Arch Linux it’s in the AUR. That means that there’s a nice little bash script that will make a package of it with all the depends of everything taken care of :)

I think that the scenario mentioned by @ Dr. Azrael Tod goes as follows:

– Alice signs up for Keybase and uploads her public key alice.asc
– NSA (or whoever) coerves Keybase to secretly generates a fake key fake.asc based on their private key
– When when someone goes to check Alice’s profile they see alice.asc
– When Bob logs in, and check Alice’s profile Kebyase is told to serve him fake.asc instead
– Bob encrypts a secret message to Alice using fake.asc and emails it to Alice
– NSA intercepts the email before it reaches Alice and decrypts it.
– They read the message and immediately dispatch Party Van to fetch Bob
– They grab alice.asc from Keybase, re-encrypt the message, and send it to Alice as if nothing happened
– Alice is none-the-wiser and Bob is in secret off-shore prison

The scenario of course requires the third party to be able to compromise both Keybase and the medium Bob and Alice choose to exchange information (so presumably Gmail) which is not that far fetched given Prism and all.

To sign, yes. To encrypt no. You can encrypt a message without signing it. So if Bob is smart, he will sign all this messages so that Alice can tell if there is any tampering going on. The NSA (or enemy spies or whoever) could still read Bob’s initial message, and if if he was whistle-blowing or spying or whatever, he could still get v& though.

Looking more at their website, giving out a different public key wouldn’t work. When you verify, you publish a signed message, thus if keybase.io sent a diffrent one, the client would detect that and reject the key.

Your email address will not be published. Required fields are marked *

Comment

Name *

Email *

Website

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page.Click here for instructions on how to enable JavaScript in your browser.