4 ms·

In the old days, people said you shouldn't write crypto in JavaScript because it was somehow insecure. Have those concerns gone away with WebAssembly and https

In the old days, people said you shouldn't write crypto in JavaScript because it was somehow insecure. Have those concerns gone away with WebAssembly and https everywhere?

rany_ 4y ago
I don't think the argument was ever that "JavaScript was insecure." It was that the websites hosting it may be compromised or may change the script at any time without any indication (or the FBI forcing a site to backdoor the JS for some investigation)
- ignoramous 4y ago
  Yeah, but see also Code Verify (and sub-resource integrity): https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users/ https://blog.cloudflare.com/cloudflare-verifies-code-whatsap...
kevin_thibedeau 4y ago
It will never go away because you can't guarantee constant time algorithms will be implemented as such when transformed by a JIT.
- lxgr 4y ago
  If machine code can issue the necessary hints to the hardware to skip all time-variant optimizations, why couldn‘t the same work for a WASM runtime?
  - jerf 4y ago
    It could, but you need a lot of work on a lot of layers, possibly routed through an entire standards committee, to get it done. If it ever happens it's going to be a long time.
e12e 4y ago
I think the consensus is still that you can't write side-channel/timing proof crypto in (most) Javascript (runtimes) - but that with webcrypto(?) most runtimes will provide the secure crypto primitives you need in order to do (secure) crypto with Javascript?
- Anunayj 4y ago
  To add, certain concerns still stand since the Web crypto API is extremely limited in capabilities (Example it doesn't support secp256k1). However on the bright side performance.now() has a much worse resolution on most browsers, making timing attacks harder.
easrng 4y ago
Now that HTTPS is everywhere and crypto.getRandomValues provides a secure RNG I think most of the concerns are mitigated.
- lxgr 4y ago
  Maybe for Javascript, the language. Definitely not for browsers as the execution environment, at least browsers running extensions.
jillesvangurp 4y ago
Both javascript and browsers have been hardened a lot since then. Back in the day people were using javascript on plain http websites, without https. Cross site scripting prevention in browsers simply did not exist. Nowadays, it's a lot harder to get past browser security and people run all sorts of applications in browsers such as banking, business critical SAAS, email, etc. So, perfectly fine to include some crypto in that and probably not optional to do so for a lot of applications. What's still true is that you should not be rolling your own crypto libraries and instead use libraries from reputable sources that have been scrutinized by people that know what they are doing. That's true whether you use javascript, C or whatever. And of course with web assembly you can just compile those libraries and use them in a browser sandbox.

In the old days, people said you shouldn't write crypto in JavaScript because it was somehow insecure. Have those concerns gone away with WebAssembly and https everywhere?

rany_ 4y ago

I don't think the argument was ever that "JavaScript was insecure." It was that the websites hosting it may be compromised or may change the script at any time without any indication (or the FBI forcing a site to backdoor the JS for some investigation)

ignoramous 4y ago
Yeah, but see also Code Verify (and sub-resource integrity): https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users/ https://blog.cloudflare.com/cloudflare-verifies-code-whatsap...

kevin_thibedeau 4y ago

It will never go away because you can't guarantee constant time algorithms will be implemented as such when transformed by a JIT.

lxgr 4y ago
If machine code can issue the necessary hints to the hardware to skip all time-variant optimizations, why couldn‘t the same work for a WASM runtime?
- jerf 4y ago
  It could, but you need a lot of work on a lot of layers, possibly routed through an entire standards committee, to get it done. If it ever happens it's going to be a long time.

e12e 4y ago

I think the consensus is still that you can't write side-channel/timing proof crypto in (most) Javascript (runtimes) - but that with webcrypto(?) most runtimes will provide the secure crypto primitives you need in order to do (secure) crypto with Javascript?

Anunayj 4y ago
To add, certain concerns still stand since the Web crypto API is extremely limited in capabilities (Example it doesn't support secp256k1). However on the bright side performance.now() has a much worse resolution on most browsers, making timing attacks harder.

easrng 4y ago

Now that HTTPS is everywhere and crypto.getRandomValues provides a secure RNG I think most of the concerns are mitigated.

lxgr 4y ago
Maybe for Javascript, the language. Definitely not for browsers as the execution environment, at least browsers running extensions.

jillesvangurp 4y ago

Both javascript and browsers have been hardened a lot since then. Back in the day people were using javascript on plain http websites, without https. Cross site scripting prevention in browsers simply did not exist. Nowadays, it's a lot harder to get past browser security and people run all sorts of applications in browsers such as banking, business critical SAAS, email, etc. So, perfectly fine to include some crypto in that and probably not optional to do so for a lot of applications. What's still true is that you should not be rolling your own crypto libraries and instead use libraries from reputable sources that have been scrutinized by people that know what they are doing. That's true whether you use javascript, C or whatever. And of course with web assembly you can just compile those libraries and use them in a browser sandbox.