I spent some time working on a project to create an encrypted contact form for people to use on websites. Thought it might make for a good wordpress plugin, but I was wrong.
Having gone from a position of "why not" to "oh hell no" on javascript crypto, the fundamental problems as I see them (aside from the ones outlined in your comment):
* Each javascript engine is different, with different (or sometimes no) sources of differing (or no) levels of randomness, which is essential for crypto to work.
* Most browsers support some level of javascript introspection whether you like it or not. Sure, things like Content Security Policies can be used to limit access from other tabs or domains but it's not just secure delivery to browsers that's a problem with javascript, it's execution integrity too.
* Most of the Javascript crypto libraries I've seen are ports of C libraries using tools such as llvm. As such they were not designed with javascript's functionality in mind, and as such are unlikely to have been anywhere near as scrutinised for side channel leaks as something built from the ground up.
The final nail in the coffin for my project was the fact that I'm not supporting a set of browsers, I'm supporting a set of ecosystems. Anything from plugins and extensions to minor version changes can affect the behaviour of a javascript engine in an unexpected way with potentially dangerous outcomes. I couldn't in good faith release a tool that lets grandma contact you without having to install PGP but in reality may mean she gets black bagged regardless because she used a dodgy tablet with no randomness source.
There are some relevant considerations in that document but I found it to be very dismissive. SSL for example is not hard to implement, and going ssl-always is now quite common.
Don't get me wrong, I certainly don't want to advocate slapping some crypto lib onto a site with a bunch of marketing script. A project from scratch with these considerations might some day get it done.
For now, crypto should be done via a native client. In the case of encrypted p2p communication, clients such as http://retroshare.sourceforge.net/ get the job done nicely.
Clientside JS for crypto? No. Bad idea.
http://www.matasano.com/articles/javascript-cryptography/
Their reasons:
> Secure delivery of Javascript to browsers is a chicken-egg problem.
> Browser Javascript is hostile to cryptography.
> The "view-source" transparency of Javascript is illusory.
> Until those problems are fixed, Javascript isn't a serious crypto research environment, and suffers for it.