A couple of years ago you probably heard about this thing called Keybase launching with a private beta, and it purported itself to be a new form of public key encryption for the masses, blah blah blah, whatever.. but what's this thing good for, exactly? I mean, it was pretty easy to request an invite from the service and either never get one, or eventually receive an e-mail and promptly forget about it. I've been using it off and on for a while, and I recently sat down to really mess around with it and get a sense for how it's changed and what it can do. Plus, there's a fair amount of outdated or bad information floating around out there, and I wanted to do my part to set the record straight.
I'm not going to spend time explaining public key crypto because I wrote a pretty decent introduction to it that I give at cryptoparties. Take a look at the PDF of the presentation; I tried to make it as painless as I could. I want to keep this post focused on Keybase.
With public key encryption systems like GnuPG there is the fundamental problem of confirming that a given public key belongs to the person the key's metadata says it does, because anybody can generate a key and attach a couple of e-mail addresses to it before publishing it. There seems to be no shortage of attempts out there. Can you be sure that this key really belongs to me even though you're reading my blog? Ultimately, it depends on how paranoid you are. If you know me, downloading the file, importing it into your keyring, and verifying the list of signatures on it is a pretty straightforward operation. If that wasn't sufficient I could give you a copy of my pubkey if we meet at a keysigning party, but if you asked to see my ID I certainly don't have a driver's license or passport made out to "Doctor, The" with a birthdate of 15 February 5023ao (After Omega). This is both good and bad, because GnuPG and PGP have the property that digital signatures can be used to build reputations for pseudonyms. In other words, I can write and digitally sign a bunch of stuff under my handle, publish my public key, and that even if you don't know exactly who I am the signatures all came from the same person - the person that has the corresponding private key. Over time, that handle builds a reputation.
The reputation network behind PGP public keys is one of the things that helps build the an identity. The people I know that I work and hack with all know me offline are willing to vouch for me by signing my public key. The more people who sign my public key, the stronger the reputation - it implies that all of these people have done at least a little bit of homework toward verifying that me-the-person actually controls and protects me-the-PGP key. Keybase accomplishes much the same task, but using a different set of techniques.
When you sign up for a Keybase account, it'll ask you to generate a public key if you don't have one already (or want to generate a new one); it'll also give you the option of uploading a pre-existing public key. Keybase will also give you the option to upload the private key if you have one, but you are by no means required to do so. I certainly didn't (not that I could if I wanted to) to their servers, and that remains the case today. Keybase gives you the option of digitally signing and uploading to various places what amount to personal affadavits that you control those resources. For example, you can use the Keybase software to generate, sign, and post to Twitter a public statement that you control that Twitter account. You can do the same thing with Github, Reddit, Facebook, Coinbase, and a slowly growing list of other websites and social networks. All of these things provide evidence that your identity, and its associated public key, control those accounts. It also makes it much easier for people who may want to add you to their follow-list to decide whether or not to do so. Keybase makes it very easy to look at those proofs of identity and decide for yourself if you want to follow that person.
To store all of this on the back end in such a way that it would be very, very difficult to tamper with (though there's nothing stopping anyone from building their own setup using the Keybase API as the data source for a mirror) Keybase uses a data structure called a Merkle Tree to immutably store records. I'll spare you a complete rundown of how Merkle Trees work but for the purposes of our discussion, it's a tree of values, where the leaves (the values at the edge) are the actual data (keys, signatures, stuff like that) and the other values are cryptographic hashes of that data, and hashes of neighboring pairs of hashes, and so forth up until you get to the root of the tree. Wikipedia has an excellent diagram of a fairly simple Merkle Tree. The reason this is resistant to tampering and misadventure is because all of the hashes can be re-computed at any time to verify their integrity. If even one calculation doesn't check out, all of the hashes beyond the one that broke are also broken. While you can't use it to repair the damage you do know at what point everything went pear-shaped. Do you need to know this to use Keybase? No. My explanation is simply to explain how the data is secured. The Keybase application does all of the heavy lifting for you. In point of fact, Keybase makes it very easy to verify someone by doing much of the legwork on your behalf:
[drwho@windbringer tmp]$ keybase id drwho ▶ INFO Identifying drwho ✔ public key fingerprint: 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 ฿ bitcoin 1P6iJzNX7PqyY5LGK8U8UQhPxu3GZyj1rG ✔ "virtualadept" on reddit: https://www.reddit.com/r/KeybaseProofs/comments/2dknv0/my_keybase_proof_redditvirtualadept_keybasedrwho/ [cached 2017-02-26 15:47:03 PST] ...As one might reasonably expect, the Keybase application is perfectly capable of encrypting and decrypting data.
[drwho@windbringer tmp]$ keybase encrypt -i READ-ME-NOW.txt -o READ-ME-NOW.txt.encrypted drwho [drwho@windbringer tmp]$ keybase decrypt -i READ-ME-NOW.txt.encrypted -o decrypted_file.txt Message authored by drwhoWhenever you encrypt something to someone, the Keybase utility automatically encrypts it to you as well, so that there will always be at least one person that can access the data. It's also capable of digitally signing data to prove where it came from and help prevent tampering. The act of doing this also seems to encrypt the file to yourself at the same time:
[drwho@windbringer tmp]$ keybase sign -i READ-ME-NOW.txt -o READ-ME-NOW.txt.signed [drwho@windbringer tmp]$ ls -alF READ-ME-NOW.txt* -rw-r--r-- 1 drwho drwho 2954 Feb 26 15:15 READ-ME-NOW.txt -rw-r--r-- 1 drwho drwho 5181 Feb 26 15:15 READ-ME-NOW.txt.encrypted -rw-r--r-- 1 drwho drwho 4609 Feb 26 15:27 READ-ME-NOW.txt.signed [drwho@windbringer tmp]$ keybase verify -i READ-ME-NOW.txt.signed --no-output Signature verified. Signed by drwho (you). [drwho@windbringer tmp]$ head READ-ME-NOW.txt.signed BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5wcIkHbrzxW9v1 uy98es4e6...Under most (all, really) circumstances, re-using the same key for different things is considered a very bad idea. The thinking behind this is that you have to assume that a passive attacker is recording everything you send. All of the encrypted traffic is recorded in the hope that it can be cracked later. On a network big enough that people actually use it every day (like the Net) you can't avoid this; all you can do is accept it and trust that the crypto you use is strong enough to protect the details until they don't matter anymore. If that one key (a PGP key, let's say) gets compromised, all that encrypted traffic that was recorded can be decrypted.
But what's the story here?
As it turns out, one can install the Keybase software on multiple devices (computers for the moment, mobile apps are coming Real Soon Now(tm)) and associate each one with the same account. Each time you hook a device into your account it generates a unique set of crypto keys for that device which get signed with your PGP key to authenticate them (this happens when the Keybase utility asks you for your passphrase) and the public key part get published. So, let's say that somebody encrypts a message to you on Keybase. Let's also say that you have the Keybase application installed on your laptop, your desktop, and your work laptop, all associated with your Keybase account. Each of those machines has a unique set of keys, the public sides of which are all published. When that somebody encrypts a message to you@keybase, their copy of the Keybase application is actually encrypting it to you@laptop, you@desktop, and you@work laptop successively. Due to one of the nifty properties of public key encryption, you can decrypt that message on any of those machines using the Keybase application. The sender could also encrypt that message to multiple Keybase accounts, and any of those users on any of their registered devices could decrypt that message because all of the recipients' known public keys are used. As far as you're concerned you're working with people, but the Keybase app implicitly understands this to mean "every public key for every identity you reference." Let's transfer my demo encrypted file to Leandra and decrypt it there:
[drwho@leandra:() ~]$ keybase decrypt -i READ-ME-NOW.txt.encrypted -o decrypted_file.txt [drwho@leandra:() ~]$ ls -alF READ-ME-NOW.txt.encrypted decrypted_file.txt -rw-r--r-- 1 drwho drwho 5181 Feb 26 15:19 READ-ME-NOW.txt.encrypted -rw-r--r-- 1 drwho drwho 2954 Feb 26 15:20 decrypted_file.txtHold onto that notion, it'll come in handy later.
Earlier this year, Keybase added an instant messaging feature to their software. I've been playing around with it a little bit and it seems pretty solid. I could complain about the font size on very high resolution screens, but that's what Github tickets are for. At any rate, if you're used to using something like GChat or Slack's private messaging you'll find yourself already familiar with how it works. Keybase Chat lets you communicate securely with anybody in the Keybase network just by searching for them: Click the speech bubble to open the chat window, then click "New chat" at the top. Pick a social network to search; I recommend searching Keybase (the default option) first). When you find that person, click on "Start a chat." Thenceforth, that particular user will be in your chat roster for easy access. Additionally, chat sessions are encrypted end-to-end, which is to say that Alice's message to Bob is encrypted before it hits the network, and only gets decrypted when it reaches Bob's computer. The servers in the middle never have access to the private keys or the cleartext. You don't have to monkey around with new keys or anything like that, Keybase does it for you automatically. Additionally, Keybase Chat offers a security property called forward secrecy, which basically means that if the Keybase key for your device is ever compromised, it can't be used to decrypt any previous chat traffic. Keybase Chat is also available from the command line, but I haven't messed with it and it seems kind of clunky for the moment so I don't feel comfortable saying anything about it yet. Just stick with the desktop chat client for now.
There's one other feature that I want to talk about, and that is KBFS, which is basically a file sharing application built on top of Keybase. In a nutshell, it lets you set up at least one publically accessible folder on your public Keybase profile page that you can put pretty much anything you want into. You are under no obligation to use this if you use Keybase because it's a separate utility called kbfsfuse (for Linux, anyway) that doesn't start automatically. By way of illustration, here's mine. Also by way of illustration here's Chris Coyne's, who is one of the founders of Keybase. Everything you copy into that folder gets digitally signed automatically to help prevent tampering and provide authenticity (so don't put anything in there that could get you in trouble), and it's as easy to use as dragging and dropping a file. You also get a free private folder that only you can access for personal storage; everything you copy into this folder is encrypted automatically, and you're the only person who can access the files. Additionally, you can easily create any number of shared private folders that are limited to yourself and some other Keybase user. For example, say I wanted to create a shared folder with the aforementioned Chris Coyne:
[drwho@leandra:(9) ~]$ cd ~/keybase/private/drwho,chris [drwho@leandra:(9) drwho,chris]$ ls -alF total 0 [drwho@leandra:(9) drwho,chris]$ touch message.txt [drwho@leandra:(9) drwho,chris]$ ls -alF total 0 -rw------- 1 drwho root 0 Feb 26 17:19 message.txtThe act of changing to the directory /home/drwho/keybase/private/drwho,chris created the shared folder. No fancy keyboard gymnastics or asking Joshua if he'd like to play a game are necessary. I could, in theory, put whatever I wanted into that file, and if he ever checked the shared folder I created he'd see it there waiting for him. Unfortunately, I've only used the Linux version of KBFS; I don't have a Windows box or a Mac to try it on, so I can't speak to it.
There is one not-very-well documented thing about KBFS, and that is by default it tries to create all of its directories hanging off of the root partition of the drive, which implies that it has to be run as the local root user. This is bad. However, the Keybase applications do not need elevated privileges to run normally, and thankfully there is an undocumented way to set up the Keybase filesystem relative to your home directory:
- Create a directory called keybase/
- Start the Keybase file system: kbfsfuse keybase
You can do this inside of a GNU Screen or tmux session so it stays running after you log out; of course, the first thing you'll need to do is start the session to begin with, but that's not a big deal. I've also noticed that KBFS seems a bit cranky if you're on a home DSL or cable line, and occasionally the router freaks out and reboots itself. If that happens you'll get a screen full of "▶ WARNING disconnected" errors, and you'll need to restart the kbfsfuse utility if that happens.
There's one more thing I want to talk about, which the more privacy minded among you have probably been grinding your teeth over: What if you didn't want to build a reputation? What if you want to use Keybase to encrypt something to someone, but you don't want the sender or receiver metadata included in the message, so you could throw it up someplace like Pastebin or rig up a dead man's switch (warning: Tropes Hole) of some kind? What if you were using the newsgroup alt.anonymous.messages, or something very much like it to broadcast messages to everybody to try to defeat traffic analysis, but only one or two people out of thousands could decrypt them? As it turns out Keybase's file encryption feature has a useful command line option, --anonymous, which means that it strips out sender and recipient metadata after encrypting it.
[drwho@windbringer tmp]$ keybase encrypt -i READ-ME-NOW.txt -o READ-ME-NOW.txt.anonymous --anonymous chris [drwho@windbringer tmp]$ ls -ltr READ-ME-NOW.txt* -rw-r--r-- 1 drwho drwho 2954 Feb 26 17:44 READ-ME-NOW.txt -rw-r--r-- 1 drwho drwho 5037 Feb 26 17:45 READ-ME-NOW.txt.anonymousNormally, the recipient metadata tells the software whether or not to bother trying to decrypt the data with the keys it has. If you tried to decrypt a message I'd encrypted to myself, Keybase would complain and it wouldn't work. The --anonymous switch means that anybody can try to decrypt it with their key, but it will only work for the rightful recipient(s) of the message. You would do this like so:
[drwho@windbringer tmp]$ keybase decrypt -i READ-ME-NOW.txt.anonymous --force Message authored by ...One more thing I just wanted to mention: What if you wanted to follow somebody on Keybase, but not make it public? Use the Keybase utility to follow them, but when it asks you "Publicly follow? [Y/n]" near the end of the process, hit 'N'. You'll still follow them but it won't be publically visible.
