7 ms·

Show HN: aes.io - secure storage/collaboration with client-side JS crypto

10 points by trekkin 14y ago

Piskvorrr 14y ago
Oblig: JavaScript crypto considered harmful. http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ The site doesn't address any of the concerns. Why? Well, because they can't. Client-side JS is fundamentally, unfixably insecure.
- ch0wn 14y ago
  This is no longer true. There exists the Stanford JavaScript Crypto Library authored by known experts, including Emily Stark, Mike Hamburg and Dan Boneh: http://crypto.stanford.edu/sjcl/ http://crypto.stanford.edu/sjcl/ I also suggest reading the paper that comes along with the library, addressing several of the common issues like randomness and entropy generation and integer calculations in JavaScript: http://crypto.stanford.edu/sjcl/acsac.pdf http://crypto.stanford.edu/sjcl/acsac.pdf
  - tinco 14y ago
    Matasano refers to SJCL in his article, it does not invalidate many of his points. If you had read his article you would know that it cannot simply be 'no longer true'. The article shows fundamental problems with security on the web and in javascript.
    - trekkin 14y ago
      The article assumes that the web service with JavaScript crypto is not using SSL. It explicitly says "And if you have SSL, why do you need Javascript crypto? Just use the SSL." aes.io uses SSL _and_ JS crypto on top of it to make sure server-side data is always encrypted, with keys unkown to the server side.
      - Piskvorrr 14y ago
        Bzzzt, strawman argument! You have addressed one point out of approximately 10 in the article and you are apparently assuming that it renders the remaining issues invalid. It doesn't.
      - tinco 14y ago
        So how do I know you (aes.io) changed the JS to leak my password to you? I can never be sure without comparing the JS you send me to some JS I know to be secure. disclaimer: I'm working on a client-side JS crypto web-app myself :P
        trekkin 14y ago
        That is true - if the server side is compromised, all bets are off. However, how this is different from, let's say, a compromised browser update? And good luck with you app - client-side JS crypto needs more dev attention. :)
        tptacek 14y ago
        I'll tell you how it's different: because you, the server operator, can at any time compromise the user. But you could not have compromised the integrity of their browser. Since the whole point of clientside encryption is to prevent the server from compromising data, the fact that the server retains the ability to do this almost defeats the purpose of encrypting.
        trekkin 14y ago
        There are two issues here, I think. One is intentional leakage, or trusting the vendor to be "not evil". Here you are right - as you mentioned in another comment, there is no easy way for users to "police" the vendor of JS crypto. I do not see, however, how this is different from users trusting other vendors of auto-updating software. You can probably argue that OSS pieces such as Linux and FF have this "policing" enabled through source code availability. But there are many closed-source vendors (Microsoft, Google, anti-virus vendors) that many users trust. If you don't trust the companies mentioned above, then yes, you should not trust aes.io and other JS-crypto based vendors. But if a user has Microsoft/Apple updates enabled, and browsers (other than FF) auto-updating on their systems, etc., then this becomes a question of vendor being "not evil", not weaknesses of JS crypto, and as such somewhat out of scope of scrictly "JS crypto - yes or no" discussion. The second issue here are unintentional leaks and breaches. Read-only breaches, for example, become more or less non-issue with JS crypto, because stealing properly encrypted data is not that useful. And there are probably orders of magnitude more read-only breaches than read-write, simply because inside companies more people have read-only access to production data than read-write access. Thus JS crypto seems to help substantially reduce the risk of unintentional compromises. The second issue needs more attention and discussion from the technical point of view, I agree, and I am open to it. The first issue, however, becomes "I trust this vendor but I don't trust that vendor", and this is not a discussion that I believe can be productive here and now.
  - tptacek 14y ago
    Did you actually read the SJCL page before you wrote this comment? Because it rebuts you.
- trekkin 14y ago
  The article has many points, but it seems that they can be grouped together around three themes: 1. very easy for MITM-type attacks: this is negated by using SSL 2. JavaScript is too "malleable" for crypto - this argument is not very clear; yes, JS is "malleable" - so what, if we can be reasonably sure it is not "infected", by using server-side tools like signatures and SSL? This is highly debatable... 3. server breaches easily propagate to users: this is a real issue, but it is a real issue with many products that auto-update themselves, such as OSes (with patches/updates), browsers, anti-viruses, etc. Thus although this is a valid concern, it is part of everyday life of most Internet users,and not something JS crypto is specifically bad at.
  - Piskvorrr 14y ago
    In other words, "I don't understand #2, so let's assume it's not a problem and handwave it away." Alas, it is a problem, and a critical one. Pray tell, how do you check the VM, from inside the VM sandbox? Guess what: you have no way to do that, not in JavaScript. That's another chicken-and-egg problem which is insurmountable with client-side, in-page JS.
    - trekkin 14y ago
      I cannot do that from inside the sandbox, but as I completely control the page, not just one script on it, I can be reasonably sure no rogue script is running on it (by using SSL). I've read the Matasano article, don't assume I didn't. Most of the points in it are negated by controlling the page 100% and using SSL.
      - tptacek 14y ago
        I'm confused. In way does your application protect users against you? You control the code that handles the users encryption secrets. Your users have no effective way to police you. Why not just have the users send you their plaintext, and rely on SSL/TLS for the rest of your security? It seems like that provides effectively the same security.
  - tptacek 14y ago
- tinco 14y ago
  Even though client-side JS has some fundamentally insecure properties it does not mean it can't be used for establishing reasonably secure communication. HTTPS suffers from some of those properties too and we rely on https for almost everything we do that requires some sort of security. If your site is entirely self-contained and transported in full over https with a trustable ssl certificate and your users are using reasonably secure passwords and run browsers with addons that respect the confidentiality of https communication then client-side js encryption might be a nice extra layer of data protection. It won't protect against the government probing, and it won't protect against a passionate lulz hacker. The government can always subpoena the host website, and force it to fetch the password from the user, thereby comprimising their data. The government also has access to ssl certificates so it could even do this without notifying the host website. You may assume that lulz hackers have similar capabilities. If you think about it straight, the only way this can be truly secure is with a browser extension that digitally signs and versions _all_ javascript on a website, and the signing is done by a fully trusted third party (which arguably don't exist).
  - tinco 14y ago
    There is one thing client side js does protect you against very well and that is simple sql-injection style vulnerabilities. Any database exposure vulnerability that does not compromise the host is fully mitigated by client side encryption. This is a very large class of vulnerabilities in the real world, so this is actually a very good case in favor of client side encryption.
    - tptacek 14y ago
      Uh, what? Losing the database is game over. The odds are very high that by losing the database loses command execution on the server.
      - tinco 14y ago
        Well that depends entirely on wether you've configured your environment securely. If your sql server runs as an unprivileged user preferably on a different machine this should not be an issue.
justauser 14y ago
Trekkin posted yesterday in the discussion regarding Microsoft's SkyDrive (http://news.ycombinator.com/item?id=4265621 http://news.ycombinator.com/item?id=4265621) and not being familiar with the project I asked him to post a ShowHN so more folks could chime in regarding the use of clientside JS cryptography. I asked about the library/implementation used and it is BouncyCastle compiled/convertered to JS using GWT. The common discussion/blog references I've also pointed out but for everyone else have a look at these: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... and http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ .
- trekkin 14y ago
  Thank you! The Matasano article, as I mentioned in another comment, for some reason assumes that SSL is not used, which is not the case with aes.io.
  - Piskvorrr 14y ago
    You are misrepresenting the article. SSL is only a mitigating factor.
  - eli 14y ago
    If you're already using SSL, why do you need client-side JS in the first place? I'm not sure I understand the use case.
  - tptacek 14y ago
    The article does not assume SSL isn't used. The article addresses JS cryptosystems in the presence of HTTPS/TLS from top to bottom. But we also go out of our way to discuss JS cryptography as an alternative to HTTPS, because that is how many people use it; for instance, to do challenge-response authentication for "secure login" without needing SSL. But that's a sideshow on this thread. The article squarely addresses exactly the application you've built, and in detail.
    - 14y ago
pwpwp 14y ago
Interesting. How difficult was it to get the Bouncy Castle crypto lib to compile with GWT?
- trekkin 14y ago
  Not difficult in theory - classes not supported by GWT (such as iostreams) are easily cut out; but in practice many array operations inside BigInteger needed to be carefully tweaked to work well when compiled into JS.
abemassry 14y ago
I went full server side encryption with https://truefriender.com https://truefriender.com I relied on SSL for the client to server communication. However the user holds a key that is not stored on the server, so without that key the text on the server is unreadable, if you try entering an incorrect PIN you can see what I mean. I've submitted to HN but didn't make the front page, check it out if you're interested in this stuff.
Toshio 14y ago
This site more or less does the same thing as deadrop.us so why do I need to sign up?
- trekkin 14y ago
  deadrop.us seems to be focused exclusively on short messages. aes.io, in addition to messages, supports file uploads and sharing, for example...

10 points by trekkin 14y ago

Oblig: JavaScript crypto considered harmful. http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ The site doesn't address any of the concerns. Why? Well, because they can't. Client-side JS is fundamentally, unfixably insecure.

ch0wn 14y ago
This is no longer true. There exists the Stanford JavaScript Crypto Library authored by known experts, including Emily Stark, Mike Hamburg and Dan Boneh: http://crypto.stanford.edu/sjcl/ http://crypto.stanford.edu/sjcl/ I also suggest reading the paper that comes along with the library, addressing several of the common issues like randomness and entropy generation and integer calculations in JavaScript: http://crypto.stanford.edu/sjcl/acsac.pdf http://crypto.stanford.edu/sjcl/acsac.pdf
- tinco 14y ago
  Matasano refers to SJCL in his article, it does not invalidate many of his points. If you had read his article you would know that it cannot simply be 'no longer true'. The article shows fundamental problems with security on the web and in javascript.
  - trekkin 14y ago
    The article assumes that the web service with JavaScript crypto is not using SSL. It explicitly says "And if you have SSL, why do you need Javascript crypto? Just use the SSL." aes.io uses SSL _and_ JS crypto on top of it to make sure server-side data is always encrypted, with keys unkown to the server side.
    - Piskvorrr 14y ago
      Bzzzt, strawman argument! You have addressed one point out of approximately 10 in the article and you are apparently assuming that it renders the remaining issues invalid. It doesn't.
    - tinco 14y ago
      So how do I know you (aes.io) changed the JS to leak my password to you? I can never be sure without comparing the JS you send me to some JS I know to be secure. disclaimer: I'm working on a client-side JS crypto web-app myself :P
      - trekkin 14y ago
        That is true - if the server side is compromised, all bets are off. However, how this is different from, let's say, a compromised browser update? And good luck with you app - client-side JS crypto needs more dev attention. :)
        tptacek 14y ago
        I'll tell you how it's different: because you, the server operator, can at any time compromise the user. But you could not have compromised the integrity of their browser. Since the whole point of clientside encryption is to prevent the server from compromising data, the fact that the server retains the ability to do this almost defeats the purpose of encrypting.
        trekkin 14y ago
        There are two issues here, I think. One is intentional leakage, or trusting the vendor to be "not evil". Here you are right - as you mentioned in another comment, there is no easy way for users to "police" the vendor of JS crypto. I do not see, however, how this is different from users trusting other vendors of auto-updating software. You can probably argue that OSS pieces such as Linux and FF have this "policing" enabled through source code availability. But there are many closed-source vendors (Microsoft, Google, anti-virus vendors) that many users trust. If you don't trust the companies mentioned above, then yes, you should not trust aes.io and other JS-crypto based vendors. But if a user has Microsoft/Apple updates enabled, and browsers (other than FF) auto-updating on their systems, etc., then this becomes a question of vendor being "not evil", not weaknesses of JS crypto, and as such somewhat out of scope of scrictly "JS crypto - yes or no" discussion. The second issue here are unintentional leaks and breaches. Read-only breaches, for example, become more or less non-issue with JS crypto, because stealing properly encrypted data is not that useful. And there are probably orders of magnitude more read-only breaches than read-write, simply because inside companies more people have read-only access to production data than read-write access. Thus JS crypto seems to help substantially reduce the risk of unintentional compromises. The second issue needs more attention and discussion from the technical point of view, I agree, and I am open to it. The first issue, however, becomes "I trust this vendor but I don't trust that vendor", and this is not a discussion that I believe can be productive here and now.
- tptacek 14y ago
  Did you actually read the SJCL page before you wrote this comment? Because it rebuts you.
trekkin 14y ago
The article has many points, but it seems that they can be grouped together around three themes: 1. very easy for MITM-type attacks: this is negated by using SSL 2. JavaScript is too "malleable" for crypto - this argument is not very clear; yes, JS is "malleable" - so what, if we can be reasonably sure it is not "infected", by using server-side tools like signatures and SSL? This is highly debatable... 3. server breaches easily propagate to users: this is a real issue, but it is a real issue with many products that auto-update themselves, such as OSes (with patches/updates), browsers, anti-viruses, etc. Thus although this is a valid concern, it is part of everyday life of most Internet users,and not something JS crypto is specifically bad at.
- Piskvorrr 14y ago
  In other words, "I don't understand #2, so let's assume it's not a problem and handwave it away." Alas, it is a problem, and a critical one. Pray tell, how do you check the VM, from inside the VM sandbox? Guess what: you have no way to do that, not in JavaScript. That's another chicken-and-egg problem which is insurmountable with client-side, in-page JS.
  - trekkin 14y ago
    I cannot do that from inside the sandbox, but as I completely control the page, not just one script on it, I can be reasonably sure no rogue script is running on it (by using SSL). I've read the Matasano article, don't assume I didn't. Most of the points in it are negated by controlling the page 100% and using SSL.
    - tptacek 14y ago
      I'm confused. In way does your application protect users against you? You control the code that handles the users encryption secrets. Your users have no effective way to police you. Why not just have the users send you their plaintext, and rely on SSL/TLS for the rest of your security? It seems like that provides effectively the same security.
- tptacek 14y ago
tinco 14y ago
Even though client-side JS has some fundamentally insecure properties it does not mean it can't be used for establishing reasonably secure communication. HTTPS suffers from some of those properties too and we rely on https for almost everything we do that requires some sort of security. If your site is entirely self-contained and transported in full over https with a trustable ssl certificate and your users are using reasonably secure passwords and run browsers with addons that respect the confidentiality of https communication then client-side js encryption might be a nice extra layer of data protection. It won't protect against the government probing, and it won't protect against a passionate lulz hacker. The government can always subpoena the host website, and force it to fetch the password from the user, thereby comprimising their data. The government also has access to ssl certificates so it could even do this without notifying the host website. You may assume that lulz hackers have similar capabilities. If you think about it straight, the only way this can be truly secure is with a browser extension that digitally signs and versions _all_ javascript on a website, and the signing is done by a fully trusted third party (which arguably don't exist).
- tinco 14y ago
  There is one thing client side js does protect you against very well and that is simple sql-injection style vulnerabilities. Any database exposure vulnerability that does not compromise the host is fully mitigated by client side encryption. This is a very large class of vulnerabilities in the real world, so this is actually a very good case in favor of client side encryption.
  - tptacek 14y ago
    Uh, what? Losing the database is game over. The odds are very high that by losing the database loses command execution on the server.
    - tinco 14y ago
      Well that depends entirely on wether you've configured your environment securely. If your sql server runs as an unprivileged user preferably on a different machine this should not be an issue.

justauser 14y ago

Trekkin posted yesterday in the discussion regarding Microsoft's SkyDrive (http://news.ycombinator.com/item?id=4265621 http://news.ycombinator.com/item?id=4265621) and not being familiar with the project I asked him to post a ShowHN so more folks could chime in regarding the use of clientside JS cryptography. I asked about the library/implementation used and it is BouncyCastle compiled/convertered to JS using GWT. The common discussion/blog references I've also pointed out but for everyone else have a look at these: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... and http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ .

trekkin 14y ago
Thank you! The Matasano article, as I mentioned in another comment, for some reason assumes that SSL is not used, which is not the case with aes.io.
- Piskvorrr 14y ago
  You are misrepresenting the article. SSL is only a mitigating factor.
- eli 14y ago
  If you're already using SSL, why do you need client-side JS in the first place? I'm not sure I understand the use case.
- tptacek 14y ago
  The article does not assume SSL isn't used. The article addresses JS cryptosystems in the presence of HTTPS/TLS from top to bottom. But we also go out of our way to discuss JS cryptography as an alternative to HTTPS, because that is how many people use it; for instance, to do challenge-response authentication for "secure login" without needing SSL. But that's a sideshow on this thread. The article squarely addresses exactly the application you've built, and in detail.
  - 14y ago

pwpwp 14y ago

Interesting. How difficult was it to get the Bouncy Castle crypto lib to compile with GWT?

trekkin 14y ago
Not difficult in theory - classes not supported by GWT (such as iostreams) are easily cut out; but in practice many array operations inside BigInteger needed to be carefully tweaked to work well when compiled into JS.

abemassry 14y ago

I went full server side encryption with https://truefriender.com https://truefriender.com I relied on SSL for the client to server communication. However the user holds a key that is not stored on the server, so without that key the text on the server is unreadable, if you try entering an incorrect PIN you can see what I mean. I've submitted to HN but didn't make the front page, check it out if you're interested in this stuff.

Toshio 14y ago

This site more or less does the same thing as deadrop.us so why do I need to sign up?

trekkin 14y ago
deadrop.us seems to be focused exclusively on short messages. aes.io, in addition to messages, supports file uploads and sharing, for example...