All the reasons why you shouldn't do JavaScript Crypto

This post came about because too many people were bringing up the same arguments in favor of JS crypto in response to my 2009 talk on common crypto mistakes. One dev went so far as to call it "host proof", which is nonsense. You can see the discussion in the comments.

http://rdist.root.org/2009/08/06/google-tech-talk-on-common-...

To show the security problems, I describe three implementation approaches: traditional client-side app, server-side app, and Javascript crypto. Each is evaluated based on its fundamental trust model, as well as any unique potential weaknesses.

JS crypto is all about trusting the server, same as with a server-side app. But it adds quite a few additional problems:

1. Numerous libraries not maintained by cryptographers

2. New code has not been properly reviewed and no clear "best practices" for implementers

3. Low-level primitives only

4. Browser is low-assurance environment

5. Poor crypto support

6. Too many platforms

7. Auditability

I end the post with a challenge. I'm willing to reconsider only if there is a fundamental change in JS crypto. For example, web browsers could standardize a high-level crypto API for use by JS, including a keystore in persistent storage. That kind of change could make JS crypto potentially useful. But until then, I stand behind this analysis that it is dangerous and misleading to users.

Not only is Javascript not an environment that makes client-side auditing easier, it's actually a uniquely hard environment to audit code in:

* Javascript is, as noted in the article, extremely dynamic; what looks like a reasonable key generation routine (as reasonable as you can get in an environment without a secure RNG) could be redefined 1000 lines later to be entirely predictable.

* The bindings in a single page environment are populated from a variety of sources; some of the most important sources are content-controlled, meaning the trusted code base in your crypto library has to play Core Wars with things like DOM attributes.

* There's a "view source" UI, but there's no common UI to easily inspect the current definition of every symbol in the interpreter; you have no way of knowing whether some interaction between the code, the DOM, and the (implicitly trusted) server hamstrung your crypto code.