3 ms·
I think this is counterproductive - transpiling and relying on emscripten to be cryptographically secure in not changing your code is the very definition of rol
by barkingcat 11y ago
I think this is counterproductive - transpiling and relying on emscripten to be cryptographically secure in not changing your code is the very definition of rolling your own crypto. How do you know that you're compiling the right things to js?
The post says they've taken a cursory look at emscripten to make sure it doesn't have "timing attacks" in one short sentence. This is exactly the kind of verification that requires an experienced and professional cryptanalyst to audit, examine, and finally confirm that emscripten -> js indeed doesn't expose the cryptographic algorithms to side channel attacks, or add additional weaknesses to the cryptography.
If the authors of the original post are not cryptographically confident enough to "roll their own crypto" how can they verify that their tool chain is secure?
Don't roll your own crypto, especially in using tools that haven't been verified to be used in crypto by cryptanalysis.
- hackcasual 11y agoYou're already running in a JIT/interpreted VM, timing attacks will be something that can't really be worked around.
- deleted 11y ago[deleted]
- bpolverini 11y agoWith or without "use asm", as hackcasual mentioned, we don't have the control we need, like one might have on some platforms in C. Some of the articles we reference in the top section of the blog post mention this about Javascript and are great reads. We selected these particular primitives because the authors mention avoiding timing attacks as a key feature of their C. We believe that aspect to their libraries is still fantastic even after being compiled with Emscripten, but you're certainly right in saying that JIT'ing and Asm.js complicate things.