Re:Cryptography in the Browser
by _prometheus on Tuesday October 29, 2013 @08:14PM
(#6638524)
Or, could use pepper.js.
http://trypepperjs.appspot.com/
https://github.com/google/pepper.js
(note the `google` in the link).
Different NaCl. djb's NaCl is a crypto library. Google's NaCl is a "native code in the browser" component of Chrome/Chromium.
It's terribly confusing, especially since this article talks about both :)
What's worse is that djb's crypto NaCl wants to be pronounced "salt".
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.
That's might be a sign you don't pay enough attention cryptographic research; compiler optimization side channels are not news.
Of course, the notion that the compiler is a threat here is getting a bit ahead of ourselves, because you don't even know what side channels are in the runtime.
My primary concern is the LLVM bytecode to JS transformation.
Even on the LLVM side certain optimizations may be dangerous in crypto code. I wouldn't play with optimization settings unless I was sure I knew what I was doing. And I'd still think twice.
In fact this is a pretty insidious mistake since you think you are doing the right thing by using a high-quality library.