Live data from Hacker News

Keybase.io

keybase.io

21–30 of 125 posts

Re: Keybase.io

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

Re: Keybase.io

#22

Looks very cool, but one piece of feedback: Let the user know it is in invite-only beta on the homepage. I downloaded the command line util and tried to login, only to be let down :( Excited to try it out!

Hi addisonj - sorry about this. The site is clearer about this limitation. If you request access via the site now (just click join on there) and remind me this happened to you in the comment field, I'll move you forward in the queue. Sound good?

Re: Keybase.io

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

Re: Keybase.io

#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 POSSIBLY GO WRONG?"

Even if I got whacked on the head one day and suddenly loved javascript, I would not use it for certain projects when I wanted to be taken seriously by, say, cryptographers.

Then again, look at all the success cryptocat has had!

Re: Keybase.io

#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 step backwards. Madness.

Re: Keybase.io

#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 forbids all other extensions from modifying a page? This policy could be specific for a single website: Keybase.

Because if browsers could do that, they could then support proof carrying code, which could be used to verify Keybase hasn't been tortured into serving a custom, targeted JavaScript.

http://en.wikipedia.org/wiki/Proof-carrying_code

Post reply on HN