Matasano Security recently published “Javascript Cryptography Considered Harmful,” an article in which it stipulated that web Javascript cryptography is “doomed” due to a number of factors. Matasano suggested SSL/TLS (HTTPS) as a viable solution in the many use cases where Javascript cryptography is sometimes being deployed. I myself deploy Javascript cryptography in Cryptocat, my open source project.
While some of Matasano’s points against Javascript cryptography are, of course, reasonable and worthy of investigation, many of their attacks against Javascript cryptography lack a complete understanding of how the technology has advanced in the short-term past; the main point Matasano seems to be missing is that while Javascript cryptography is, admittedly, very difficult to deploy correctly, it is still possible to use it to counter problems that HTTPS cannot counter alone.
One of these problems is that data sent via HTTPS will always be readable as plaintext on the server, even in situations where the server is supposed to simply store ciphertext without being able to read its plaintext equivalent. However, while Javascript cryptography is theoretically capable of sending ciphertext that cannot be decrypted server-side, Matasano raises many interesting issues against using Javascript cryptography in this scenario:
“Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request.”
This problem is simply mitigated by deploying Javascript cryptography in conjunction with HTTPS. While HTTPS has its own set of problems, not taking advantage of its benefits in the sensitive context of Javascript cryptography is lazy.
However, while Matasano encourages the usage of HTTPS (referred to in their article as SSL/TLS,) they say that “having established a secure channel with SSL, you no longer need Javascript cryptography; you have “real” cryptography.” Obviously, since HTTPS is incapable of sending ciphertext that the server cannot decrypt, Javascript cryptography remains very useful in such a context.
“Secure delivery of Javascript to browsers is a chicken-egg problem.”
This problem, while serious, can be mitigated with the usage of browser plugins that locally verify the integrity of the Javascript code, warning the user should the code be faulty. In the case of Google Chrome, the browser plugin may itself be in Javascript, and thus is easy to audit and verify locally. Cryptocat Verifier is one such plugin. The browser plugin can be extended to verify the Javascript crypto code’s immediate environment as well, such as HTML, CSS, etc. to check for possible backdoors and invisible DOMs. Such a plugin would solve a myriad of other raised issues with Javascript cryptography, such as side-channel attacks and code injections.
“Javascript lacks a secure random number generator.”
While Javascript does not ship with a secure random number generator, David Bau’s seedrandom is a seedable, secure Javascript random number generator that derives a seed from local elements:
The DOM contains several candidate sources of entropy such as the cookie, the window size and position, the scroll position, the history length, the current event, the clock, the native random number generator, and Javascript variable state.
While seedrandom’s automatic seeding may not be good enough to withstand a highly adversarial setting, it can still be manually seeded by asking the user for random mouse/keyboard input. The seed may be hashed using a secure digest before it is fed to a CSPRNG, such as Fortuna, which has also been implemented in Javascript.
“Javascript cryptography hasn’t implemented well-known standards such as PGP; such a high-level language can’t be trusted with cryptography.”
Cryptico is a Javascript cryptography library that has an RSA implementation that is fully cross-compatible with any OpenSSL-based backend. It can generate keys up to 8192 bits in length in the browser, and is capable of message signing.
“Javascript’s ‘view-source transparency’ is illusory.”
It is the case in every cryptography implementation that the implementation will need to be reviewed by an expert before being declared secure. This is no different in Javascript, C, or Python. The only benefit of view-source transparency is that the same code actually being executed by the browser can be read, which is impossible with compiled binary crypto. From that standpoint, “view-source transparency” is not illusory; it becomes illusory when we take the idea too far. With the use of a local code-verifying browser plugin, it becomes only necessary to audit the plugin once.
The Real Issue with Browser Crypto
There is no question that Javascript cryptography is still a growing field that requires much work, somewhat on the part of browser providers to clamp down DOM sharing and other issues in their code, but also on the part of the crypto community to find ways to safely implement functions in Javascript crypto. Javascript cryptography is difficult, heck, downright dangerous to implement correctly, but creative solutions to difficult problems, such as seedrandom, are a way forward.
However, the ultimate problem with browser cryptography is that there is no standard for innate, in-browser encryption. Very much like HTML5 and CSS, there needs to be an international, vetted, audited, cross-browser standard for browsers to be capable of securely encrypting and communicating sensitive information. There’s no denying the urgent need for such a standard , considering the ridiculous rate in which the browser is becoming pretty much the mainstream central command for personal information.
Update (Sep 14, 211): This post apparently sent Matasano Security employee Thomas Ptacek on a passive-aggressive tirade against me on his Twitter feed, where he posted a bunch of angry attacks that I feel really don’t speak well of Matasano Security’s reputation as a company. As a security researcher, I don’t appreciate having a particular company react against me with public personal attacks and rudeness when I take the time to write a considerate, respectful reply to their analysis.