Apologies for the barely coherent wall of text below. This was written about 19 hours into a recent 22-hour trans-Pacific journey, but thought I would still share it.
Introduction
I've been using an exciting new startup service for a few months now, and wanted to put down what I love about this awesome new project.
My favourite thing is actually two things, that I can best summarise as: Makes information security accessible to the masses, by improving on the basic foundations of trust-based security. Now for the non-security people in th eaudience this probably sounds like a heap of confusing buzzwords, so I'm going to give a quick primer on the current state of data and messaging security to me, before outlining how Keybase changes this.
Primer on trust-based information security
If you're already familiar with the concepts of message signing and asymmetric/PKI infrastructure, skip down to the second part of this post
To try and explain how Keybase changes things, I'm going to try and give this primer in the form of a few simple scenarios.
So, for the sakes of argument, let's say my friend Gary has sent me an email with some important changes to a project we're working on; he's asking me to open a document he's created so he puts a link in the email.
Now, having received this email, I might get a bit suspicious since this is a bit unusual. How do I know this is really Gary? Well, that's easy: Gary can use GPG to sign his email to me, thereby verifying it's really him. So Gary signs it and send it to me again. However, contrary to what many think I still don't know it's really him!.
A digital signature has many similarities to a physical one. That includes the fact that a signature on a document doesn't help verify it's authenticity unless I have a verified copy of Gary's signature somewhere. Even with the digital signature on Gary's email, this doesn't help me verify that that signature is the one belonging to Gary, and not just someone else pretending to be him.
In the "traditional" Web of Trust (WoT) system, the ideal scenario would be that Gary sends me that email, then he meets me in person, we exchange public keys and I can verify that the key matches his signed email. One problem: Gary is 16,170 km away. No issue, maybe Gary has met our friend Mattias in person, Mattias has verified that signature (and signed it using his own key), then I've met Mattias independently and we've done the same. Since I trust Mattias, I can trust that Gary's is accurate. This is a very effective way of sharing trust across groups of people without verifying identities and keys 1:1 with every member of the group. Plus, this method is much easier because Mattias is only 15,484 km away from me.
The first problem here is scaling: there are only so many ways of securely verifying keys, and most of them don't work with global-scale groups of people. The second problem is the innate insecurity of the Web: if I want to verify his key, I could send him a message on Slack asking for it, but now I'm trusting that when I'm talking to Gary on Slack, I'm really talking to Gary, and there is no way to verify that.
Secure communications often aren't secure
When tasked with messaging sommeone securely, many people without a basic knowledge of security will immediately install a copy of Signal for their device, look up their recipient and start chatting away, happy with their increased security. What I've just described is not secure. Signal provides you with a safety number and asks users to verify (out of band) that it matches their intended recipient. How many people actually do so?
The Keybase model
Keybase helps with this problem through the simple feat of enabling users to verify keys over insecure mediums.
To reuse our example from earlier, Gary has sent an email to me (and the team) about some changes, asking to open a document. He's digitally signed his message, but I have no signed keys in common with his, so I have no way of verifying his signature.
With Keybase however, I can look up his signature's key on Keybase. On his profile I could then see that the mysterious alleged Gary with this signature is also @gep13 on Twitter, and @gep13 on GitHub. I know for certain that the Gary I am looking for is @gep13 on GitHub so I can reasonably now trust the signature on the email as being genuine. Without any secure key exchange and without any complicated multi-person trust chains I've just immediately verified a signature against a known-good version of the signature (sort of).
For the nitpickers: I haven't actually verified his signature, instead I've verified that the signature I received is the same one used by his Twitter, GitHub etc identities. Given I work on the same project with him, we can assume I trust his GitHub identity, for example.
How followers improve the model
Let's expand our previous example and say that Gary has also included Dave in the original email. Now I haven't had any direct communication with Dave before so I can't verify his signature. Worse, I also haven't interacted with him on Twitter or other social networks yet. With traditional GPG security, I can now try and draw a web of trust using signed keys from people in my local keyring hoping to find a path I'm satisfied with from my key to Dave's (which is even less fun than that makes it sound). With Keybase, I can just look his key up on Keybase and see that not only has Adam verified his Twitter, GitHub, and Reddit accounts, but also that he is followed by quite a few people I trust. Given this, I can see from just one screen that yes, I can also trust Dave's key, no key exchange needed, no local GPG setup, no trust settings, just quick and easy verification.
Verifying identities, not keys
To be clear, I don't see this as a failure on the part of GPG/PGP security and signing. That technology was built quite some time ago and does exactly what it set out to do: allow users to encrypt, sign and verify digital keys. Keybase, on the other hand, supports GPG keys, but it changes the whole design to be about verifying identities, not just keys. If you check my Keybase profile, for example, you will see not just my GPG key (which is also on the MIT keyserver, for example), but an additional work-specific key, multiple verified social networks, proof of the web domains under my control, and a list of my trusted circle. Now, when you check my Keybase profile, you're not just verifying my PGP key (and signature), you're verifying my whole digital identity at once. As digital security goes, this is a major improvement, that is not significantly more difficult for average users.
In fact, this identity-centric approach works so well that you can encrypt files or chat messages to users who haven't even signed up to Keybase yet!
Room for improvement
Is Keybase perfect, then? Definitely not. I think the proof system can be a bit confusing for new users, especially for those without a basic knowledge of security and signing. As utterly awesome as the KBFS is (completely seamless, OS-native encrypted files? Yes, please!), performance could really do with some attention. I haven't had a chance to try out the new Keybase Chat either, but it looks to solve the problem of secure chat without offline key/fingerprint exchange, again by allowing you to verify against your recipient's digital identity, rather than just their key. For me, given I work with it daily, Keybase's GPG integration feels like it could do with work.
All that being said, I think Keybase ticks off the important points:
- Makes digital signatures and message encryption more accessible
- Goes a long way to solving the problem of secure key exchange over the Web
- Implements this in a versatile and flexible way (chat, files, messages, GPG etc)
If you're curious about digital signatures and encryption and haven't got a Keybase account, hit me up on Twitter and I'll try and sort you out with an invite code. What do you think of Keybase's approach to the trust model? Let me know in the comments.