Hacker News new | comments | show | ask | jobs | submit login
Thoughts on Keybase.io (lrdesign.com)
36 points by DanielRibeiro 1365 days ago | hide | past | web | favorite | 11 comments

The author may have some points; I have not inspected the protocols or the source completely, but the arguments made in the post are misleading and inaccurate descriptions of keybase. Seems like there may be some subtle yet festering bias.

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


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.

"A public directory of publicly auditable keys? Allow me to introduce PKS (an example server) - a decentralized system for distributing public keys."

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)

Many clients do the PKS search for you. Using the website is always going to be suboptimal, you have to copy keys around. Way better to let your client of choice do it.

Unfortunately I think this particular review is missing the point of Keybase. In the same vein as attacking Twitter for not making the follow relationship symmetric or attacking Instagram for ruining the dynamic range of pictures, this author is (mostly) attacking Keybase for the very point of what Keybase is.

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.

I think the issue is not so much that a scary adversary could simultaneously hack Twitter, GitHub, etc - that seems hard. The real problem is that all these services will, in the default configuration (no 2-factor auth), perform password resets via your email account. Thus if you succeed in hacking someone's mail account you can take control of their other accounts and go ahead and verify a new keybase profile. Unfortunately there's no way to know externally if someone uses 2-factor, so it's hard to judge how meaningful a Keybase profile really is.

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.

Also, the age of the tweet or gist would be a red flag. If the signed gist is 2 years old and hasn't even modified since, you can pretty safely assume that if the keybase public key matches the signed message in the gist, nothing nefarious has happened recently.

> 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.

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 agree with the OP about uploading private keys being bad, but you don't have to do that – everything works without doing that as long as you are comfortable in the command line. Whether or not uploading private keys should be an option is a good question (I think they probably should not be uploaded ever), but the site is still early beta so they should be given time to work this out without getting thrown under the bus quite yet.

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.

I agree that the Twitter integration doesn't seem enormously useful. However the GitHub integration seems to be somewhat useful for code signing at the very least.

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.

There are a few funny things about keybase. First, should they even make it an option to give them your private key? I believe they should not.

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.

Honest question: can somebody explain what problem Keybase addresses?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact