

All the reasons why you shouldn't do JavaScript Crypto - marcinw
http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

======
NateLawson
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-...](http://rdist.root.org/2009/08/06/google-tech-talk-on-common-
crypto-flaws/)

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.

------
tptacek
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.

