Edit: I also have invites available if you are interested in checking it out. Contact me via my HN profile
In other words, if you ask for Twitter user X's public key, your client can check that proof on twitter itself (rather than trusting that a key server did it for you, like it would with email proofs), and it can trust a hacked/coerced server isn't hiding something specifically from you, such as a revocation. The latter is particularly hard to protect against. It also gets timestamping: you know the world has been seeing the same public key for Twitter user X for many months or years.
[1] https://keybase.io/docs/server_security/merkle_root_in_bitco...
[update] I gave mey a bunch more invitations, but I can be hit up on twitter (https://keybase.io/chris) for HN users wishing to jump our invitation queue, which is large.
One complication: looking up a key by email and trusting 3rd party verifications is philosophically pretty different from what Keybase is doing. So we have to figure out how to resolve this. For example, we don't even have an email based lookup at all (!), because we have no way of letting a client verify it's true. I don't know if we can be convinced to change this. We're looking forward to Yahoo's and GMail's work on their E2E projects because it may help verifying email addresses publicly.
And to be clear: we're not in the email business, so we want Keybase-style key proofs to be useful to mail clients like Whiteout. We'd like to work well with everyone.
Second, for public keys that are signed by other fingerprints in keybase, it would be nice to have those listed in my trackers list.
Finally, for people who upload a public key to keybase, it would be great if that would gossip to the pool so I could get it via gpg --recv-key.
Thanks for the great work so far!
Felix and me will be at the event in April as well. So we can chat there.
We think keybase's concept is great and also look forward to what the E-2-E developers are coming up with for certificate transparency. Our only concern is, that these concepts are not open and backwards compatible to current key server solutions. This would create an island... and we've been sitting on our own small island up until now with our closed key server solution.
Sure if Google and Yahoo launch their concept it might exceed any marketshare that HKP might have had. But unless there is an open standard where small guys like us can latch onto, it's going to be hard to get vendors on board.
- Tankred
How does HN feel about that identity aspect? Is it supposed to replaced key signing or just augment it?
I'm frankly not sure I fully get my head around the concept, even after reading this page:
https://keybase.io/docs/tracking
But it's Friday afternoon, so that could be it...
Even this case is mitigated because of the timestamping: a compromise would have to be a public compromise on an ongoing basis, and everyone in the world would have to see the same compromise, including the alleged twitter holder. Tracker statements add to the timestamping: when someone runs the Keybase client and tracks them, they sign a statement saying on date X twitter user Y had that public key and they checked it.
The second advantage is that a person is typically a sum of many identities. Consider a known developer who signs code using their Keybase announced key. (Let's say Jeremy Ashkenas does (does he?) - anyway, he's on Keybase as https://keybase.io/jashkenas). His public key is announced on his Github and Twitter accounts, both of which are known. He signs those statements with the matching private key. If you ask Keybase for his key, you get 3 things: Keybase telling you what it is, Twitter agreeing with you, Github agreeing with you, and bitcoin telling you everyone in the world has gotten the same answer for those 3 accounts for the last few months. And CLI tracker statements timestamping, too.
Additionally, doesn't the user signing the statement with his or her private key mean that you need to have his private key to really believe it? I notice on the website it states that encryption/decryption is done with client encrypted keys. If it's client encrypted presumably the signing is happening at the client and an announcement is sent to keybase stating as such. How can you trust the data your getting back from the client is trustworthy or not also compromised?
Forgive me if I'm being boneheaded here, I'm just trying to grasp this so I can say, "Yes, that makes enough sense."