3 ms·

Obligatory disclaimer: "Javascript Cryptography Considered Harmful" http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascri

by sasas 12y ago

Obligatory disclaimer: "Javascript Cryptography Considered Harmful" http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/

chrisfosterelli 12y ago
This article gets posted a lot. The author seems to provide two scenarios: either you use SSL/TLS and don't need Javascript encryption or you use Javascript encryption and are open to side-channel attacks. He briefly covers the idea of using both, then hand-wavily disregards it. He has many valid points, but serving Javascript encryption code over SSL/TLS and using it to keep your privacy in the server's DB is still a good idea. Do you have to trust the server a reasonable amount because of the fact that they could change their JS at any time? Yes. Does that make encryption useless and not worth doing? No. I'd also like to point out that there are alternatives to this where you don't have to trust the server after verifying the code the first time, see Substack's demo here: http://hyperboot.org/ http://hyperboot.org/ JS encryption does have weak spots that could be improved, but that's not going to happen by completely refusing any sort of JS encryption as useless.
- sasas 12y ago
  > Do you have to trust the server a reasonable amount because of the fact that they could change their JS at any time? What if it's not the server's JS? - http://imgur.com/DKmfic0 http://imgur.com/DKmfic0
  - chrisfosterelli 12y ago
    Desktop crypto applications also suffer from security vulnerabilities, I think the same criticism applies there. Clever XSS by the way ;)
  - jamiesonbecker 12y ago
    Agreed.. but XSS (or MITM injection) isn't a scalable activity. You'd have to write it custom for each app. Even if you just attacked the underlying library, it's still something that's detectable on the browser side, so you'd have to carefully target your opponent (unless you just didn't care if they knew at all -- but that'd minimize your effectiveness as well.) IMO, it's definitely worthwhile at least the initial crypto stage in-browser. Heartbleed et al proved that. Just don't rely on it. Ensure strong TLS, HSTS, etc as well. Definitely agreed - XSS is really severely problematic since it's potentially easier and doesn't require MITM. In this rare use case (and without actually trying the app), I'm guessing you'd basically have to be XSS'ing yourself since you're probably not XSS'ing a public field?

by sasas 12y ago

Obligatory disclaimer: "Javascript Cryptography Considered Harmful" http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/

chrisfosterelli 12y ago

This article gets posted a lot. The author seems to provide two scenarios: either you use SSL/TLS and don't need Javascript encryption or you use Javascript encryption and are open to side-channel attacks. He briefly covers the idea of using both, then hand-wavily disregards it. He has many valid points, but serving Javascript encryption code over SSL/TLS and using it to keep your privacy in the server's DB is still a good idea. Do you have to trust the server a reasonable amount because of the fact that they could change their JS at any time? Yes. Does that make encryption useless and not worth doing? No. I'd also like to point out that there are alternatives to this where you don't have to trust the server after verifying the code the first time, see Substack's demo here: http://hyperboot.org/ http://hyperboot.org/ JS encryption does have weak spots that could be improved, but that's not going to happen by completely refusing any sort of JS encryption as useless.

sasas 12y ago
> Do you have to trust the server a reasonable amount because of the fact that they could change their JS at any time? What if it's not the server's JS? - http://imgur.com/DKmfic0 http://imgur.com/DKmfic0
- chrisfosterelli 12y ago
  Desktop crypto applications also suffer from security vulnerabilities, I think the same criticism applies there. Clever XSS by the way ;)
- jamiesonbecker 12y ago
  Agreed.. but XSS (or MITM injection) isn't a scalable activity. You'd have to write it custom for each app. Even if you just attacked the underlying library, it's still something that's detectable on the browser side, so you'd have to carefully target your opponent (unless you just didn't care if they knew at all -- but that'd minimize your effectiveness as well.) IMO, it's definitely worthwhile at least the initial crypto stage in-browser. Heartbleed et al proved that. Just don't rely on it. Ensure strong TLS, HSTS, etc as well. Definitely agreed - XSS is really severely problematic since it's potentially easier and doesn't require MITM. In this rare use case (and without actually trying the app), I'm guessing you'd basically have to be XSS'ing yourself since you're probably not XSS'ing a public field?