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?
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?
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.
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)
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.
Comments
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?
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?
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.
It will never go away because you can't guarantee constant time algorithms will be implemented as such when transformed by a JIT.
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?
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.
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)
Yeah, but see also Code Verify (and sub-resource integrity): https://blog.cloudflare.com/cloudflare-verifies-code-whatsap...
Now that HTTPS is everywhere and crypto.getRandomValues provides a secure RNG I think most of the concerns are mitigated.
Maybe for Javascript, the language.
Definitely not for browsers as the execution environment, at least browsers running extensions.
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.