2 ms·

> 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 vuln

> 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.

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.