8 ms·

https://keybase.io/ https://keybase.io/ with it's social media identity proofs have been interesting way to allow finding contacts in my social network's pgp ke

by mey 12y ago

https://keybase.io/ https://keybase.io/ with it's social media identity proofs have been interesting way to allow finding contacts in my social network's pgp keys. Edit: I also have invites available if you are interested in checking it out. Contact me via my HN profile

pasbesoin 12y ago
Tim Bray's been interested in it, which is where I first heard about it. https://www.google.com/#q=site:tbray.org+keybase https://www.google.com/#q=site:tbray.org+keybase
malgorithms 12y ago
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_bitcoin_blockchain 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 https://keybase.io/chris) for HN users wishing to jump our invitation queue, which is large.
- diafygi 12y ago
  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/ https://diafygi.github.io/publickeyjs/
  - malgorithms 12y ago
    Cool site! Max Krohn (https://keybase.io/max 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.
    - diafygi 12y ago
      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!
      - IgorPartola 12y ago
        I second all these requests. Exactly what I was thinking when I finally got my invite.
    - tanx 12y ago
      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
- williamcotton 12y ago
  Can you give us the txId of a bitcoin transaction used to represent the entire state?
  - tokenizerrr 12y ago
    https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain https://keybase.io/docs/server_security/merkle_root_in_bitco...
- mey 12y ago
  He wasn't kidding about a bunch, I've only burned through about a tenth of them. :) Still have more available.
volker48 12y ago
This is the first thing I thought of as well as I've been using keybase myself for a little while now and am very happy.
stinkytaco 12y ago
This is fascinating concept, especially since I've always felt that my PGP key was sitting out there mostly useless since no one I know personally signs their emails or even knows someone who signs emails. However, wouldn't the weak part here be if my twitter (or other public) account was compromised somehow? Or if someone just impersonated me and sent a "unique tweet" pretending to be me? 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 https://keybase.io/docs/tracking But it's Friday afternoon, so that could be it...
- malgorithms 12y ago
  This is a good question: generally if all you know about someone is their twitter name, and that's it, then a compromise of their twitter account could lead to a compromise of their key announcement. 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 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.
  - stinkytaco 12y ago
    So it becomes its own "web of trust" in a sense? Every time there is activity, it's another point for "yeah, this person is who they say they are, look at all the stuff they've verified"? That's an interesting concept, at least for casual communication (the kind I might want to keep out of the ears of Google or Twitter, probably not the kind I'd want to keep out of the ears of the government). Is there any plan to incorporate traditional keyservers into the "web" as a component in the trust model? 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."

by mey 12y ago

pasbesoin 12y ago

Tim Bray's been interested in it, which is where I first heard about it. https://www.google.com/#q=site:tbray.org+keybase https://www.google.com/#q=site:tbray.org+keybase

malgorithms 12y ago

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_bitcoin_blockchain 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 https://keybase.io/chris) for HN users wishing to jump our invitation queue, which is large.

diafygi 12y ago
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/ https://diafygi.github.io/publickeyjs/
- malgorithms 12y ago
  Cool site! Max Krohn (https://keybase.io/max 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.
  - diafygi 12y ago
    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!
    - IgorPartola 12y ago
      I second all these requests. Exactly what I was thinking when I finally got my invite.
  - tanx 12y ago
    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
williamcotton 12y ago
Can you give us the txId of a bitcoin transaction used to represent the entire state?
- tokenizerrr 12y ago
  https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain https://keybase.io/docs/server_security/merkle_root_in_bitco...
mey 12y ago
He wasn't kidding about a bunch, I've only burned through about a tenth of them. :) Still have more available.

volker48 12y ago

This is the first thing I thought of as well as I've been using keybase myself for a little while now and am very happy.

stinkytaco 12y ago

This is fascinating concept, especially since I've always felt that my PGP key was sitting out there mostly useless since no one I know personally signs their emails or even knows someone who signs emails. However, wouldn't the weak part here be if my twitter (or other public) account was compromised somehow? Or if someone just impersonated me and sent a "unique tweet" pretending to be me? 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 https://keybase.io/docs/tracking But it's Friday afternoon, so that could be it...

malgorithms 12y ago
This is a good question: generally if all you know about someone is their twitter name, and that's it, then a compromise of their twitter account could lead to a compromise of their key announcement. 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 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.
- stinkytaco 12y ago
  So it becomes its own "web of trust" in a sense? Every time there is activity, it's another point for "yeah, this person is who they say they are, look at all the stuff they've verified"? That's an interesting concept, at least for casual communication (the kind I might want to keep out of the ears of Google or Twitter, probably not the kind I'd want to keep out of the ears of the government). Is there any plan to incorporate traditional keyservers into the "web" as a component in the trust model? 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."