6 ms·

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

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.
    - aragot 13y ago
      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.
  - tptacek 13y ago
    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 designed to make content-controlled code "auditable"; it simply isn't a capability of the environment.
    - chaitanya 13y ago
      FWIW, I found your post "Javascript Cryptography Considered Harmful" very helpful in understanding problems with client side crypto in the browser. I will recommend it to anyone who thinks it is safe: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
    - e_proxus 13y ago
      And don't forget all extensions which can "Access all your data on all webpages, Access all your tabs and browsing activity".
    - jessaustin 13y ago
      If this functionality were provided by e.g. a signed extension (so the code can't be changed without the user being told: I think browsers can do this?), then you would worry mostly about how well that extension was sandboxed away from other extensions and various websites, right?
- bascule 13y ago
  Yes, you are correct. Unless browser extensions are used (and even then) the web is not a good platform for cryptography. The web is a platform for letting a potential attacker run untrusted code on your computer without all hell breaking loose, not for building trusted cryptography applications: http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto
malgorithms 13y ago
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.
- theboss 13y ago
  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.
  - malgorithms 13y ago
    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.
    - midas007 13y ago
JustARandomGuy 13y ago
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? Again, thanks so much, and it looks like a terrific site so far.
- malgorithms 13y ago
  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 wouldn't work with Keybase. So any given identity check has to match some human definition of what it means to have that identity. And it has to be publicly auditable. With twitter, it's the ability to post a tweet under a certain username. With owning a tumblr account, it might be something similar. With your known StackExchange profile it might mean posting a statement in a specific part of your profile. And so on. The common thread in each case is (1) that you post in a place where only your identity can, and (2) what you post is a signed statement claiming a connection among three things: (a) your keybase username, (b) your public key, and (3) the identity on that third party service. (The third one is necessary so it can't be moved elsewhere.) Note how twitter and github's are totally different, but achieving these three things. We will build out this list of identity checks, hopefully making all kinds of them easy to do. Everything from proving you own a domain to having a tumblr or reddit accoun. The definition of those checks will all be publicly reviewable, both in the spec and in the client, which is what checks them for you.
  - ghayes 13y ago
    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?
huhtenberg 13y ago
Chris, a bit OT, but who made the illustrations for the site? They are incredible.
- pritambaral 13y ago
  I think https://keybase.io/chadilaksono https://keybase.io/chadilaksono did. Mentioned near the footer of the main site. Her portfolio: http://www.hadilaksono.com/ http://www.hadilaksono.com/
  - malgorithms 13y ago
    confirmed, yes! Caroline is doing both the artwork and the site design. She's a wonderful artist and we're lucky to work with her. Note the site isn't done yet, so anything that looks funny or imbalanced is not her fault but mine.
riquito 13y ago
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... I looked up for 'maria', all ascii. The answer, served by a malicious server, contains the first 'a' of maria in Cyrillic (check yourself, you'll see that 'mаria_leah' != 'maria_leah'). This would fool the user. 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.
- riquito 13y ago
  I wrote "man in the middle" attack, but that's wrong, since the connection is over https. The point is still valid if the server is compromised (or managed by evil people).
- malgorithms 13y ago
  Hi riquito - this is a very legitimate concern, and it has to be reviewed individually for each type of proof keybase supports, in the client. With twitter, keybase, and github, you can't have a username containing any character other than an alphanumeric, dash, or underscore. Which means this kind of attack is impossible. But for future identity proofs (domains, for example, which we've yet to implement), this kind of attack is real. Our approach here will be that anything outside of normal ascii will be highlighted and addressed to the user, as a serious warning.
  - riquito 13y ago
    These are good news. Thank you and good work!
abvdasker 13y ago
Glad to see you're focused on improving, but you're being too hard on yourself. The design is good as is imho (not that there isn't room for improvement). And the idea itself is pretty genius, so I'd say you're ok even if you don't immediately achieve the level of polish you're shooting for. Great idea and good luck!
murbard2 13y ago
Could you do email verification by emailing a challenge to users, and having them reply with a signature of the challenge combined with their email address? It does demonstrate control of the email account, and you cannot fake it either.
taralx 13y ago
Hi Chris - it looks like a neat idea. One question: Is this another global namespace, or do you plan to support pet names?

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.
  - aragot 13y ago
    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.
- tptacek 13y ago
  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 designed to make content-controlled code "auditable"; it simply isn't a capability of the environment.
  - chaitanya 13y ago
    FWIW, I found your post "Javascript Cryptography Considered Harmful" very helpful in understanding problems with client side crypto in the browser. I will recommend it to anyone who thinks it is safe: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
  - e_proxus 13y ago
    And don't forget all extensions which can "Access all your data on all webpages, Access all your tabs and browsing activity".
  - jessaustin 13y ago
    If this functionality were provided by e.g. a signed extension (so the code can't be changed without the user being told: I think browsers can do this?), then you would worry mostly about how well that extension was sandboxed away from other extensions and various websites, right?
bascule 13y ago
Yes, you are correct. Unless browser extensions are used (and even then) the web is not a good platform for cryptography. The web is a platform for letting a potential attacker run untrusted code on your computer without all hell breaking loose, not for building trusted cryptography applications: http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto

malgorithms 13y ago

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.

theboss 13y ago
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.
- malgorithms 13y ago
  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.
  - midas007 13y ago

JustARandomGuy 13y ago

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? Again, thanks so much, and it looks like a terrific site so far.

malgorithms 13y ago
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 wouldn't work with Keybase. So any given identity check has to match some human definition of what it means to have that identity. And it has to be publicly auditable. With twitter, it's the ability to post a tweet under a certain username. With owning a tumblr account, it might be something similar. With your known StackExchange profile it might mean posting a statement in a specific part of your profile. And so on. The common thread in each case is (1) that you post in a place where only your identity can, and (2) what you post is a signed statement claiming a connection among three things: (a) your keybase username, (b) your public key, and (3) the identity on that third party service. (The third one is necessary so it can't be moved elsewhere.) Note how twitter and github's are totally different, but achieving these three things. We will build out this list of identity checks, hopefully making all kinds of them easy to do. Everything from proving you own a domain to having a tumblr or reddit accoun. The definition of those checks will all be publicly reviewable, both in the spec and in the client, which is what checks them for you.
- ghayes 13y ago
  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?

huhtenberg 13y ago

Chris, a bit OT, but who made the illustrations for the site? They are incredible.

pritambaral 13y ago
I think https://keybase.io/chadilaksono https://keybase.io/chadilaksono did. Mentioned near the footer of the main site. Her portfolio: http://www.hadilaksono.com/ http://www.hadilaksono.com/
- malgorithms 13y ago
  confirmed, yes! Caroline is doing both the artwork and the site design. She's a wonderful artist and we're lucky to work with her. Note the site isn't done yet, so anything that looks funny or imbalanced is not her fault but mine.

riquito 13y ago

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... I looked up for 'maria', all ascii. The answer, served by a malicious server, contains the first 'a' of maria in Cyrillic (check yourself, you'll see that 'mаria_leah' != 'maria_leah'). This would fool the user. 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.

riquito 13y ago
I wrote "man in the middle" attack, but that's wrong, since the connection is over https. The point is still valid if the server is compromised (or managed by evil people).
malgorithms 13y ago
Hi riquito - this is a very legitimate concern, and it has to be reviewed individually for each type of proof keybase supports, in the client. With twitter, keybase, and github, you can't have a username containing any character other than an alphanumeric, dash, or underscore. Which means this kind of attack is impossible. But for future identity proofs (domains, for example, which we've yet to implement), this kind of attack is real. Our approach here will be that anything outside of normal ascii will be highlighted and addressed to the user, as a serious warning.
- riquito 13y ago
  These are good news. Thank you and good work!

abvdasker 13y ago

Glad to see you're focused on improving, but you're being too hard on yourself. The design is good as is imho (not that there isn't room for improvement). And the idea itself is pretty genius, so I'd say you're ok even if you don't immediately achieve the level of polish you're shooting for. Great idea and good luck!

murbard2 13y ago

Could you do email verification by emailing a challenge to users, and having them reply with a signature of the challenge combined with their email address? It does demonstrate control of the email account, and you cannot fake it either.

taralx 13y ago

Hi Chris - it looks like a neat idea. One question: Is this another global namespace, or do you plan to support pet names?