Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keybase.io

keybase.io

Post reply on HN
Print view View original

61–70 of 125 posts

Re: Keybase.io

#61

Post by IgorPartola »

maxtaco wrote: post #56
IgorPartola wrote: post #53

Earlier quoted context omitted.

Hold on. First, GPG servers are susceptible to the same type of attack, except they would never be used that way. You never look up a person by email, the send them an encrypted message using the key you get. Instead, you verify their key and email address out of band: you meet them, check their credentials, then sign the key. Keybase is trying to get rid of the in-person verification, an effort I applaud, but in fav…

Cool, I agree no one should use PGP servers the way I described, but you never know what people are doing out there. To do things the proper way, as you described, is difficult in practice for lots of people. To answer the question, the point isn't to get an (email address, GPG-key) mapping. It's to get a (public-internet-identity, GPG-key) mapping. People sometimes do this today in an adhoc manner (e.g. tweeting you…

I see. That MO makes a bit more sense then, though is it not then limited to just Keybase.io and will no longer work if something happens to this service? Or more importantly, is there a way to make this distributed?

Re: Keybase.io

#62

Post by maxtaco »

theboss wrote: post #4

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…

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).

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/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-Archit...

We hope to have better documentation soon, and we value feedback, we just haven't had the time to put it together yet.

Re: Keybase.io

#63

Post by sweis »

maxtaco wrote: post #47
sweis wrote: post #25

Earlier quoted context omitted.

Even though there is a disclaimer, I think the "encrypt in your browser" feature ( https://keybase.io/encrypt ) undermines Keybase's security credibility. This form has essentially the same level of security as Hushmail. Anybody using it should consider the content exposed to Keybase or anyone compromising Keybase.

I'm not an authority on hushmail, but it seems like they do crypto on the server, and the server is just trusted to throw away the keys and plaintext? In the keybase Web client, all crypto happens on the browser. The server knows no keys or data in plaintext. Of course, you'd have to audit the front-end JS code to believe that claim. But our intention is that the only way to compromise the Web-based tools would be to…

As you just said, users must trust the JS coming from Keybase. It might be compromised at any time.

Next, people usually mumble about auditing it, downloading a copy, signing it, etc. At the end of the day, you arrive to code installed on the client - which you already have.

The web version just weakens your story.

Re: Keybase.io

#64

Post by malandrew »

IgorPartola wrote: post #53
maxtaco wrote: post #51

Earlier quoted context omitted.

No, there are no proofs based on e-mail addresses, because such proofs are not publicly-auditable. We could ask that maria prove to the server that she controls a given gmail account, but there's no way for the server to prove that to you. We want the server to be untrusted, ideally just a dumb message router. If Chloe wants to impersonate maria, she'll need to get control of maria's twitter and github accounts. Just…

Hold on. First, GPG servers are susceptible to the same type of attack, except they would never be used that way. You never look up a person by email, the send them an encrypted message using the key you get. Instead, you verify their key and email address out of band: you meet them, check their credentials, then sign the key. Keybase is trying to get rid of the in-person verification, an effort I applaud, but in fav…

Could you effectively add an online "in person" check by having keybase.io send the person a large uniquely watermarked placard with a unique OCRable pin that the person holds up while taking of photo of themselves mugshot-style that must be sent in as a lossy image type (where image tampering is detectable). With this image publicly published online, it would be easy to visually verify the person yet another way. Obviously for people with pseudonym identities that are online only, these check would be irrelevant.

Re: Keybase.io

#65

Post by maxtaco »

IgorPartola wrote: post #61
maxtaco wrote: post #56

Earlier quoted context omitted.

Cool, I agree no one should use PGP servers the way I described, but you never know what people are doing out there. To do things the proper way, as you described, is difficult in practice for lots of people. To answer the question, the point isn't to get an (email address, GPG-key) mapping. It's to get a (public-internet-identity, GPG-key) mapping. People sometimes do this today in an adhoc manner (e.g. tweeting you…

I see. That MO makes a bit more sense then, though is it not then limited to just Keybase.io and will no longer work if something happens to this service? Or more importantly, is there a way to make this distributed?

If the site went away tomorrow, you'd still have keys in your GPG keychain. You'd also have a local cache of the server-side data relevant to you.

All public server-side data is available as a dump (https://keybase.io/__/api-docs/1.0#call-dump-all). Private data like encrypted public keys and password hashes we of course will keep under wraps.

We don't have immediate plans to make the system distributed, but if someone did it, we'd find it very cool. It's just too much for us to do right now.

Re: Keybase.io

#66

Post by malgorithms »

theboss wrote: post #40
jonesetc wrote: post #35

Earlier quoted context omitted.

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.

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.

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.

Re: Keybase.io

#67

Post by derefr »

sneak wrote: post #31
jonesetc wrote: post #21

Earlier quoted context omitted.

> 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.

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 sho…

The... the whole point of this is to avoid the "you could add friend mappings with key fingerprint + nickname" part. You do realize that, right?

Re: Keybase.io

#68

Post by tptacek »

maxtaco wrote: post #47
sweis wrote: post #25

Earlier quoted context omitted.

Even though there is a disclaimer, I think the "encrypt in your browser" feature ( https://keybase.io/encrypt ) undermines Keybase's security credibility. This form has essentially the same level of security as Hushmail. Anybody using it should consider the content exposed to Keybase or anyone compromising Keybase.

I'm not an authority on hushmail, but it seems like they do crypto on the server, and the server is just trusted to throw away the keys and plaintext? In the keybase Web client, all crypto happens on the browser. The server knows no keys or data in plaintext. Of course, you'd have to audit the front-end JS code to believe that claim. But our intention is that the only way to compromise the Web-based tools would be to…

Then the only difference between hushmail and your model is exactly what the FBI will get a subpoena to have you type into your server to subvert your users. The models are equivalently insecure.

Incidentally, you can't simply audit the "front-end Javascript"; you have to evaluate everything that influences the Javascript runtime (the DOM, stylesheets, cached resources, &c) every time the page loads. Browsers aren't designed to make content-controlled code "auditable"; it simply isn't a capability of the environment.

Re: Keybase.io

#69

Post by theboss »

maxtaco wrote: post #62
theboss wrote: post #4

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…

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…

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.

Re: Keybase.io

#70

Post by jonesetc »

theboss wrote: post #40
jonesetc wrote: post #35

Earlier quoted context omitted.

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.

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.

This is what I assumed the answer would be, and at this point it just becomes a difference in opinion. I personally do not believe that the methods you describe are generally acceptable options in the modern age. My phone number and address are much more important to me than the off chance of someone capturing my https traffic, breaking it, and inserting a fake public key. There is a point where the absolute security of exchanging public keys written on pieces of paper in a park are called for, but it's not for everyone or even most.
Post reply on HN