4 ms·

I feel WebCrypto (strange architectural choices made by people whose priorities are availability of crypto, not consistency of security) is even more questionab

by 9gunpi 10y ago

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.

tptacek 10y ago
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.
- giaour 10y ago
  Can you recommend any reading on the subject? I've found WebCrypto to be a vast improvement over the alternatives.
  - tptacek 10y ago
    In what sense? The WebCrypto interface is inferior to SJCL's, which existed for years prior.
    - giaour 10y 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.
      - tptacek 10y 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.
        giaour 10y 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/blog/2011/august/javascript-cryptography-considered-harmful/ 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.)
        tptacek 10y 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).
        giaour 10y 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/2016Sep/0007.html https://lists.w3.org/Archives/Public/public-webcrypto/2016Se...), though I believe only Chrome enforces that requirement at the moment.

by 9gunpi 10y ago

tptacek 10y ago

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.

giaour 10y ago
Can you recommend any reading on the subject? I've found WebCrypto to be a vast improvement over the alternatives.
- tptacek 10y ago
  In what sense? The WebCrypto interface is inferior to SJCL's, which existed for years prior.
  - giaour 10y 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.
    - tptacek 10y 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.
      - giaour 10y 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/blog/2011/august/javascript-cryptography-considered-harmful/ 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.)
        tptacek 10y 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).
        giaour 10y 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/2016Sep/0007.html https://lists.w3.org/Archives/Public/public-webcrypto/2016Se...), though I believe only Chrome enforces that requirement at the moment.