4 ms·

>terrible in-browser Javascript crypto I'm not a cryptographer by any means, but my first thought when reading that is can we make non-terrible in-browser java

>terrible in-browser Javascript crypto I'm not a cryptographer by any means, but my first thought when reading that is can we make non-terrible in-browser javascript crypto?

Aethaeryn 15y ago
One of the top Google results for "javascript cryptography" thoroughly attacks the concept, but I'm not an expert in the area so I can't refute or confirm its claims: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
- tkahn6 15y ago
  This is tptacek's company.
pgeorgi 15y ago
The main issue is the trust base. Allow the entire code base of a site to be pinned down to a cert (and that has to be done outside the website context, ie. in-browser), and you're halfway there. Say, a signed webapp manifest, listing all files that are supposed to be used in that context and their hashes. On first execution, the associated key is stored, maybe compared with third party knowledge about the site (not tampered with) and key (known not-trustworthy). After that, you know when someone else than the maintainer tampered with the code. With that you're down to trusting the maintainer. Which makes it as good as any other code distribution scheme.
oconnore 15y ago
It's not a problem with javascript so much as a problem with the issue of knowing what code is actually running in your browser.
m0nastic 15y ago
The short answer is "no, we can't" which every time someone proposes a new scheme seems to infuriate people (as though our inability to actually do it is a value judgement on whether or not it's a good idea).
- Estragon 15y ago
  Actually, I think in some limited circumstances, JS crypto could be useful for a kind of "separation of trust." For instance, I am considering a service at the moment which would involve people uploading confidential information. The uploads will be fairly large, so a lot of bandwidth will be required (optimistically assuming it gets traction.) One architecture I am considering is a small dedicated HTTPS server which provides a self-contained webpage-plus-JS program to encrypt the upload and send it for storage on Amazon S3. Then I will pull the results off Amazon and decrypt them on a machine which is not even connected to the network. The advantage to this architecture is that it will scale arbitrarily but require me to secure only relatively modest dedicated resources, despite being used for transmission of confidential information. Because it uses a dedicated HTTPS server serving a self-contained page doing all the crypto, it avoids tptacek's objections to JS crypto in the browser (E.g., the server can provide the random seed in the JS itself, HTTPS prevents MITM attacks, etc.) (Copied from http://news.ycombinator.com/item?id=3872007 http://news.ycombinator.com/item?id=3872007)
  - m0nastic 15y ago
    So, you're scheme would require the long answer... ;) Which is that it sounds rather complicated (which makes my security-sense go off, but certainly isn't a fatal indictment) and that I'd really need to either do an active evaluation of the system or get several reassurrances that someone else decent (ideally someone much smarter than me) did and it checked out before I'd be remotely comfortable using it or recommending it.
    - Estragon 15y ago
      That's fair enough. I was just pointing out that not every architecture involving in-browser JS crypto suffers from the problems tptacek detailed.
    - AUmrysh 15y ago
      Yeah, we need a crypto library like JQuery where it's open and people can use a common implementation.

>terrible in-browser Javascript crypto I'm not a cryptographer by any means, but my first thought when reading that is can we make non-terrible in-browser javascript crypto?

Aethaeryn 15y ago

One of the top Google results for "javascript cryptography" thoroughly attacks the concept, but I'm not an expert in the area so I can't refute or confirm its claims: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/

tkahn6 15y ago
This is tptacek's company.

pgeorgi 15y ago

The main issue is the trust base. Allow the entire code base of a site to be pinned down to a cert (and that has to be done outside the website context, ie. in-browser), and you're halfway there. Say, a signed webapp manifest, listing all files that are supposed to be used in that context and their hashes. On first execution, the associated key is stored, maybe compared with third party knowledge about the site (not tampered with) and key (known not-trustworthy). After that, you know when someone else than the maintainer tampered with the code. With that you're down to trusting the maintainer. Which makes it as good as any other code distribution scheme.

oconnore 15y ago

It's not a problem with javascript so much as a problem with the issue of knowing what code is actually running in your browser.

m0nastic 15y ago

The short answer is "no, we can't" which every time someone proposes a new scheme seems to infuriate people (as though our inability to actually do it is a value judgement on whether or not it's a good idea).

Estragon 15y ago
Actually, I think in some limited circumstances, JS crypto could be useful for a kind of "separation of trust." For instance, I am considering a service at the moment which would involve people uploading confidential information. The uploads will be fairly large, so a lot of bandwidth will be required (optimistically assuming it gets traction.) One architecture I am considering is a small dedicated HTTPS server which provides a self-contained webpage-plus-JS program to encrypt the upload and send it for storage on Amazon S3. Then I will pull the results off Amazon and decrypt them on a machine which is not even connected to the network. The advantage to this architecture is that it will scale arbitrarily but require me to secure only relatively modest dedicated resources, despite being used for transmission of confidential information. Because it uses a dedicated HTTPS server serving a self-contained page doing all the crypto, it avoids tptacek's objections to JS crypto in the browser (E.g., the server can provide the random seed in the JS itself, HTTPS prevents MITM attacks, etc.) (Copied from http://news.ycombinator.com/item?id=3872007 http://news.ycombinator.com/item?id=3872007)
- m0nastic 15y ago
  So, you're scheme would require the long answer... ;) Which is that it sounds rather complicated (which makes my security-sense go off, but certainly isn't a fatal indictment) and that I'd really need to either do an active evaluation of the system or get several reassurrances that someone else decent (ideally someone much smarter than me) did and it checked out before I'd be remotely comfortable using it or recommending it.
  - Estragon 15y ago
    That's fair enough. I was just pointing out that not every architecture involving in-browser JS crypto suffers from the problems tptacek detailed.
  - AUmrysh 15y ago
    Yeah, we need a crypto library like JQuery where it's open and people can use a common implementation.