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