Hacker News Reader

Comment by malgorithms | Hacker News Reader

Two things we're particularly proud of at Keybase are (1) that there's no server trust of these proofs, and (2) we pin the entire state of the directory to the bitcoin blockchain, to prevent forking. [1]

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.

View on HN

Question. Do you plan on gossiping with or mirroring the SKS pools? I would love to be able to just search keybase for a public key rather than both:

https://diafygi.github.io/publickeyjs/

Cool site! Max Krohn (https://keybase.io/max) and I are meeting with some people working on various PGP projects in Germany in April, and one of the things on our personal agenda is the ideal future of key distribution. We don't really want to be a sole place to look up these keybase-style social media proofs. We also don't think they belong inside the keys themselves.

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.

Makes sense. If possible, I'd like to request at least gossiping with servers in the SKS pool. Right now, when someone signs my key and sends it to the pool via gpg --send-key, it doesn't get updated in keybase :(

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!

I second all these requests. Exactly what I was thinking when I finally got my invite.

Hey Tankred from Whiteout here,

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

He wasn't kidding about a bunch, I've only burned through about a tenth of them. :) Still have more available.

Can you give us the txId of a bitcoin transaction used to represent the entire state?

https://keybase.io/docs/server_security/merkle_root_in_bitco...

Reply on news.ycombinator.com