Why JavaScript Crypto Is Useful

The main criticisms of JS crypto that I've seen have nothing to do with the language, just that it's in-browser scripting hosted by a third party. Even if the language were perfectly designed for cryptography, the problem is the trust model - every single time you decrypt or sign something, you need to load your private key (or give a password for key generation, or whatever) into the script, which means that you need to make sure that the code has not been subverted every single time, which is nearly impossible to do anyway. So if you try and offer a service that says, "Even I can't access your e-mails, they are end-to-end encrypted using Javascript in your browser!", that may be true right now, but you can revoke that trust unilaterally by changing the Javascript and I won't notice. You could be compelled to do this. Your server might be compromised in some way, then all of a sudden you've got my private key. The whole problem that end-to-end encryption solves is that the server/cloud can only say, "We won't look at your data.", not "We can't look at your data." If you're controlling the encryption process with javascript, then you can't necessarily decrypt the data when it's at rest, but the next time I log in, you could snatch my keys, and maybe you've already done that at some point. So now we're back to a "We won't look at your data." model, because you're just making the choice not to subvert the crypto javascript.

Think about what you'd do if you were going to install TrueCrypt or some other security/cryptography program. Assuming you didn't want to build it from the source, you'd download a binary, and that binary would have an SHA or MD5 hash next to it, verifying that it's the correct file. Other people who compile the binary from source should be able to generate the same file and compare the hashes, so at the very least it can be audited and you can verify that you've got what they say you have. To do the equivalent thing with in-browser Javascript, you'd need to check the MD5 hash of the javascript that you're executing every single time you use the script, BEFORE you start the encryption/decryption process. You could use some sort of browser extension to check that the script you're about to download and execute is the same one you've used before, but if you're already installing browser extensions to do something like that, you might as well just install a browser extension that does the crypto for you without having a trust relationship with a server.

Yeah. The ability of Javascript to underpin a cryptographic system isn't a question. For some systems, where the code will never be transmitted to an executing system, no problems.

It's the transit that presents a vulnerability. If the cryptosystem can be intercepted and modified enroute to the host that will execute it, it cannot be considered secure. If the cryptosystem is delivered as part of an embedded system, it's more likely it can be considered secure.

edit: I'll add a caveat to the cannot. It's more reasonable to consider it secure if it sends a hashed checksum of itself to a server, using itself to generate the hash and it sends a copy of itself to the server to generate the hash. If the hashes match, it's quite likely good to go. The total transmission required for this style of code authentication is worth consideration.