3 ms·
Just to clarify, as I've seen many of your responses to posts on this subject, you're advocating against use of javascript encryption in client-side application
by revdinosaur 13y ago
Just to clarify, as I've seen many of your responses to posts on this subject, you're advocating against use of javascript encryption in client-side applications served through the browser.
If the encryption library were running on a server using node.js or packaged into a mobile app using a framework like Phonegap it doesn't matter that the implementation is in javascript, does it?
- tptacek 13y agoThe issue is with browser Javascript, specifically with sensitive Javascript that has to coexist in the same runtime and even the same variable scope as content-controlled code.
- jaekwon 13y agoAll client code is essentially equally sensitive. I'm not sure why you're making a distinction at all.
- jahewson 13y agoIndeed, there's nothing wrong with using node.js' bindings to OpenSSL. It's crypto in the browser which creates the chicken-and-egg problem.
- hershel 13y agoThis relatively old webpage[1] talks about the possibility of side channel attacks in javascript(among other things).I believe this applies to Phonegap. [1]https://hellais.wordpress.com/2011/12/27/how-to-improve-javascript-cryptography/ https://hellais.wordpress.com/2011/12/27/how-to-improve-java...
- revdinosaur 13y agoThank you, these sorts of timing attacks are very interesting. I was asking for clarification because I am curious about vectors such as these; vulnerabilities in JS runtime or in HTML/CSS. This thinking was spurred by an article posted here not to long ago[1] about timing attacks on CSS and SVG shaders through requestAnimationFrame. [1] http://www.contextis.com/files/Browser_Timing_Attacks.pdf http://www.contextis.com/files/Browser_Timing_Attacks.pdf