Thoughts on Keybase.io
blog.lrdesign.com
blog.lrdesign.com
1. They are not "rolling their own" crypto. keybase seems to be an interesting wrapper around gpg that helps you establish links between accounts using "proofs of knowledge of secret keys." I haven't tried the service yet; but one can inspect the code:
npm install -g keybase-installer
keybase-installer
grep gpg ~/.npm/keybase/0.0.43/package/lib/*.js
2. "Keybase's pitch is that rather than use a web of trust..."
It is not mutually exclusive. Since you have it installed, try
keybase -h
keybase track <id>
That seems to subsume web-of-trust
"limits on that identification are two-fold...<security of twitter>...and...<soundness of tweeting>"
So it is actually the same argument repeated. The first 3 Mission Impossible movies also demonstrate that when you meet someone in person, they might be Ethan Hunt instead of the person you think they are. For the paranoid, there are out-of-band mechanisms around this (that can also be used with keybase). Even without those, keybase is an out-of-the-box mechanism for linking identities that is weakly sound over the Internet.
3. "...doing this right" One of the founders, Max Krohn, was at RealWorldCrypto this year. He is an MIT phd and he certainly knows quite a bit about applied crypto. He is also a systems person and comfortable making tradeoffs between usability and security.
If keybase allows 1m more people to easily create and use keys, even if their day-to-day workflow is not secure-against-state-adversaries, that would be progress.
In my opinion that thought process is exactly what's wrong right now.
Just compare the two interfaces [1] and [2] and you'll see why why your average person won't be happy to use the pgp.mit.edu keyserver to verify identifies. It's cluttered, complicated and the presentation once you searched for a name is subpar. I'm not saying that keybase is the best way to do it but it's a good start to make the existing tools (Like the webinterface of pgp.mit.edu) prettier and easier to use.
[1] http://pgp.mit.edu/ [2] https://keybase.io/ (search field in the header)
PGP has failed to reach even a moderate userbase outside of crypto enthusiasts, and while part of this, as the author suggests, is painful UI, a large part is also that the web of trust model is unreasonably demanding for most cases.
Keybase asks: who are you on the internet if not the sum of your public identities? The fact that those identities all make a certain claim is a proof of trust. In fact, for someone who knows me only online, it's likely the best kind of trust possible. If you meet me in person and I say "I'm sgentle", that's a weaker proof than if I post a comment from this account. Ratchet that up to include my Twitter, Facebook, GitHub, personal website and so forth, and you're looking at a pretty solid claim.
And if you're thinking "but A Scary Adversary could compromise all those services and Keybase itself", consider that an adversary with that much power would also probably have the resources to compromise highly-connected nodes in the web of trust, compromise PKS servers, and falsify real-world identity documents.
I think absolutism in security is counterproductive. Keybase is definitionally less secure than, say, meeting in person and checking that the person has access to all the accounts you expect, which is itself less secure than all of the above and using several forms of biometric identification to rule out what is known as the Face/Off attack.
The fight isn't "people use Keybase" vs "people go to key-signing parties", the fight is "people use Keybase" vs "fuck it crypto is too hard". Those who need the level of security provided by in-person key exchanges still have that option available to them. In fact, it would be nice to see PKS as one of the identity proof backends. But for practical purposes, anything that raises the crypto floor is going to do a lot more good than dickering with the ceiling.
And I don't buy the "don't reinvent crypto" argument at all. Sure, it's a bad idea to use your own password hash instead of bcrypt, but maybe you think you can do better and you end up creating the foundation for Litecoin. A general-case argument against any innovation is a dangerous thing.
With that said, I totally agree about uploading your private key to Keybase. That's one very scary basket to put all your eggs in and I don't trust it at all. Luckily, it's optional.
The mitigating factors here are:
1) Most "good" services at least those used by the tech geek community do support 2SV these days, which would raise the bar somewhat for people who use it, although I suspect several of those services will still unlock 2SV for you if you say you lost your second factor and know enough about the account (Google does).
2) Someone would obviously notice that their passwords had all been reset and could sound the alarm.
But in practice, I think this feels like not much different to just verifying ownership of an email address, which is what CA's already do (and there are PGP CA's if you don't want to use X.509). Comodo will do it for free, it's integrated with the browser via the HTML5 keygen tag, and it takes just a couple of minutes.
That's why (for PGP) you, as an assurer, generally don't upload the signature yourself but send it to the e-mail address the assuree claims to own. The proof that they own that account is that they are able to receive the mail with the signature. They can then publish it themselves.
I disagree that the existing public key repositories are what people should be using and that the twitter/github integration is pointless. In today's world, we often want to communicate with people we have never met in person. An old tweet or a gist that hasn't changes in a long time seems like a pretty safe way of verifying someone's identity. Apart from the NSA[^1], it's hard to imagine a situation where both keybase was compromised with a bad public key, and twitter/github was compromised by invisibly changing an old tweet (not possible to edit without a big hack) or a gist (not possible to edit without creating a change history within a big hack). So this makes a lot of sense to me as a way to easily verify identity.
[^1]: At this point I'm not sure I would trust any encrypted online communication if the NSA wanted to read it.
Knowing that the binary or tarball you got was created by the account you are trusting to have actually written it isn't perfect, but it's pretty good for a lot of situations.
The thing this doesn't solve is it opens the door for new attacks. What happens if I make a page identical to twitter on twtr.com, that shows a keybase user verifying a fake public key. Keybase could easily accomplish this and this attack isn't that different than other attacks we have seen on the web.
In my opinion...keybase doesn't buy you any new level of security...it's just supposed to be a user friendly way to distribute keys, even though you still have to do the work of verifying them yourself.