Hacker News new | ask | show | jobs
by giaour 3390 days ago
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.
1 comments
tptacek 3390 days ago
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.

link
giaour 3390 days ago
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.)

link
tptacek 3390 days ago
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).

link
giaour 3390 days ago
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.

link
CiPHPerCoder 3389 days ago
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.

link