3 ms·

I believe you are suggesting that we make a more foolproof API like keyczar. The original idea of DOMCrypt was along those lines as well. I don't think we will

I believe you are suggesting that we make a more foolproof API like keyczar. The original idea of DOMCrypt was along those lines as well. I don't think we will be able to avoid specifying and shipping the low-level API at this point. It would be nice to define such a foolproof API on top of the low-level API, prototype it with a JS implementation, get feedback on how useful it is (i.e. whether it is too limited for the use cases people have), and then push browser makers to provide this safer API natively. I think the main concern with a keyczar-like API is that we won't be able to create one that significant numbers of websites would actually use.

tptacek 14y ago
Can I ask what the point of enabling websites to create vulnerable cryptosystems is? I don't mean that snarkily and I'm not trying to make a point. What are the applications that would not be possible with a high-level "envelope" interface that are key use cases for the Web Crypto API?
- briansmith 14y ago
  > Can I ask what the point of enabling websites to create vulnerable cryptosystems is? You yourself noted that Javascript, not this API, is the enabler of vulnerable cryptosystems in web apps. Also, sometimes you want to implement a vulnerable cryptosystem. For example, imagine a PDF viewer or a Microsoft Word document viewer that wants to be able to view password-protected (encrypted) documents with acceptable performance. > What are the applications that would not be possible with a high-level "envelope" interface that are key use cases for the Web Crypto API? I have asked this question quite a few times. The responses are that the model you and I have in mind doesn't fit the model that certain applications want/need. Also, the people working on this are people that are used to programming in C with CAPI, PKCS#11, etc. So, it shouldn't be surprising that the API will look a lot like a Javascript transliteration of CAPI, PKCS#11, etc. in the end. Finally, I think some people perceive it as being easier to standardized "Javascript PKCS#11" than it would be to standardize several high-level "foolproof" APIs. Please also see my other response(s) in this thread.
  - tptacek 14y ago
    If you want to implement a vulnerable cryptosystem, do it in pure Javascript. Concessions to the broken cryptography of the last 20 years have no place in a forward-looking browser security standard. Similarly: the industry has grown accustomed to interfaces like PKCS#11, and indeed from looking at the threads on the W3C Web Crypto mailing list, it's clear that PKCS#11 was a major influence on this proposal. But the industry has manifestly failed to enable the deployment of sound cryptosystems for 20+ years. Cryptographers have come up with new interfaces, like Keyczar and Nacl. Why aren't forward-looking standards adopting those instead of perpetuating mistakes from the '90s? Ordinarily, you wouldn't want the perfect to be the enemy of the good. But this is security and you don't get to say that here. As a developer and someone who has spent the last 8+ years dealing with the security challenges of other people's web software, I think the goal of interop with existing crypto is counterfeit. It would be extraordinarily difficult for a browser standard to capture the gory details of every widely deployed cryptosystem. You don't have a shot at "very good" interop. Meanwhile, if we could just solve the problem of getting applications a trusted cryptographically secure binding between client and client-data-stored-on-server, there's a lot of interop problems we could solve "out of band". Part of what makes interop hard is getting the details of CTR counter byte order right, sure. But another part of what makes interop hard today is just providing the baseline level of security required to make the trust model work. More people need the trust model to work than need support for backwards crypto systems. That's the problem that should get tackled first.
daeken 14y ago
> I think the main concern with a keyczar-like API is that we won't be able to create one that significant numbers of websites would actually use. I'm personally much more concerned about websites using an API with significant faults than fewer websites using a solid API. The fact that an MITM or XSS can completely undermine this makes it equivalent (outside of the secure RNG -- a definite good thing) of doing all your crypto in JS. 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.
- briansmith 14y ago
  > 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.
romaniv 14y ago
I think the main concern with a keyczar-like API is that we won't be able to create one that significant numbers of websites would actually use. Why not try to create one that significant number of users will use? Stuff like automatic verification of files using a hash or signing and verifying GPG signatures on web-based message boards would be tremendously useful and don't require much support on the website side.
- briansmith 14y ago
  Please see my other responses in this thread. I recommend people to write up proposals for such APIs and submit them to the W3C working group. It should be simple to specify them because you should literally be able to specify them directly in code based on the low-level API.

tptacek 14y ago

Can I ask what the point of enabling websites to create vulnerable cryptosystems is? I don't mean that snarkily and I'm not trying to make a point. What are the applications that would not be possible with a high-level "envelope" interface that are key use cases for the Web Crypto API?

briansmith 14y ago
> Can I ask what the point of enabling websites to create vulnerable cryptosystems is? You yourself noted that Javascript, not this API, is the enabler of vulnerable cryptosystems in web apps. Also, sometimes you want to implement a vulnerable cryptosystem. For example, imagine a PDF viewer or a Microsoft Word document viewer that wants to be able to view password-protected (encrypted) documents with acceptable performance. > What are the applications that would not be possible with a high-level "envelope" interface that are key use cases for the Web Crypto API? I have asked this question quite a few times. The responses are that the model you and I have in mind doesn't fit the model that certain applications want/need. Also, the people working on this are people that are used to programming in C with CAPI, PKCS#11, etc. So, it shouldn't be surprising that the API will look a lot like a Javascript transliteration of CAPI, PKCS#11, etc. in the end. Finally, I think some people perceive it as being easier to standardized "Javascript PKCS#11" than it would be to standardize several high-level "foolproof" APIs. Please also see my other response(s) in this thread.
- tptacek 14y ago
  If you want to implement a vulnerable cryptosystem, do it in pure Javascript. Concessions to the broken cryptography of the last 20 years have no place in a forward-looking browser security standard. Similarly: the industry has grown accustomed to interfaces like PKCS#11, and indeed from looking at the threads on the W3C Web Crypto mailing list, it's clear that PKCS#11 was a major influence on this proposal. But the industry has manifestly failed to enable the deployment of sound cryptosystems for 20+ years. Cryptographers have come up with new interfaces, like Keyczar and Nacl. Why aren't forward-looking standards adopting those instead of perpetuating mistakes from the '90s? Ordinarily, you wouldn't want the perfect to be the enemy of the good. But this is security and you don't get to say that here. As a developer and someone who has spent the last 8+ years dealing with the security challenges of other people's web software, I think the goal of interop with existing crypto is counterfeit. It would be extraordinarily difficult for a browser standard to capture the gory details of every widely deployed cryptosystem. You don't have a shot at "very good" interop. Meanwhile, if we could just solve the problem of getting applications a trusted cryptographically secure binding between client and client-data-stored-on-server, there's a lot of interop problems we could solve "out of band". Part of what makes interop hard is getting the details of CTR counter byte order right, sure. But another part of what makes interop hard today is just providing the baseline level of security required to make the trust model work. More people need the trust model to work than need support for backwards crypto systems. That's the problem that should get tackled first.

daeken 14y ago

> I think the main concern with a keyczar-like API is that we won't be able to create one that significant numbers of websites would actually use. I'm personally much more concerned about websites using an API with significant faults than fewer websites using a solid API. The fact that an MITM or XSS can completely undermine this makes it equivalent (outside of the secure RNG -- a definite good thing) of doing all your crypto in JS. 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.

briansmith 14y ago
> 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.

romaniv 14y ago

I think the main concern with a keyczar-like API is that we won't be able to create one that significant numbers of websites would actually use. Why not try to create one that significant number of users will use? Stuff like automatic verification of files using a hash or signing and verifying GPG signatures on web-based message boards would be tremendously useful and don't require much support on the website side.

briansmith 14y ago
Please see my other responses in this thread. I recommend people to write up proposals for such APIs and submit them to the W3C working group. It should be simple to specify them because you should literally be able to specify them directly in code based on the low-level API.