Live data from Hacker News

Keybase.io

keybase.io

41–50 of 125 posts

Re: Keybase.io

#41
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…

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

Re: Keybase.io

#42

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…

I don't see why you don't just get the key once, allow you to verify it, and store it locally. It seems pointless to make all these extra requests to you.

There's a reason that gpg does this..... Maria's twitter being hacked, Maria's github being hacked, Maria's Keystore being hacked....a lot can go wrong.

There are still weaknesses like, you lie about a github and link to your own github, and lie about the public key. And...many others.

Re: Keybase.io

#43
There should be a big sign-up call-to-action button. You're missing out on tons of potential users.

Re: Keybase.io

#44
post #42

Earlier quoted context omitted.

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…

I don't see why you don't just get the key once, allow you to verify it, and store it locally. It seems pointless to make all these extra requests to you. There's a reason that gpg does this..... Maria's twitter being hacked, Maria's github being hacked, Maria's Keystore being hacked....a lot can go wrong. There are still weaknesses like, you lie about a github and link to your own github, and lie about the public ke…

yes, it does do this; once you're satisfied with maria's identity, that she's the person you want, you sign a statement to that effect, which you can store just locally or post back to the server. (or of course you can just sign her key in GPG!) The latter - posting back to the server - is for portability reasons. A keybase user will likely use keybase on multiple machines.

Re: Keybase.io

#45
post #36

Earlier quoted context omitted.

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?

Yes to DNS, though we have to be careful here since DNS can be spoofed more easily than github or twitter proofs over https. I was thinking a slightly better way to prove ownership of foo.com would be to post a proof at https://foo.com/_keybase (or something similar). To spoof this, an attacker would have to spoof DNS and also the https certificate.

Authenticating a self-signed domain certificate via keybase is a neat idea, but would probably need some browser support, unless there's a clever hack that I'm not thinking of.

Re: Keybase.io

#47
post #25

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…

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 insert malicious JavaScript into the client's browser. A read-only compromise of the server yields only encrypted data, and the server never has access to the decryption keys.

Re: Keybase.io

#48

Earlier quoted context omitted.

http://pgp.mit.edu:11371/faq.html?search=foo

Right, but this isn't just a keyserver. They are allowed to break those rules in their service if they wish.

Sure, just pointing out that it's still basically useless.

Re: Keybase.io

#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 if Maria never published a GPG key, but Chloe did using Maria's email address? Moreover, what if Chloe has access to Maria's inbox and can read these messages I believe to be only readable by Maria?

Edit: I see from responses below that various online presences of an identity tied to "maria" are checked. Is this not then susceptible to its own attack? For example, if Maria does not have a Twitter account and I create one, or compromise hers and post a different key, will I be able to at least introduce doubt into her identity, if not take it over outright?

Post reply on HN