nlacasse

What's worse is that djb's crypto NaCl wants to be pronounced "salt".

I disagree. Javascript cryptography can provide real security, it's just important to keep in mind what is being secured, and where the vulnerabilities are. Currently, js crypto is vulnerable in that its difficult to verify that the js a browser is running is the intented code.

Every day, millions of people are sending sensitive data over very insecure channels like email and DropBox because secure tools like PGP are to difficult for them or their friends to use. Clearly some security is better than none, as long as the limitations are known.

Thanks for the reply.

Opal requires as little trust as possible, but you are correct that some server-trust is required at the moment.

I hope that apps like Opal will encourage more progress on browser/javascript cryptography. The W3C crypto spec is coming along nicely, and things like Content Security Policy address some of the concerns about delivering secure javascript.

One nice thing about web-apps is that they are by-default open source, and browsers are bundled with all sorts of diagnostic tools. Anybody who worries that their data is being "sprayed" can just open the network tab and see exactly what is being sent over the wire. Obviously we don't expect many users to do this, but it's one way to enforce our honesty until better solutions exist.

Emscripten compiles the input source with LLVM, then converts the LLVM bytecode to JS. Most of the optimization passes are done by the LLVM compiler. Are you suggesting that LLVM (or optimizing compilers in general) should not be used to compile crypto libraries?

I completely agree that further analysis is needed on js-nacl, but I hadn't considered that compiler optimizations might lead to vulnerabilities.