[sokrates]

The entire idea is that, while keybase stores the pubkey, you don't have to trust them to deliver the right key. They have basically rolled their own type of digital certificate that's stored within a variety of social services, i.e. Twitter -- you tweet something like "I'm <fingerprint of your key> on keybase.io!". The keybase server says this to the keybase CLI: "Bob's pubkey is <key>, and I'm right because https://twitter.com/bob/tweets/1234 says so". The CLI then verifies that the tweet URL really contains the right fingerprint. This extends the trust root to the twitter user (and your local HTTPS CA store). Repeat for a variety of services similar to Twitter. This extends the trust root to the union of all the social site accounts of the keybase user. Whether you choose to trust those is (as always with trust roots) entirely up to you.

Not the worst idea ever, in my opinion.

[skrebbel]

Wow, that's pretty cool indeed. I completely did not understand that off their landing page though. Thanks for the clarification!

[antocv]

Kind of still sucks to use this to communicate with other people since you loose deniability.

I prefer to talk on internet forums or exchange clear-text emails, because deniability.

[skrebbel]

Is it ever possible to have both security and deniability? Aren't they kind of intrinsically opposed?

I mean, is the same argument to keep security off your home wifi router so that if the MPAA goes after you for seeding torrents, you can claim that it might've been the neighbour.

[icebraining]

There's something in-between, though it doesn't actually break the paradox, just makes some different tradeoffs:

In cryptography, a ring signature is a type of digital signature that can be performed by any member of a group of users that each have keys. Therefore, a message signed with a ring signature is endorsed by someone in a particular group of people. One of the security properties of a ring signature is that it should be difficult to determine which of the group members' keys was used to produce the signature

http://en.wikipedia.org/wiki/Ring_signature

[malgorithms]

On the IM side of things, you should check out OTR (off-the-record messaging): https://otr.cypherpunks.ca/ - in particular check out the top 4 goals mentioned on that page.

[endlessvoid94]

Really interesting. I've used OTR but didn't realize those goals.

However, I don't quite understand how "anyone can forge messages after the conversation" works. Can you explain any more?

[acomar]

The keys are effectively public once the conversation ends -- they aren't tied to your identity. So those messages could have been forged by anyone, there's no proof they came from you.

[Zigurd]

You need to narrow the question. Instead ask "Is deniability hard in store-and-forward or and storage applications?"

The answer is yes. But, as others here have pointed out, you can use ephemeral keys for some applications.

[eridius]

That's pretty cool. I was under the impression that it was validating that the twitter/github/etc are owned by the same person, but using twitter/github/etc to validate that the keybase key is correct is much cooler.

However, it's not foolproof. If your attacker (e.g. the NSA) can compromise some of the proof sources, they can return only the compromised proof sources to the client so the client doesn't see anything that contradicts their malicious key. And if the user doesn't know offhand what twitter/github belong to the person their contacting, the attacker could even simply substitute their own sources that claim to be the same person without actually requiring any compromise of the proof site at all.

For example, if I don't know already that maria's Twitter is maria_h20, then the attacker who has compromised keybase can instead return maria_g20, a Twitter account under their control that has posted a proof of the malicious key.

I get that tracking a user will mitigate this, but that only helps if I've already interacted with the user before and chosen to track them.

[ryandrake]

What if you don't use Twitter, Facebook, GitHub, etc.? Do they have a way of establishing trust that does not involve signing up for various identity-harvesting social networking services? Maybe a certificate that you can host on your own web server or something?

[clarkm]

Right now you can only do:

  keybase prove {twitter,github}

but more types are in the works. Though proving your identity on more than just your personal website has its advantages. For one, I don't know anything about your hosting situation or your security practices.

[niels_olson]

This seems very sensible. For example, at a key-signing party, as I understand it, ideally everyone knows someone there, or can authenticate via two separate government ID. The benefit here is that keybase.io has removed "government" from the equation.

[awendt]

After what happened to Mat Honan almost two years ago, having insecure systems like Twitter "confirming" my pubkey seems more like a nightmare than a good idea, doesn't it?

And the fact that Keybase.io even suggests uploading your private key puts a big fat "AVOID" sign on the service for me.

[Fede_V]

Great explanation, thanks. Could you explain how this set up would resist a hostile actor (like say, the NSA) from compelling the site to serve to wrong certificate?

[malgorithms]

The client verifies the key by checking that the signed tweet, gists, etc., all exist and were signed by the private key that matches that public key. So to get the server to successfully lie, one would need to coordinate lies from twitter, github, etc., all at the same time.

[schrodinger]

And it would be really hard to get all those services to lie without the recipient being able to tell. They could see that their tweet contains a different fingerprint than they expected, unless you got all those services to lie only to the sender, not the recipient. Which is very hard to do without getting caught.

[xgbi]

DNS highjack and boom?