14 ms·

Keybase.io

409 points by andybons 13y ago

jszmajda 13y ago
Awesome! Unix `finger` is back! I loved that tool!
sneak 13y ago
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!
- FiloSottile 13y ago
  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).
- aidos 13y ago
  Honest question, which part of writing it in JS makes it less safe? I understand that running in a browser is an inherently unsafe model because of the various mechanisms that make it impossible to track code that's running along side yours. How is it that JS is unsafe in a server environment?
  - sneak 13y ago
    The median programmers it attracts to write it.
    - aidos 13y ago
      Argh. That barely warrants a response. The average skill of developers using a language is low, therefore it's not possible for anything written in the language to be of high quality? Wow. Even assuming that the initial assertion is correct, that's horrifically illogical. True reason: you have an anti-js bias. You're welcome to that, but for goodness sake be rational in your hatred.
- midas007 13y ago
  LOL. http://tobtu.com/decryptocat.php http://tobtu.com/decryptocat.php On a serious matter, javascript (eg all browsers) absolutely needs to change to make the web more trustworthy. I agree with some of the Matasano points[0], but these are the minimum, exhaustively complete changes that would improve browser security: i. js that can be cryptographically signed and verified, a trust model and a browser security policy to enforce it. Think ascii armored GPG signature as a comment for the code it encloses. ii. js native extensions: able to talk to native code that was previously installed iii. js objects that can be made immutable (can't change them in any way) iv. js objects that can be made un-protypable (can't copy or "subclass" them) v. js properties that can be made read-only vi. js properties that can be made private (only the object itself can use them) With folks pushing to make this happen across all browsers, javascript theft of bank passwords and credit card numbers would be much harder. Crypto stuff like the Stanford library would benefit. References: 0. http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ 1. https://crypto.stanford.edu/sjcl/ https://crypto.stanford.edu/sjcl/
  - midas007 13y ago
    As an update, I was hacking on https://github.com/moxie0/Convergence https://github.com/moxie0/Convergence to try to get it working on modern FF. FF supports binding system libraries to JS objects. (If anyone knows how to modernize a FF extension, please help: https://github.com/moxie0/Convergence/issues/178 https://github.com/moxie0/Convergence/issues/178)
geerlingguy 13y ago
On iPhone, I only see a graphic and login/registration links; can someone describe/summarize the service?
sneak 13y ago
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.
- bqe 13y ago
  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.
  - FiloSottile 13y ago
    Exactly, and moreover. If there is no trust in the server, everything can even go over unencrypted HTTP. CAs have no business here.
- maxtaco 13y ago
  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.
  - sneak 13y ago
    > `keybase-installer` needs an initial install over https from npm. We unfortunately saw no way around this. Write it in a language that has a packaging system not designed by amateurs.
read 13y ago
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 http://en.wikipedia.org/wiki/Proof-carrying_code
- kzahel 13y ago
  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.
- IgorPartola 13y ago
  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.
  - read 13y ago
    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.
dmix 13y ago
There should be a big sign-up call-to-action button. You're missing out on tons of potential users.
IgorPartola 13y ago
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?
- maxtaco 13y ago
  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).
  - IgorPartola 13y ago
    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.
jl2975 13y ago
sweet site
mbreese 13y ago
What does this do? The mobile site has zero information, just a form to sign up.
luke-stanley 13y ago
Is it FOSS?
carbocation 13y ago
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)?
sfeng 13y ago
I've got to say this site does 'responsive design' the exact wrong way. On small screens all the words are hidden explaining what it actually is, instead you just get a giant meaningless image and buttons with no context.
jlafon 13y ago
This looks pretty cool! I like the story flow. You might want to include some links that explain what the keys are, what PGP is, etc - because not everyone who lands on your site will know.
Sir_Cmpwn 13y ago
Styles are broken on Firefox, text is flowing off the right side of the screen. Why do lots of sites seem to have forgotten about testing on Firefox recently?
- rch 13y ago
  The whole thing seems to be very early alpha. I'm sure that will be taken care of a little further down the road. As a former Opera user, I certainly sympathize though.
- 8_hours_ago 13y ago
  It has the same text flow issue with Chromium so I'm guessing that they didn't do much testing at all. Furthermore, using a narrow window results in absolutely no information on the front page except "Join" and "Login" links. For reference, I'm using Firefox 25.0.1 and Chromium 30.0.1599.11 in Linux.
theboss 13y ago
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, but how about more obscure services? One mistake in one single account causes the entire thing to fall apart...
- caf 13y ago
  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).
  - andrewaylett 13y ago
    s/could/should/?
    - caf 13y ago
      Only if you don't trust your copy of the keybase client (as opposed to the server, which you should not need to trust).
- maxtaco 13y ago
  As Chris said, we would like to publish everything, just haven't found the time yet. We have bits and pieces in wikis in our various github repositories (almost all of which are open source and public). The high bits are: all crypto is with GPG/RSA as per RFC4880. There are of course problems here, but we wanted backwards-compatibility and well-tested, well-used clients. We encrypt server-stored GPG private keys (if you choose to use that option) with TripleSec (see https://keybase.io/triplesec https://keybase.io/triplesec). Users use GPG to sign a series of JSON objects, of the form "I'm maxtaco on twitter", or "I checked Chris's proofs as of 2014/2/14 and they look good to me." All JSON objects that a user signs are chained together with SHA-2 hashes. So a user can sign the whole group of JSON statements by just signing the most recent one. Here's an example (click on "Show the Proof") https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1WuaT59 https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1Wu... There's a fair amount of engineering that went into the software distribution system. We rely first on npm to get the initial client out there, but after that, exclusively GPG for code-signing. That's documented here: https://github.com/keybase/node-installer/wiki/Update-Architecture https://github.com/keybase/node-installer/wiki/Update-Archit... We hope to have better documentation soon, and we value feedback, we just haven't had the time to put it together yet.
zobzu 13y ago
https://sks-keyservers.net/ https://sks-keyservers.net/ Advantage: it's distributed
- ParadisoShlee 13y ago
  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 https://i.imgflip.com/6w8mc.jpg
  - zobzu 13y ago
    i'm surprised by the number of comments which attempt to mock SKS because "the UI is not nice looking" "the url sucks to remember". I'm like, wow, if that's the only issue, that's great lol. Sounds pretty easy to fix ;-)
- primitivesuave 13y ago
  Disadvantage: it doesn't have a memorable name like keybase.io
- philfreo 13y ago
  Disadvantage: this site does nothing to make cryptography more accessible / easy to use for the common person.
  - diasp 13y ago
    Try https://encrypt.to/ https://encrypt.to/ to send encrypted messages by one click :)
  - midas007 13y ago
    Accessibility should not introduce a SPoF. What happens when Snowden uses it and the USG requests access? Oops. Businesses / nonprofits cannot provide privacy-as-a-service unless they're "SWAT proof" (distributed). Advantage: SKS is "SWAT proof."
electic 13y ago
This is totally off-topic however I really like the graphic at the bottom of the page. The graphic really sums up the challenges developers have in creating secure communication channels. There are so many threats now a days it seems overwhelming.
malgorithms 13y ago
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 will be on the site before we open general access or turn beta. Right now only a few friends are on there. All that said, Max and I can answer questions here. My profile on the site is https://keybase.io/chris https://keybase.io/chris if anyone wants to look. My profile demonstrates early examples of how identity proofs will work, including both twitter and github. We'll of course be adding other public identities in the future. The site design is also very iffy at the moment; I was about to move into firefox bugs tomorrow.
- sweis 13y ago
  Even though there is a disclaimer, I think the "encrypt in your browser" feature (https://keybase.io/encrypt 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.
  - maxtaco 13y ago
    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.
    - sweis 13y ago
      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.
pknight 13y ago
Just want to say cool art work on the landing page
- apgwoz 13y ago
  Done by the extra talented Caroline Hadilaksono! http://www.hadilaksono.com/ http://www.hadilaksono.com/
  - scotty79 13y ago
    For me it increased the perceived trustworthiness of the website 10 times. I've seen illustrations drawn in similar style in Scientfic Amercian and subconsciously carried over the trust I have for SA to this site.
- cpach 13y ago
  It's very charming!
deleted 13y ago
[deleted]
addisonj 13y ago
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!
- malgorithms 13y ago
  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?
- alokv28 13y ago
  Same boat here! Any sense of how long the queue is?
Stealth- 13y ago
This is great. Proper cryptography is the solution to so many of the problems the modern internet is facing right now, but the key problem with cryptography is that it is never user friendly enough and never distributed enough. This looks like a great step in the right direction.
- fsiefken 13y ago
  What do you think of http://invictus.io/keyhotee.php http://invictus.io/keyhotee.php user friendly and distributed identity
IgorPartola 13y ago
Cannot tell what this does on a mobile browser.
- lallysingh 13y ago
  This, exactly. All I see are two buttons, Join and Login. But no description, no clue, nothing on what I'm being offered to join our log into.
rinon 13y ago
Very cool idea. The idea of automatically verifying public keys over publicly accessible and known channels is great. This is more or less the manual process I follow when I want to verify a key remotely. Looking forward to seeing where this goes! Also, being able to use this with arbitrary crypto software (eg GPG) would be even better!
jonesetc 13y ago
Is there a way to remove an associated account?
- maxtaco 13y ago
  Yes, though it might be broken right now. Our plan is to allow this, for sure.
- steveklabnik 13y ago
  http://pgp.mit.edu:11371/faq.html?search=foo http://pgp.mit.edu:11371/faq.html?search=foo
  - jonesetc 13y ago
    Right, but this isn't just a keyserver. They are allowed to break those rules in their service if they wish.
    - steveklabnik 13y ago
      Sure, just pointing out that it's still basically useless.
diasp 13y ago
Interesting. Another approach is https://encrypt.to/ https://encrypt.to/ which loads the public key from key servers and encrypts client-side via JS.
- malgorithms 13y ago
  To clarify the difference, it seems encrypt.to is a service which does PGP crypto in the browser, based on keys pulled from keyservers. In contrast, Keybase is an identity-proving service, which proves key X belongs to person with twitter account Y, github account Z, etc. As a convenience, it also does encryption and other crypto actions for its users.
yeukhon 13y ago
This 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 :)
g3orge 13y ago
but... node? really?
fiatjaf 13y ago
This is awesome. We didn't anyone did this before?
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]

409 points by andybons 13y ago

Awesome! Unix `finger` is back! I loved that tool!

sneak 13y ago

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!

FiloSottile 13y ago
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).
aidos 13y ago
Honest question, which part of writing it in JS makes it less safe? I understand that running in a browser is an inherently unsafe model because of the various mechanisms that make it impossible to track code that's running along side yours. How is it that JS is unsafe in a server environment?
- sneak 13y ago
  The median programmers it attracts to write it.
  - aidos 13y ago
    Argh. That barely warrants a response. The average skill of developers using a language is low, therefore it's not possible for anything written in the language to be of high quality? Wow. Even assuming that the initial assertion is correct, that's horrifically illogical. True reason: you have an anti-js bias. You're welcome to that, but for goodness sake be rational in your hatred.
midas007 13y ago
LOL. http://tobtu.com/decryptocat.php http://tobtu.com/decryptocat.php On a serious matter, javascript (eg all browsers) absolutely needs to change to make the web more trustworthy. I agree with some of the Matasano points[0], but these are the minimum, exhaustively complete changes that would improve browser security: i. js that can be cryptographically signed and verified, a trust model and a browser security policy to enforce it. Think ascii armored GPG signature as a comment for the code it encloses. ii. js native extensions: able to talk to native code that was previously installed iii. js objects that can be made immutable (can't change them in any way) iv. js objects that can be made un-protypable (can't copy or "subclass" them) v. js properties that can be made read-only vi. js properties that can be made private (only the object itself can use them) With folks pushing to make this happen across all browsers, javascript theft of bank passwords and credit card numbers would be much harder. Crypto stuff like the Stanford library would benefit. References: 0. http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ 1. https://crypto.stanford.edu/sjcl/ https://crypto.stanford.edu/sjcl/
- midas007 13y ago
  As an update, I was hacking on https://github.com/moxie0/Convergence https://github.com/moxie0/Convergence to try to get it working on modern FF. FF supports binding system libraries to JS objects. (If anyone knows how to modernize a FF extension, please help: https://github.com/moxie0/Convergence/issues/178 https://github.com/moxie0/Convergence/issues/178)

geerlingguy 13y ago

On iPhone, I only see a graphic and login/registration links; can someone describe/summarize the service?

sneak 13y ago

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.

bqe 13y ago
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.
- FiloSottile 13y ago
  Exactly, and moreover. If there is no trust in the server, everything can even go over unencrypted HTTP. CAs have no business here.
maxtaco 13y ago
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.
- sneak 13y ago
  > `keybase-installer` needs an initial install over https from npm. We unfortunately saw no way around this. Write it in a language that has a packaging system not designed by amateurs.

read 13y ago

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 http://en.wikipedia.org/wiki/Proof-carrying_code

kzahel 13y ago
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.
IgorPartola 13y ago
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.
- read 13y ago
  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.

dmix 13y ago

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

IgorPartola 13y ago

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?

maxtaco 13y ago
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).
- IgorPartola 13y ago
  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.

jl2975 13y ago

sweet site

mbreese 13y ago

What does this do? The mobile site has zero information, just a form to sign up.

luke-stanley 13y ago

Is it FOSS?

carbocation 13y ago

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

sfeng 13y ago

I've got to say this site does 'responsive design' the exact wrong way. On small screens all the words are hidden explaining what it actually is, instead you just get a giant meaningless image and buttons with no context.

jlafon 13y ago

This looks pretty cool! I like the story flow. You might want to include some links that explain what the keys are, what PGP is, etc - because not everyone who lands on your site will know.

Sir_Cmpwn 13y ago

Styles are broken on Firefox, text is flowing off the right side of the screen. Why do lots of sites seem to have forgotten about testing on Firefox recently?

rch 13y ago
The whole thing seems to be very early alpha. I'm sure that will be taken care of a little further down the road. As a former Opera user, I certainly sympathize though.
8_hours_ago 13y ago
It has the same text flow issue with Chromium so I'm guessing that they didn't do much testing at all. Furthermore, using a narrow window results in absolutely no information on the front page except "Join" and "Login" links. For reference, I'm using Firefox 25.0.1 and Chromium 30.0.1599.11 in Linux.

theboss 13y ago

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, but how about more obscure services? One mistake in one single account causes the entire thing to fall apart...

caf 13y ago
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).
- andrewaylett 13y ago
  s/could/should/?
  - caf 13y ago
    Only if you don't trust your copy of the keybase client (as opposed to the server, which you should not need to trust).
maxtaco 13y ago
As Chris said, we would like to publish everything, just haven't found the time yet. We have bits and pieces in wikis in our various github repositories (almost all of which are open source and public). The high bits are: all crypto is with GPG/RSA as per RFC4880. There are of course problems here, but we wanted backwards-compatibility and well-tested, well-used clients. We encrypt server-stored GPG private keys (if you choose to use that option) with TripleSec (see https://keybase.io/triplesec https://keybase.io/triplesec). Users use GPG to sign a series of JSON objects, of the form "I'm maxtaco on twitter", or "I checked Chris's proofs as of 2014/2/14 and they look good to me." All JSON objects that a user signs are chained together with SHA-2 hashes. So a user can sign the whole group of JSON statements by just signing the most recent one. Here's an example (click on "Show the Proof") https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1WuaT59 https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1Wu... There's a fair amount of engineering that went into the software distribution system. We rely first on npm to get the initial client out there, but after that, exclusively GPG for code-signing. That's documented here: https://github.com/keybase/node-installer/wiki/Update-Architecture https://github.com/keybase/node-installer/wiki/Update-Archit... We hope to have better documentation soon, and we value feedback, we just haven't had the time to put it together yet.

zobzu 13y ago

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

ParadisoShlee 13y ago
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 https://i.imgflip.com/6w8mc.jpg
- zobzu 13y ago
  i'm surprised by the number of comments which attempt to mock SKS because "the UI is not nice looking" "the url sucks to remember". I'm like, wow, if that's the only issue, that's great lol. Sounds pretty easy to fix ;-)
primitivesuave 13y ago
Disadvantage: it doesn't have a memorable name like keybase.io
philfreo 13y ago
Disadvantage: this site does nothing to make cryptography more accessible / easy to use for the common person.
- diasp 13y ago
  Try https://encrypt.to/ https://encrypt.to/ to send encrypted messages by one click :)
- midas007 13y ago
  Accessibility should not introduce a SPoF. What happens when Snowden uses it and the USG requests access? Oops. Businesses / nonprofits cannot provide privacy-as-a-service unless they're "SWAT proof" (distributed). Advantage: SKS is "SWAT proof."

electic 13y ago

This is totally off-topic however I really like the graphic at the bottom of the page. The graphic really sums up the challenges developers have in creating secure communication channels. There are so many threats now a days it seems overwhelming.

malgorithms 13y ago

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 will be on the site before we open general access or turn beta. Right now only a few friends are on there. All that said, Max and I can answer questions here. My profile on the site is https://keybase.io/chris https://keybase.io/chris if anyone wants to look. My profile demonstrates early examples of how identity proofs will work, including both twitter and github. We'll of course be adding other public identities in the future. The site design is also very iffy at the moment; I was about to move into firefox bugs tomorrow.

sweis 13y ago
Even though there is a disclaimer, I think the "encrypt in your browser" feature (https://keybase.io/encrypt 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.
- maxtaco 13y ago
  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.
  - sweis 13y ago
    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.

pknight 13y ago

Just want to say cool art work on the landing page

apgwoz 13y ago
Done by the extra talented Caroline Hadilaksono! http://www.hadilaksono.com/ http://www.hadilaksono.com/
- scotty79 13y ago
  For me it increased the perceived trustworthiness of the website 10 times. I've seen illustrations drawn in similar style in Scientfic Amercian and subconsciously carried over the trust I have for SA to this site.
cpach 13y ago
It's very charming!

deleted 13y ago

[deleted]

addisonj 13y ago

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!

malgorithms 13y ago
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?
alokv28 13y ago
Same boat here! Any sense of how long the queue is?

Stealth- 13y ago

This is great. Proper cryptography is the solution to so many of the problems the modern internet is facing right now, but the key problem with cryptography is that it is never user friendly enough and never distributed enough. This looks like a great step in the right direction.

fsiefken 13y ago
What do you think of http://invictus.io/keyhotee.php http://invictus.io/keyhotee.php user friendly and distributed identity

IgorPartola 13y ago

Cannot tell what this does on a mobile browser.

lallysingh 13y ago
This, exactly. All I see are two buttons, Join and Login. But no description, no clue, nothing on what I'm being offered to join our log into.

rinon 13y ago

Very cool idea. The idea of automatically verifying public keys over publicly accessible and known channels is great. This is more or less the manual process I follow when I want to verify a key remotely. Looking forward to seeing where this goes! Also, being able to use this with arbitrary crypto software (eg GPG) would be even better!

jonesetc 13y ago

Is there a way to remove an associated account?

maxtaco 13y ago
Yes, though it might be broken right now. Our plan is to allow this, for sure.
steveklabnik 13y ago
http://pgp.mit.edu:11371/faq.html?search=foo http://pgp.mit.edu:11371/faq.html?search=foo
- jonesetc 13y ago
  Right, but this isn't just a keyserver. They are allowed to break those rules in their service if they wish.
  - steveklabnik 13y ago
    Sure, just pointing out that it's still basically useless.

diasp 13y ago

Interesting. Another approach is https://encrypt.to/ https://encrypt.to/ which loads the public key from key servers and encrypts client-side via JS.

malgorithms 13y ago
To clarify the difference, it seems encrypt.to is a service which does PGP crypto in the browser, based on keys pulled from keyservers. In contrast, Keybase is an identity-proving service, which proves key X belongs to person with twitter account Y, github account Z, etc. As a convenience, it also does encryption and other crypto actions for its users.

yeukhon 13y ago

This 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 :)

g3orge 13y ago

but... node? really?

fiatjaf 13y ago

This is awesome. We didn't anyone did this before?

deleted 13y ago

[deleted]

deleted 13y ago

[deleted]