[security] Please strongly discourage pure javascript implementation

[bastien-roucaries]

Hi,

With my debian hat on, could be possible to strongly discourage pure javascript implementation.

It is a crypto cover channel pitfall. Javascript due to is modern implementation is a JIT implementation, so sensible to cover channel (particularly time cover channel, how to impement for instance big number multiplication in js without assembly support).

Wasm is the same BTW

rouca@debian.org

[tniessen]

I believe that's a well-known issue and one of the primary reasons for the existence of the Web Crypto API. It is available in most JavaScript environments and I am not aware of a single (popular) runtime that implements cryptographic primitives in JavaScript. Polyfills are an unfortunate but increasingly irrelevant exception.

WebAssembly could very well become a good choice as soon as constant-time WebAssembly moves forward.

[paulmillr]

This is nonsensical advice, from op post.

1. wasm binaries are not a good choice. They are commonly not being built in reproducible way, which means they can contain malware and steal user data or infect their machine
   • you can't verify wasm, you can verify pure js
   • wasm binaries are unnecessarily large, especially when produced from rust, it's tedious to decompile them
2. wasm would still leak data (to uint8arrays etc) when called from javascript.
3. there are many protocols which are not implemented natively in webcrypto and won't be, meaning some third-party implementation is needed
4. there are different threat models which may not include side-channel attacks
5. there are implementations of js cryptography which algorithmically protect against side-channel attacks, and there are impls of rust cryptography which do not
6. Writing in js is fun and simple, it's way easier for outsiders to read JS code instead of low-level ASM-wobbling C stuff. Easy learning curve would increase amount of cryptography developers.

Best we can do is encouraging pure javascript implementation.

webcrypto is good, but the working group cannot even make browser developers include secp256k1, x25519 and chacha20. It's too much bureaucracy even for algorithms used all over the place in tls 1.3.

[twiss]

@paulmillr OP is not talking about applications implementing crypto in pure JavaScript vs using Web Crypto, as you seem to be. Rather, they are saying that implementers of Web Crypto (i.e. browsers and other web runtimes) should not use JavaScript to implement the Web Crypto API.

That is good advice because some applications may have requirements wrt. side-channel attacks that require a constant-time implementation, for example. (And this was indeed a motivation for the creation of the Web Crypto API. The existence of some applications that don't have that requirement is not really a counter-argument to that.)

The runtime can/should thus ideally implement the Web Crypto API in a language that allows a constant-time implementation. There is also no need for the runtime to compile that implementation to wasm, so most of your points do not apply there.

webcrypto is good, but the working group cannot even make browser developers include secp256k1, x25519 and chacha20. It's too much bureaucracy even for algorithms used all over the place in tls 1.3.

This is an entirely separate discussion, please see #82, #196 and #223 respectively, and https://github.com/w3c/webcrypto/issues/280#issuecomment-1151509624 for a more general discussion. And you'll be pleased to know that there's a spec for the CFRG curves now, and X25519 is implemented in some browsers already :)

[paulmillr]

@twiss yeah, I just assumed all web crypto implementations are using low-level languages, that's the right thing to do. Implementing webcrypto in js kinda defies its purpose.