Hacker News new | ask | show | jobs
by jrochkind1 4466 days ago
You just have to know that you're placing all your trust in keybase. If keybase says they have verified that `liz` is a certain facebook account, and you are acting based on that in encyrpting something to `liz`, you are trusting that:

* keybase acted honestly

* nobody compromised keybases software when it was doing the verification

* _after_ it did the verification, nobody managed to get keybase to switch out `liz`s key for some other key that wasn't really liz's (either because keybase was compromised, or keybase was untrustworthy... maybe because the government made them be?)

That last one is the kicker for me. If keybase catches on, surely they are going to get government orders to swap our one key for another key at some point.

The traditional web of trust does not require trusting any of those things, or at least not in those simple forms.

On the other hand, yes, there are reasons traditional PGP hasn't caught on, and usability is a big one. But, still, to compromise security for usability... if you go all the way there, you just wind up where we are now, not secure at all, right?

So, okay, is there value in going some of the way there, and getting some improved security but not as much as you could, for a more usable experience? Maybe. The danger is that people will think they are getting a lot more security than they are getting, and that situation can be worse than no security at all.

One thing Snowden taught us is that if you have to trust a third party to be honest... it's not that the people running keybase aren't honest, it's that the government will _compel_ them to be dishonest if it ever matters to them.

3 comments

It's not correct that you need to trust Keybase. The way that someone verifies their social identity is by posting a tweet (or equivalent) signed with their private key. So you can look up someone's public key on Keybase and then verify that Keybase gave you the correct key, by checking the signature on their original tweet / other social verification posts.

Assuming you actually do this level of verification yourself (rather than allowing keybase to do it for you), the only thing you have to trust is that Keybase/Twitter/Github/Facebook/etc aren't all simultaneously colluding to give you a bad key. That seems to me like a reasonable assumption in pretty much all plausible circumstances.

Aha, good point! Hmm, have to think about that more.

It might be cool if there were an open source tool (from keybase or not) that would do this check for you. Most people in the target audience aren't going to be able to do it yourself.

That might be something cool for keybase to provide. (Yes, of course you'd still have to trust the open source tool, but that's why it's open source, etc.).

Before sending something particularly sensitive, you could run the tool to check that the public key you have still matches what was posted on their twitter, facebook, etc. (And yes, if someone can hack the old tweet on twitter, then of course, yeah).

Isn't that exactly what the command line client does when you verify a user?
Ah, you can re-verify the user at any point, not just the first time you add them as a contact or whatever? Neat.

Okay, this is good marketting for the product, because you are convincing me that at least it might have evaded some of these problems, and is worth further investigation. :)

Yes, it is, and it's 100% open source.
The system does not work like this.

To put it shortly: it's not Keybase that verifies that `liz` is a certain Facebook account. `liz` generates cryptographic proofs and publish them on Facebook, you get them and verify them. Keybase.io can't switch anything, unless also `liz`'s FB (and Twitter, and GH...) is compromised and the proofs switched.

This is a common and understandable misconception with Keybase threat-model, they should probably try even harder to put it up front.

What OP says is that she does not trust the way the tool to generate these proofs is distributed.

If you trust Twitter/Facebook/Github, you can verify assertions about account ownership by retrieving the signed message from those services and verifying they encode the correct data and that the signatures verify.

However, this does not protect against a malicious service provider from modifying the message to replace it with a different user.