3 ms·

> The fact that an MITM or XSS can completely undermine this MITM and XSS are problems with many Web APIs. There are already countermeasures for MITM (e.g. TLS

> The fact that an MITM or XSS can completely undermine this MITM and XSS are problems with many Web APIs. There are already countermeasures for MITM (e.g. TLS) and XSS (e.g. CSP). They are too difficult to use, and we need to make them easier to use. That is a parallel effort. > outside of the secure RNG -- a definite good thing The cryptographic PRNG is actually the enabler of pure JS cryptography. If all browsers provide only the cryptographic PRNG, then we'll see people implementing crypto algorithms in JS for sure. I would rather we provide them with (native code) APIs that guarantee maximal protection against side-channel attacks. > As long as the server controls how the building blocks are put together, what keys are used and when, etc, the trust model is broken. Even if these crypto APIs are less useful for normal web page use, I expect them to be an improvement for (packaged) installable web apps. We are planning on packaged web apps being protected by digital signatures (at least in Firefox OS) and having a default CSP that prevent the execution of any external scripts. Still, of course it would still be up to the application developer to do all the other things that are necessary for their application to be secure--whether it is using cryptography or not.

tptacek 14y ago
But you haven't protected those applications from Javascript attacks, because you've left virtually all of the glue to bind HMAC to AES (if the developer knows to do that) or to set the parameters for AES-CBC or AES-CTR (if the developer knows to do that) and to perform secure key exchange and avoid key reuse (if the developer knows to do that) to higher levels, like Javascript. Avoiding attacks on Javascript crypto is a very strong argument for a browser crypto standard --- but that standard has to be a high-level envelope interface for the argument to hold water.

tptacek 14y ago

But you haven't protected those applications from Javascript attacks, because you've left virtually all of the glue to bind HMAC to AES (if the developer knows to do that) or to set the parameters for AES-CBC or AES-CTR (if the developer knows to do that) and to perform secure key exchange and avoid key reuse (if the developer knows to do that) to higher levels, like Javascript. Avoiding attacks on Javascript crypto is a very strong argument for a browser crypto standard --- but that standard has to be a high-level envelope interface for the argument to hold water.