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.
With 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.
It is super weird to see new code using Skein; doing that almost by definition implies you're rolling your own crypto (which has more to do with how you connect crypto primitives than which primitives you choose), but it's never made clear in this post exactly what they're doing with it.
"1024-bit symmetric key encryption" certainly has the flavor of a statement which is technically correct, but designed to be favorably misinterpreted. I'm surprised they didn't mention that Skein is gluten free.
You're right. To be honest, the reason why we don't use it the way it is described in the paper, is entirely out of fear of misconfiguring the Skein context. The NIST reference implementation for Skein doesn't provide a simple way or an example for building the valid configuration for the HMAC construction they recommend, and we always wanted to feel like we had a wall to our back (i.e. being able to check against the NIST implementation or to check against test vectors). They do mention in the paper that doing the keyed mac approach is provably safe, which just felt easier to implement.
Interesting thought, "rolling your own crypto" seems to be something of an accordion term. I took it to mean creating your own crypto primitives, but I guess there are plenty of opportunities to mess up security while writing code.
The biggest reason was familiarity with the Skein NIST implementation--I've dug through it in the past in research and the like, so I wanted to leverage some experience there. We decided against just using crypto_secretbox from NaCl because it doesn't have a way for us to simply pause and resume to keep from blocking our UI thread on big files. We thought about trying to bolt ways into seeking into the stream output of crypto_stream, but that wasn't performing well. We went as far as trying to use crypto_secretbox in an Asm.js-ified WebWorker, but the performance hit was just too big, so we knew we had to find a way to "schedule" our encryption, otherwise our React.js app would crawl. The reason I passed on AES is far less justifiable, but important to me for aesthetic reasons: Using Skein just seemed like way more fun. Programming without whimsy is drudgery.
My next blog post will cover some of these decisions and performance tradeoffs in more detail with some code. Since you mentioned it, I will add an AES-CTR implementation into the metrics so people can see. I'm curious myself to see how we stack up!
The reason I passed on AES is far less justifiable, but important to me for aesthetic reasons: Using Skein just seemed like way more fun. Programming without whimsy is drudgery.
You seem like you know what you're talking about but that last sentence is approximately the scariest thing any software developer working with crypto has ever said.
Looks like the asmcrypto's speed boosts are pretty high relative to SJCL and CryptoJS. Granted, this article's approach is transpiles C->JS, not sure what the implications are there in terms of performance.
I wonder if many of our security issues are not due to poorly written software, and a big part of that is accumulating layers of cruft in exactly this sort of way.
I would certainly write my own crypto (but not design my own encryption scheme!) before using such a heavyweight solution. Implementing crypto might be hard, but common, not harder than building a compiler.
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.