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.

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

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.

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.

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

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.

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?

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.

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.

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.

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?

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.

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.

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.

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?

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.

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.

DNS highjack and boom?

What they do is have proofs hosted by the user on different sites (e.g. Github, Twitter) that your client can use to verify that the key is valid. The Keybase server can't fake those without compromising those sites.

In one command, Keybase has acquired maria's public key, her keybase username, and her public identities, and confirmed they're all her, using GnuPG to review a signed tweet and gist she posted. (...) If you trust the client (our reference client is open source), then the server can't give you the wrong key for maria without getting caught or also compromising her twitter and github accounts.

If the keybase tool uses certificate pinning and if keybase.io is using SSL (likely), then a compromise of your connection would also need to be a compromise of the keybase tool on your machine (to defeat the certificate pinning, though if they can compromise the tool installed locally, you have other things to worry about).

You are right however that keybase.io themselves might be compelled by the government (or criminals if you make a distinction there) to serve up modified public keys.

If keybase.io provides a modified public key, doesn't the client detect that by comparing a hash of the provided key to the "proof" hash posted elsewhere?

e.g. In the situation commented above [1], your client would download the altered key from keybase.io, compute a hash, then download https://twitter.com/bob/tweets/1234 and extract THAT hash, then compare the two. The comparison would fail, and you would know that the key you received from keybase.io is not the same as the key that the tweet vouched for.

[1] https://news.ycombinator.com/item?id=7465349

And certificate pinning means that they store whatever public key was reported for maria the last time, and complain if they're different? I see that that would help.

I would even go farther and include the expected public key directly in the client. That would even defeat attacks where the connection is already compromised the first time you run the client.

It's the whole point of Keybase! :)

maria will publish proofs in a Tweet and a Gist (and hopefully more in the future) and your client will check them, and tell you "maria is @Mmmaria on TW and @mariaz on GH, is this the person you know?"

The server has no say in this, it can only perform a DoS.

I presume that the tool at least uses TLS to talk to the server.