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

31–40 of 125 posts

Re: Keybase.io

#31

Post by sneak »

jonesetc wrote: post #21
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…

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

Re: Keybase.io

#32

Post by bqe »

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…

I don't understand how using HTTPS for the API has any bearing whatsoever on the WoT built via PGP.

You can still verify the keys with your client's cached copies, or using another PGP client.

Re: Keybase.io

#33

Post by FiloSottile »

bqe wrote: post #32
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…

I don't understand how using HTTPS for the API has any bearing whatsoever on the WoT built via PGP. You can still verify the keys with your client's cached copies, or using another PGP client.

Exactly, and moreover. If there is no trust in the server, everything can even go over unencrypted HTTP. CAs have no business here.

Re: Keybase.io

#34

Post by FiloSottile »

sneak wrote: post #27

I really, really want crypto, specifically, safe and secure-by-default crypto, to become much more usable. Despite this hope, I can't seem to help the fact that the first thing that popped into my head when I read their webpage is "oh, they're wrapping and abstracting important key authentication and critical key trust configuration to make it more user-friendly, and implementing it all in javascript. WHAT COULD POSS…

As long as the trust model is that the server is untrusted, it can be written in the language they prefer. As for the client, there can be as many implementations in as many languages as needed to make everyone happy IMHO (they call it reference client in the home).

Re: Keybase.io

#35

Post by jonesetc »

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…

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.

Re: Keybase.io

#36

Post by ghayes »

malgorithms wrote: post #20
JustARandomGuy wrote: post #11

Earlier quoted context omitted.

Hi Chris, a few comments: 1. I like the site design, the story flow on the front page does a great job of explaining what keybase is. 2. I see (from the abovementioned story flow) that keys can be verified by reviewing signed tweets/gists. Is this functionality extendable to arbitrary links; i.e. verifying keys against personal blogs, Tumblr, WordPress or does the third-party site need to implement a recognized API?…

Good question! There will be no such thing as a general check, because -- for any identity -- the client software has to perform a check that a human would agree means something. For example, what does it mean that you own a certain blog? How would a person confirm it? Well, at first glance it might mean that you have the power to post a message there. But someone else could do that it in a comment, and so that would…

Well, to follow up, could this be extended to ownership of a domain (via DNS txt record)? Could we use this as a means of authentication of a self-signed certificate for a domain?

Re: Keybase.io

#37

Post by kzahel »

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…

That sounds like an interesting use case, to have a browser API whereby an extension can disable other extensions from having access to certain domains. Perhaps you should submit a proposal and/or start a discussion on the appropriate mailing lists or bug trackers.

Re: Keybase.io

#39

Post by malgorithms »

malgorithms wrote: post #8

Hi everyone, Chris here, I've been working with Max on Keybase. I can't help but feel this ended up scooped a bit early. (Crap!) Not a surprise, because HN is quick. The alpha site's changing every day, and we're working on the documentation now. I don't use the term "alpha" loosely. There will be extensive security details published, explaining every aspect of the identity proof system, client sessions, etc. They wi…

There were multiple questions/comments below about this, so I felt I should clarify one detail about the keybase client's trust of the server. When the keybase client requests maria's key from the keybase server, it does not simply trust the public key because it trusts the server (or uses https - huh?).

Rather, the server replies with links to tweets, gists, etc. -- maria's public identity proofs. The keybase client does not trust that these are honest, so it scrapes them directly and makes sure they were signed by the same public key that the server provided. In other words, the server could reply with a different maria, and simply lie, but not with the real maria's github or twitter account.

The server could also lie by omission, leaving out an identity. But it cannot invent ones that do not exist, without the client knowing.

Again, the premise here is that maria is the sum of her online identities.

The website itself is of course a different story. When you look up maria on keybase's website, you are trusting that keybase.io did not lie about her github account. Fortunately you can confirm by following the link to her gist, where she announced her keybase username and posted her key fingerprint.

Re: Keybase.io

#40

Post by theboss »

jonesetc wrote: post #35
sneak wrote: post #31

Earlier quoted context omitted.

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…

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.

Post reply on HN