Just want to say cool art work on the landing page
It's very charming!
Keybase.io
81–90 of 125 posts
Re: Keybase.io
#82Earlier quoted context omitted.
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…
And don't forget all extensions which can "Access all your data on all webpages, Access all your tabs and browsing activity".
Re: Keybase.io
#83Hi 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…
Chris, a bit OT, but who made the illustrations for the site? They are incredible.
I think https://keybase.io/chadilaksono did. Mentioned near the footer of the main site.
Her portfolio: http://www.hadilaksono.com/
Re: Keybase.io
#84Hi 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…
The first thing I thought about is a man in the middle attack with homoglyphs. I don't know if I'm paranoid, but look at this
> keybase id maria
pgp: C4B3 15B4 7154 5281 5100 1C58 C2A5 977B 0022
github: mаria_leah ✓ https://gist.github.com/23423
twitter: mаria_h20 ✓ https://t.co/mаria_h20/523554
site: mаriah20.com ✓ https://mаriah20.com/X904F...
Maybe the client should apply some logic as browsers do for IDN homograph attack to show characters not in your locale in a different way, or at least warn you.
Re: Keybase.io
#85Earlier quoted context omitted.
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 nea…
Well if an attacker is successfully spoofing DNS, she can spoof MX records, thus getting emails for the domain, which is the only precondition on acquiring a certificate. You're obviously adding more complexity, butt security-wise it doesn't change much
Re: Keybase.io
#86Where 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 an…
s/could/should/?
Re: Keybase.io
#87This is effectively the same idea to provide your ownership of a domain. For example, if you want to use webmaster tool from Google you'd either insert a text in some file or modify the DNS A record to contain the expected text.
One thought is vouch and level of credibility by the person's profile. If a lot of people vocuhed for Maria or if Maria has a lot of active tweet and/or a lot of Github activity there is a good chance this is a real Maria. However, the activity-based credibility is easily forged and defeated so probably not a good idea to add, bur worth thinking about :)
Re: Keybase.io
#88Is 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 pag…
The point is to make it impossible to do what you just described.
For example, to make it impossible for code sent by a server to execute any Javascript (or other scripting languages) at all. The server could instead send a data structure (as opposed to code) describing what to do, without having the power to replace any encryption functions or to execute additional functions that can subvert encryption. I realize a first version of this might sound too restrictive, but the point here is to show how it can be made to work.
If it's possible to reduce what the server sent to the browser down to a fingerprint, it will also be possible for the browser extension to verify this fingerprint with multiple third parties. It can verify the fingerprint of the server code matches a fingerprint published on Twitter, or GitHub or other sources, which is something Keybase tries to do.
An attacker would need to break into all (or at least a majority) of those services to serve you bad code. Which is harder than breaking only into your server.
Forbidding other malicious browser extensions from interfering with a Keybase browser extension would allow the Keybase extension to perform all this fingerprint-checking logic with the guarantee the verification hasn't been tampered with.
Re: Keybase.io
#89Earlier quoted context omitted.
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.
But it's a good idea: Sign the js. Even md5 would be enough, it's just so that when the FBINSA subpoenas you, we'll know it.
Re: Keybase.io
#90Earlier 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…
I don't see how this is any better than a keyserver and just asking confirming their GPG fingerprint by some other means. Not knowing someone and guessing that their fingerprint is right from some third party is very sketchy because it doesn't use a trustworthy, authoritative source (the other person).
Also, WoT works best when people meet other people they trust in person and sign each other's keys as the GNU/Linux community encourages. https://www.kernel.org/signature.html Then it's possible to get other people's keys elsewhere on the planet and know they're probably good given they're signed by someone you trust.