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

51–60 of 125 posts

Re: Keybase.io

#51

Post by maxtaco »

IgorPartola wrote: post #49

OK, finally looking at it on a desktop... So my first question is this: if I know "maria" and I want to look her up to get her GPG key, how does keybase handle that? Does it just do an email address lookup, as in goes to, say, GitHub, grabs her email address, maria@example.com, then goes to a public key server and grabs the key that corresponds to maria@example.com? If that's the case, there is a security issue: what…

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 claiming maria's email address won't get her anywhere. (Note that GPG keyservers are susceptible to exactly the attack you describe).

Re: Keybase.io

#52

Post by IgorPartola »

read wrote: post #30

Is it really impossible to make browser crypto a reality? Browser crypto can be scary! Do you have a malicious extension installed? We can't tell. Further, how can you guarantee we haven't been tortured into serving you custom, targeted JavaScript? Hopefully you're not that important. I realize malicious extensions can currently do as they please, but can't browsers allow extensions to define a security policy that f…

So even if you have a valid crypto implementation baked directly into the browser, and you can call crypto primitives directly from JavaScript, what's the point? I'd just grab whatever you are trying to encrypt before it gets encrypted, or decrypt it myself. Or replace the encryption functions with my own wrappers.

Remember, I can introduce any code I want so long as I control the server which is serving your web page. JavaScript crypto is an attempt to not trust the server serving the data, but if that server, or any other server can inject any code into the web page which is handling the encrypted data, then you have no security. You are still left trusting the server to not screw you. Which is the same as using HTTPS which we already have today.

Re: Keybase.io

#53

Post by IgorPartola »

maxtaco wrote: post #51
IgorPartola wrote: post #49

OK, finally looking at it on a desktop... So my first question is this: if I know "maria" and I want to look her up to get her GPG key, how does keybase handle that? Does it just do an email address lookup, as in goes to, say, GitHub, grabs her email address, maria@example.com, then goes to a public key server and grabs the key that corresponds to maria@example.com? If that's the case, there is a security issue: what…

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 favor of a much weaker check: whether a few centralized accounts had been compromised.

The other part, where you check Maria's Twitter and GitHub accounts, means that a few things like Twitter, and GitHub are impervious to Chloe: a tall order and a centralized one at that.

Once again, is the point here for me to get a tuple of (email address, public GPG key) so I can email Maria securely? If so, then someone somewhere has to prove that this tuple fetched from the public key servers is valid.

If the point is to only communicate via keybase.io, then the service is centralized, and useless once actual sensitive info is exchanged, the US government takes notice and shuts it down at the DNS level.

Re: Keybase.io

#54

Post by maxtaco »

sneak wrote: post #29

If this talks to keybase's API over https and any large groups come to rely on this, we've then effectively replaced the decentralized safety of the Web of Trust used for authenticating PGP keys with the PKI that's used in browsers, which is completely and totally fucked. I cannot support a project that doesn't build and strengthen the underlying WoT. Getting https involved for authenticating unknown keys is a huge s…

We're not big fans of browser PKI either, but we're using it as scaffolding that hopefully one day can be torn down.

`keybase-installer` needs an initial install over https from npm. We unfortunately saw no way around this.

Assuming that install succeeds with integrity, then all future upgrades of the installer and client are verified with PGP keys stored locally on the client.

Once the client is installed, it speaks HTTPS to the server, but we're not trusting the root CA. Rather, we sign with our own CA that we ship with the client.

The proofs themselves, on twitter and github, all can be verified in the clear, as FiloSottile points out, but of course relying upon the HTTPS certificates of twitter and github to make sure the proofs weren't corrupted in transit between those services and the client.

Re: Keybase.io

#56

Post by maxtaco »

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…

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 your GPG fingerprint). We want it to be checkable by user-friendly software.

Re: Keybase.io

#59

Post by carbocation »

Am I correct in thinking that this would not prevent a targeted MITM where an attacker generates a "valid" cert that allows them to serve up a modified response for the Twitter and Github public key verification requests (say, providing you with an alternative public key)?

Re: Keybase.io

#60

Post by ParadisoShlee »

zobzu wrote: post #5

https://sks-keyservers.net/ Advantage: it's distributed

I love sks as much as the next GPG user, but this is about as clean as I'd expect from a user friendly keyserver.

Sounds like a datamining goldmine too, but what do you expect from OkCupid founders.

btw had to do it. https://i.imgflip.com/6w8mc.jpg

Post reply on HN