6 ms·

Where are the security details published? I think that's what we all want to see... On top of this....I think this is cool in theory but bad in practice. The

by theboss 13y ago

Where are the security details published? I think that's what we all want to see... On top of this....I think this is cool in theory but bad in practice. The assumption that Root CA's are trustworthy is already hard enough to make, how do I know that Maria is actually Maria? How will you verify that ``Maria'' actually owns that twitter, github, gmail. Maybe it is possible to devise some type of scheme for those sites, but how about more obscure services? One mistake in one single account causes the entire thing to fall apart...

caf 13y ago
The idea here isn't that you use keybase to find out Maria's twitter, github or gmail identities - it's the opposite. The idea is that you already know who Maria is on one or more of those services, so the fact that the account you know is Maria's at github has posted a signed message from that public key is supposed to testify to you that that is really your Maria's public key. You could of course manually review and verify Maria's github post that contains her public key - all that keybase is really doing here is providing an easy way of discovering that github post (or tweet, or whatever).
- andrewaylett 13y ago
  s/could/should/?
  - caf 13y ago
    Only if you don't trust your copy of the keybase client (as opposed to the server, which you should not need to trust).
maxtaco 13y ago
As Chris said, we would like to publish everything, just haven't found the time yet. We have bits and pieces in wikis in our various github repositories (almost all of which are open source and public). The high bits are: all crypto is with GPG/RSA as per RFC4880. There are of course problems here, but we wanted backwards-compatibility and well-tested, well-used clients. We encrypt server-stored GPG private keys (if you choose to use that option) with TripleSec (see https://keybase.io/triplesec https://keybase.io/triplesec). Users use GPG to sign a series of JSON objects, of the form "I'm maxtaco on twitter", or "I checked Chris's proofs as of 2014/2/14 and they look good to me." All JSON objects that a user signs are chained together with SHA-2 hashes. So a user can sign the whole group of JSON statements by just signing the most recent one. Here's an example (click on "Show the Proof") https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1WuaT59 https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1Wu... There's a fair amount of engineering that went into the software distribution system. We rely first on npm to get the initial client out there, but after that, exclusively GPG for code-signing. That's documented here: https://github.com/keybase/node-installer/wiki/Update-Architecture https://github.com/keybase/node-installer/wiki/Update-Archit... We hope to have better documentation soon, and we value feedback, we just haven't had the time to put it together yet.
- theboss 13y ago
  Okay I'll dig into the details when I have time. I noticed you an malgorithms took the time to write big posts to me. Thanks, Ill make sure I repay you with some of my time too.
jonesetc 13y ago
> how do I know that Maria is actually Maria? How will you verify that ``Maria'' actually owns that twitter, github, gmail. > confirmed they're all her, using GnuPG to review a signed tweet and gist she posted. So it sounds like it you believe in GPG as a viable method of id, there's no reason not to trust this.
- sneak 13y ago
  Except the part where you're contacting keybase over https and they're handing you some key that says "this is maria's key, trust us". That's the part where you trust the PKI, and that part is easily subverted, breaking the trust of the entire system. If they were using the inherent properties of maria's key (e.g. the fingerprint), then they wouldn't need this whole silly website and username database. Maybe this should be an offline tool that just goes and fetches tweets and gists so we don't have to trust them. You could add friend mappings with key fingerprint + nickname.
  - jonesetc 13y ago
    Sorry if this is a dumb question, but I do not heavily follow cypto goings. How are you normally accessing the GPG public keys? The way I understood it was that you always access key servers through http or https from a key server.
    - theboss 13y ago
      When I get someone's GPG key I can call them on the telephone or go to their house and make sure I got the right one. I add it and use it. When you use this, I'm assuming I get that key every time from the server. I can get it and verify it once, or twice, or three times, but what about the 1000th time? What happens when I am important enough that they return a public key that is not Maria's, and I am none the wiser.
      - malgorithms 13y ago
        boss, I'm glad you answered this question. Because it explains the impetus for Keybase. I think what Keybase is addressing in the status quo is twofold: (1) sadly, almost no one does what you describe; in person meeting key exchanges and webs of trust may sadly be as unpopular in 20 years as they are now, and as they were 20 years ago. People who go to them are often confused, even programmers. I wish it were different. And (2) more important, in 2014, often the person you're dealing with is someone whose digital public identity is what matters, not their face in real life or phone number. If you know me online as github/malgorithms and twitter/malgorithms, to get my key, meeting someone in person or talking on the phone to someone who claims to be me is actually less compelling than a signed statement by malgorithms in all those places you know me. And if you do know me in real life, then I can tell you my keybase username and fingerprint, exactly as you're used to. So it's still as powerful for meeting in person. With the added benefit you can confirm my other identities, which you likely know to. In answer to your scenario about verifying: you only need to review the "maria" the server provides once, and then your private key signs a full summary of maria -- her key and proofs. Cases 2 through 1000 of performing a crypto action on maria involve you only trusting your own signature of what "maria" is. The client can query the server for changes to her identity, and this will be configurable; if maria adds a new proof, you might wish to know.

by theboss 13y ago

caf 13y ago

The idea here isn't that you use keybase to find out Maria's twitter, github or gmail identities - it's the opposite. The idea is that you already know who Maria is on one or more of those services, so the fact that the account you know is Maria's at github has posted a signed message from that public key is supposed to testify to you that that is really your Maria's public key. You could of course manually review and verify Maria's github post that contains her public key - all that keybase is really doing here is providing an easy way of discovering that github post (or tweet, or whatever).

andrewaylett 13y ago
s/could/should/?
- caf 13y ago
  Only if you don't trust your copy of the keybase client (as opposed to the server, which you should not need to trust).

maxtaco 13y ago

As Chris said, we would like to publish everything, just haven't found the time yet. We have bits and pieces in wikis in our various github repositories (almost all of which are open source and public). The high bits are: all crypto is with GPG/RSA as per RFC4880. There are of course problems here, but we wanted backwards-compatibility and well-tested, well-used clients. We encrypt server-stored GPG private keys (if you choose to use that option) with TripleSec (see https://keybase.io/triplesec https://keybase.io/triplesec). Users use GPG to sign a series of JSON objects, of the form "I'm maxtaco on twitter", or "I checked Chris's proofs as of 2014/2/14 and they look good to me." All JSON objects that a user signs are chained together with SHA-2 hashes. So a user can sign the whole group of JSON statements by just signing the most recent one. Here's an example (click on "Show the Proof") https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1WuaT59 https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1Wu... There's a fair amount of engineering that went into the software distribution system. We rely first on npm to get the initial client out there, but after that, exclusively GPG for code-signing. That's documented here: https://github.com/keybase/node-installer/wiki/Update-Architecture https://github.com/keybase/node-installer/wiki/Update-Archit... We hope to have better documentation soon, and we value feedback, we just haven't had the time to put it together yet.

theboss 13y ago
Okay I'll dig into the details when I have time. I noticed you an malgorithms took the time to write big posts to me. Thanks, Ill make sure I repay you with some of my time too.

jonesetc 13y ago

> how do I know that Maria is actually Maria? How will you verify that ``Maria'' actually owns that twitter, github, gmail. > confirmed they're all her, using GnuPG to review a signed tweet and gist she posted. So it sounds like it you believe in GPG as a viable method of id, there's no reason not to trust this.

sneak 13y ago
Except the part where you're contacting keybase over https and they're handing you some key that says "this is maria's key, trust us". That's the part where you trust the PKI, and that part is easily subverted, breaking the trust of the entire system. If they were using the inherent properties of maria's key (e.g. the fingerprint), then they wouldn't need this whole silly website and username database. Maybe this should be an offline tool that just goes and fetches tweets and gists so we don't have to trust them. You could add friend mappings with key fingerprint + nickname.
- jonesetc 13y ago
  Sorry if this is a dumb question, but I do not heavily follow cypto goings. How are you normally accessing the GPG public keys? The way I understood it was that you always access key servers through http or https from a key server.
  - theboss 13y ago
    When I get someone's GPG key I can call them on the telephone or go to their house and make sure I got the right one. I add it and use it. When you use this, I'm assuming I get that key every time from the server. I can get it and verify it once, or twice, or three times, but what about the 1000th time? What happens when I am important enough that they return a public key that is not Maria's, and I am none the wiser.
    - malgorithms 13y ago
      boss, I'm glad you answered this question. Because it explains the impetus for Keybase. I think what Keybase is addressing in the status quo is twofold: (1) sadly, almost no one does what you describe; in person meeting key exchanges and webs of trust may sadly be as unpopular in 20 years as they are now, and as they were 20 years ago. People who go to them are often confused, even programmers. I wish it were different. And (2) more important, in 2014, often the person you're dealing with is someone whose digital public identity is what matters, not their face in real life or phone number. If you know me online as github/malgorithms and twitter/malgorithms, to get my key, meeting someone in person or talking on the phone to someone who claims to be me is actually less compelling than a signed statement by malgorithms in all those places you know me. And if you do know me in real life, then I can tell you my keybase username and fingerprint, exactly as you're used to. So it's still as powerful for meeting in person. With the added benefit you can confirm my other identities, which you likely know to. In answer to your scenario about verifying: you only need to review the "maria" the server provides once, and then your private key signs a full summary of maria -- her key and proofs. Cases 2 through 1000 of performing a crypto action on maria involve you only trusting your own signature of what "maria" is. The client can query the server for changes to her identity, and this will be configurable; if maria adds a new proof, you might wish to know.