Emscripten and ClojureScript: Transpiling to Avoid Rolling Your Own Crypto | Hacker News Reader

Emscripten and ClojureScript: Transpiling to Avoid Rolling Your Own Crypto

blog.balboa.io

45 pointssquidlogic23 comments

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.

You're already running in a JIT/interpreted VM, timing attacks will be something that can't really be worked around.

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.

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.

From https://www.balboa.io/security.html:

"Skein-1024-CTR, with Skein-1024 as an HMAC in an encrypt-then-mac scheme"

I guess Skein-CTR is based on "Skein as a Stream Cipher" section from the spec.

https://github.com/pkcsecurity/trabant/blob/master/pkc_skein...

From homepage: "We use 1024-bit symmetric key encryption, a stronger level of encryption than most industry standards."

I guess the reason for using Skein is so that they can use this bullshit marketing :)

Skein HMAC? Why? Skein was designed not to need the HMAC construction.

It looks like they are actually using keyed Skein and call it HMAC

https://github.com/pkcsecurity/trabant/blob/master/pkc_skein...

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.

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

Wasn't one of Skein's selling points how optimized it was for Intel's newer architectures? asm.js isn't going to be able to leverage that.

Yeah, it is. We use the optimized 64bit version through JNI in our backend.

Why are you using Skein at all? It doesn't look like you have a problem that is hard for AES-CTR or Salsa/Chacha to solve.

Definitely right about that.

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.

Any reason for not to use the WebCryptoAPIs?

https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_...

Whoever made this website has never heard of "Never break the back button" rule. They literally rewrite my history with every click.

I guess they're using history.replaceState() when they meant to use history.pushState().

I had to double check to make sure this article wasn't some Markov chain troll article.

For reference, an open source library using a similar approach (crytpo + asm.js): https://github.com/vibornoff/asmcrypto.js/

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.

Interesting to see that other projects also consider client side Crypto possible by calling server side macros. Well done!

This is my project where I do it too : https://github.com/zubairq/coils

A reminder that one of the large issues with running crypto on the client is that you lose important timing information (due to the JS VM).

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.

Reply on news.ycombinator.com