I’ve been fooling around with this for the last couple of days; you can find me at keybase.io/timbray. I think it might be pointing a useful way forward on private-by-default communication and, for what it does, it gets a lot of things right.

The problem · We’d like to be confident that the messages we send across the net — email, chat, SMS, whatever — are secure. When we say “secure” we mean some combination of “nobody can read them but the person who’s supposed to” and “the person reading them can be sure who sent them.”

In principle, this should be easy because of Public-key cryptography, which has been around for a while, is reliable enough to power basically 100% of the financial transactions that cross the net, and for which there’s excellent open-source software that anyone can use for free.

Getting crypto in place for mail and other messages has been tough, for a few reasons. First, how do you find someone else’s key reliably, where by “reliably” I mean not just find it, but believe that it’s really theirs?

Second, most messages these days live in the cloud (Gmail, Facebook, Twitter, whatever) and the cloud owners like to have them unencrypted to help them advertise better. So they’re probably not really all that motivated to help make messages secure.

Now, I know that secure email is possible, and that https connections to Facebook and Google and Hotmail are helpful, but right now today, most messaging isn’t very secure.

Keybase · Keybase.io does a few simple things:

  • Keeps a directory of keys that you can look up by a simple name. Since I’m an early adopter I got “timbray”, but in practice your email address would work fine.

  • Lets you prove that the owner of a key also owns a particular Twitter handle and Github account. In practice, since I tend to believe that the people I know are associated with certain Twitter/Github accounts, I’m inclined to believe that the keys really belong to them.

  • Lets you encrypt messages so they can only be read by one particular person, lets you sign them to prove that they could only have come from you, and the inverse; decrypt and signature-check.

  • Does all this in a simple web page that’s easy to use, or in a geek-friendly command-line interface.

So, the idea is that if there’s a message you want to send, and you want it to be a secret, you visit keybase.io, paste your text in, encrypt it for the person you’re sending it to, sign it, and then copy/paste it into an email or chat or Facebook message or whatever. The person at the other end copy/pastes it into keybase.io and reverses the process and hey-presto, you’ve just practiced secure communication!

Here are a couple of screenshots showing how I’d encrypt a message to my wife, who’s known as laurendw on Keybase.

Encrypting a message in Keybase
· · ·
An encrypted message in Keybase

In case you were wondering, yes I did change the length of my passphrase before I took the screenshot.

Yeah, it would be better if this were already built into every messaging program that everyone uses, and you got it by pressing a button; or better still, if everything were always encrypted.

But in the interim, while this may be a little klunky, it’s awfully simple and easy to understand; and it works with anything that can be used to send a chunk of text from anywhere to anywhere. So I’m pretty impressed.

In greater depth · Here are a few more technical reasons why I like what I see at Keybase; probably not accessible to non-geeks, sorry.

  • There’s the ability to “track” another user, which does all the crypto checking and signs the result, so in future you can do a quick check whether anything’s changed. This speeds things up and removes a few threat models.

  • There’s also a command-line client, which should be very comforting for the paranoid. Perhaps the most worrying threat model is that someone shows up at Keybase’s office and, using either malicious technology, a National Security letter, or white-hot thumbscrews, arranges to compromise their software; the first time you type your passphrase into that compromised software, your security is a smoking cavity. But if you use the command-line client, the adversary has to compromise your own computer to get at you.

  • The actual cryptography software is all GPG and Scrypt; what Keybase offers is pipefitting and a directory and some utilities. So the crypto part ought to be believably secure.

  • It’s all open-source and there on Github. Very comforting.

  • There’s also a REST API, which at first glance looks very sensible to me. I’m fighting the temptation to start building an Android client. Such a thing could be pretty useful in combination with Android’s Intent-based sharing architecture; you could post an intent filter to receive pretty well any message, encrypt it, and then fire off another intent and let the person holding the phone email it or Facebook it or whatever.

  • In principle, once the API is locked down, anyone could implement a Keybase-style directory — for example to serve a particular community of trust — and messaging tools could be taught how to work with any old instance.

  • The people who built this are the ones who built OkCupid, which suggests that their technical chops may well be up to the task.

A worry · You can also store your private key, encrypted with your passphrase, in the Keybase directory. This makes certain things easier and quicker, but it makes that one particular threat model, where a bad person compromises the software, even scarier, because they have your private key the first time you type your passphrase into the compromised software. I’m going to try running without the stored private key (which it seems requires deleting my current key and refreshing it); I’ll report back.

Trade-offs · [Update:] Yep, if you delete your stored private key, it means you have to use the command-line client rather than the web interface. Which is way less civilian-friendly. This is a very, very interesting trade-off. I’m thinking Keybase is going to have to publish something about their legal and political defensive measures.

[Another update:] If you’re using the command-line keybase tool on OS X, you can store your passphrase in the Mac keychain, so any commands that need your passphrase Just Work. So for people who are handy with the command line, it’s actually more convenient then the Web form, which requires you to type in the passphrase, or paste it from your password manager.


Comment feed for ongoing:Comments feed

From: nick (Mar 19 2014, at 18:42)

While it may look good, unfortunately it's not such a great idea. It effectively relies on Twitter for authentication, so you only need to get access to someone's Twitter account to replace their key. Also JS crypto...

For some counter arguments:


I don't think that 'curated shell scripts that wrap gpg' is the solution either though.


From: npd (Mar 19 2014, at 21:12)

It might be misleading to say that "you only need to get access to someone's Twitter account to replace their key" -- Keybase still generates GPG keys with fingerprints, and if you "track" a user, it stores a signature of a particular key. When I "track" a user, what I need to be confident of is that the user's Twitter and Github accounts weren't simultaneously hacked at the point when this key was uploaded to Keybase and that the user hadn't yet had a chance to notice that both of their accounts were hacked and messages uploaded on their behalf. If a fingerprint is changed after you "track" a user, the Keybase client will notify you, so you only need to be confident at that moment.

That's not to say that there might still be limitations to the security or usability of Keybase (they seem to be pretty direct about the limitations regarding JS crypto, for example), but just that authentication by publishing proofs isn't just the same as 'if your Twitter account gets hacked, your key is silently replaceable'.


From: Gavin B. (Mar 20 2014, at 00:04)


ha internet domain .io -

does that mean it's not run from the US?


From: Evan Jones (Mar 20 2014, at 05:49)

Cloud providers don't store unencrypted data just so that they can advertise to you, but also because it is significantly easier to implement, and allows them to easily add additional features.

For example: imagine we launch a basic secure email service, where everything is encrypted end-to-end. Now, 6 months after we launch, we want users to have the ability to search their email from their phones. There are techniques for full-text search over encrypted data, but they require the *client* to index the data. So now users on their phone are going to need to download all their mail, index it, and upload that to the server. This is much more complicated than just pushing out a server-side update. This has been our experience at Mitro (https://www.mitro.co/ ), where we manage shared accounts using client-side crypto: every update must be carefully orchestrated so clients upgrade their own data

I still think more things should be using client-side encryption. At the very worst, it means that attackers need to use some sort of "online" attack, where they install malicious software in the server, to get your data. Today, as soon as an attacker gets access to your database its game over. This at least increases the difficulty of obtaining data, and ideally makes it more detectible. This seems like a win, although it certainly isn't the holy grail of "its impossible to get your data" that we want.


From: Matěj Cepl (Mar 20 2014, at 07:18)

> Keybase.io has internet domain .io - does that mean it's not run from the US?

I doubt it, it looks like being run on AWS:

matej@wycliff: ~$ whois keybase.io

Domain : keybase.io

Status : Live

Expiry : 2014-09-06

NS 1 : ns-1016.awsdns-63.net

NS 2 : ns-1722.awsdns-23.co.uk

NS 3 : ns-1095.awsdns-08.org

NS 4 : ns-337.awsdns-42.com

Owner : Krohn, Maxwell

Owner : CrashMix.org

Owner : 902 Broadway, 4th Floor

Owner : New York

Owner : NY

Owner : United States

matej@wycliff: ~$


From: Aaron Huslage (Mar 20 2014, at 09:27)

I think you might have overlooked a large infrastructure of key servers that already exists. Maybe intentionally?

The SKS keyservers (https://sks-keyservers.net/) are a globally distributed store of public keys. They provide history, multiple identities, etc already. It doesn't solve the problem of private key storage, but that is a problem that (arguably) shouldn't be solved outside of personal preference anyway.


From: Brandon (Mar 20 2014, at 09:27)

"It’s all open-source and there on Github. Very com­fort­ing."

At the risk of sounding too paranoid - which gets harder by the day - this doesn't comfort me.

Prove that the Github source is what's actually running on their servers. Doesn't prevent the thumbscrews attack and modifying their deployment.


From: Nelson (Mar 20 2014, at 10:58)

I think Keybase is interesting. The comments so far have missed one crucial point: existing public key systems are a complete failure for email communication. PGP/GPG in email is a failure. The keyservers are a failure. They do not work for ordinary people, they are too complicated.

PGP has had literally 23 years to try to provide email privacy and it's failed, largely because of terrible UI and integration with communications tools. It's exciting to see Keybase try something new.


From: Simon Daby (Mar 20 2014, at 11:13)

FWIW, it integrates the gnome keychain on ubuntu also.


From: nick (Mar 20 2014, at 11:20)

@npd: Yes, 'replace key' is wrong, sorry. But if I have access to your Twitter account (even briefly), I could register a key in your name. Then you'd have to go and convince everybody that it's actually, really you and here's your *real* key. It's being done with keyservers as well, targeting Tor developers. Ultimately, the WOT doesn't really scale and no amount of pretty UIs is going to change this.


From: Brent Rockwood (Mar 20 2014, at 12:11)

According to the website, even when using the web site, all crypto occurs in JS, in the browser. In theory, that could be validated by a sufficiently clever user at runtime. Unless I'm missing something then, even if thumbscrews are deployed, as long as your passphrase isn't broken you should be good to go.


From: orcmid (Mar 24 2014, at 14:55)

I am also wary of giving keybase my private key, however encrypted.

Tim, did you arrange a distinct key pair for use with keybase as a precaution or did you just happen to set up that way when trying out the service?

I would think having a single set of persona-associated (whether or not -identifying) identifiers is desirable.

Hmm, when you give them a public-key certificate, you obviously need to sign something with the corresponding private key for them to verify association with whoever has control of the keybase account. I'll be interested in seeing what that ceremony is when I get through the queue for new accounts.


author · Dad · software · colophon · rights

March 19, 2014
· Technology (77 fragments)
· · Security (33 more)

By .

I am an employee
of Amazon.com, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.