Hacker News Reader

Comment by 9gunpi | Hacker News Reader

I feel WebCrypto (strange architectural choices made by people whose priorities are availability of crypto, not consistency of security) is even more questionable than running SJCL (a good crypto done by good people in questionable environment) in browser.

View on HN

I agree. Not making this up: the primary goal of WebCrypto was the elimination of Flash and plugins to enable streaming media players. It's not designed for security. It eliminates some of the least worrisome flaws in browser crypto (side-channel attacks against the lowest-level primitives) but leaves all the rest of the problems intact.

Can you recommend any reading on the subject? I've found WebCrypto to be a vast improvement over the alternatives.

In what sense? The WebCrypto interface is inferior to SJCL's, which existed for years prior.

It has a built-in cryptographically sound random source, uses modern JS primitives (Uint8Array and Promise), and easily outperforms SJCL at hashing and HMACing.

Additionally, the WebCrypto operations are built into the browser platform and cannot be overwritten by userland javascript, though the interface can be spoofed in browsers that do not support it natively.

SJCL provides a secure random interface (it implements Fortuna). It's not great, and SJCL is not especially performant. But its interface, cryptographically, is (as I said) superior to that of WebCrypto.

I'm not sure it matters that WebCrypto is native and "can't be overwritten", given that all the glue connecting the crypto is pure Javascript and can easily be rewritten.

I meant that the WebCrypto API does not rely on network transmission and that window.crypto and window.crypto.subtle are read-only properties in compliant implementations. Those two characteristics alone would seem to solve many of the problems enumerated on https://www.nccgroup.trust/us/about-us/newsroom-and-events/b..., namely the chicken-egg problem of secure javascript transmission and the malleability of the JS runtime.

I'd be interested in reading about how SJCL's interface is cryptographically superior. Superior/inferior seem to have a particular definition in this context, and I'm not sure I understand exactly what you mean. I know you're an expert in the field and would love some more context on how I should be cautious with WebCrypto.

(Edited for clarity.)

It doesn't matter that you've securely transmitted the AES implementation if the code that drives AES, sets up its constructions, ensures that its parameters are set properly, manages its keys, and handles the plaintext is itself delivered insecurely.

(I wrote the document you're citing, for what it's worth).

I know you wrote the document; that's why I was surprised to see you agree with a claim that using WebCrypto is "more questionable" than serving and using SJCL based on the differences in the libraries interfaces. I personally find SJCL's interface difficult to work with, since all bytes must be converted to an idiosyncratic format (sjcl.bitArray), whereas WebCrypto uses the unsigned int array primitives introduced to the language after SJCL was released. I'm pretty sure that's not what you mean when you say the WebCrypto interface is inferior, and I'll probably need to do some basic reading to figure out what exactly that means in the context of cryptography.

FWIW, WebCrypto should only be available in a secure context (https://lists.w3.org/Archives/Public/public-webcrypto/2016Se...), though I believe only Chrome enforces that requirement at the moment.

WebCrypto is also a potluck of primitives, designed my committee, with "secure end-to-end encryption" as a non-goal.

I'd personally rather see browsers ship libsodium.js (or equivalent) than WC or SJCL.

Reply on news.ycombinator.com