3 ms·

Since this article was written, Google released an alpha version of a JS-based crypto tool: http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-e

Since this article was written, Google released an alpha version of a JS-based crypto tool: http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-encryption-easier-to.html http://googleonlinesecurity.blogspot.com/2014/06/making-end-... They directly address some of the arguments against JS crypto: https://code.google.com/p/end-to-end/ https://code.google.com/p/end-to-end/ When End to End was released I was curious if any proponents of "JS Crypto Considered Harmful" would have a response, but I didn't see one, nor do I see one here. I would be interested to see a response for why the Google approach is flawed.

haberman 12y ago
I'm a crypto novice, but from my (layperson) reading here is how the Google approach addresses the points made in this article: - chicken and egg problem: being a browser extension, the code for End to End is distributed up front, when you do (presumably) trust the server. If the server is compromised in the meantime, you are not affected. Also, you could download the extension from a source you do trust and then use it on websites that you don't trust. - content-controlled code / malleable runtime: End to End, as a browser extension, isolates itself from the code/content of actual websites. - no RNG: "CS-PRNG is available thanks to WebCrypto." - secure erasure: "The threat model we are trying to address discounts adversaries with physical access and users with malware outside the browser. Chrome’s design means that extensions should be safe against other extensions. Adversaries with this level of access have a plethora of attacks available to compromise data even in systems that control their memory carefully and wipe it." - no secure keystore: ? (I don't know) - timing and other side-channel attacks: "End-To-End requires user interaction for private operations in normal use, mitigating this risk. Non-user-interaction actions are rate-limited and done in fixed time. End-To-End’s crypto operations are performed in a different process from the web apps it interacts with. The End-To-End library is as timing-aware it can be and we’ve invested effort to mitigate any exploitable risk."
jerf 12y ago
"They directly address some of the arguments against JS crypto:" And in the very first 5 words, "End-To-End is a Chrome extension" (emphasis mine), they take themselves out of the domain of the original post, which is 90% about Javascript included in web pages, not Javascript in general.
- haberman 12y ago
  From the page: "For the rest of this document, we're referring to browser Javascript when we discuss Javascript cryptography." Browser extensions are still part of the browser. They still have DOMs, for example. Maybe the article is trying to limit itself to talking about "Web page JavaScript". But if so this isn't very clear.

haberman 12y ago

I'm a crypto novice, but from my (layperson) reading here is how the Google approach addresses the points made in this article: - chicken and egg problem: being a browser extension, the code for End to End is distributed up front, when you do (presumably) trust the server. If the server is compromised in the meantime, you are not affected. Also, you could download the extension from a source you do trust and then use it on websites that you don't trust. - content-controlled code / malleable runtime: End to End, as a browser extension, isolates itself from the code/content of actual websites. - no RNG: "CS-PRNG is available thanks to WebCrypto." - secure erasure: "The threat model we are trying to address discounts adversaries with physical access and users with malware outside the browser. Chrome’s design means that extensions should be safe against other extensions. Adversaries with this level of access have a plethora of attacks available to compromise data even in systems that control their memory carefully and wipe it." - no secure keystore: ? (I don't know) - timing and other side-channel attacks: "End-To-End requires user interaction for private operations in normal use, mitigating this risk. Non-user-interaction actions are rate-limited and done in fixed time. End-To-End’s crypto operations are performed in a different process from the web apps it interacts with. The End-To-End library is as timing-aware it can be and we’ve invested effort to mitigate any exploitable risk."

jerf 12y ago

"They directly address some of the arguments against JS crypto:" And in the very first 5 words, "End-To-End is a Chrome extension" (emphasis mine), they take themselves out of the domain of the original post, which is 90% about Javascript included in web pages, not Javascript in general.

haberman 12y ago
From the page: "For the rest of this document, we're referring to browser Javascript when we discuss Javascript cryptography." Browser extensions are still part of the browser. They still have DOMs, for example. Maybe the article is trying to limit itself to talking about "Web page JavaScript". But if so this isn't very clear.