- From: Harry Halpin <hhalpin@w3.org>
- Date: Thu, 04 Oct 2012 15:09:36 +0200
- To: Zooko Wilcox-OHearn <zooko@leastauthority.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Please read and comment! I suggest we get consensus on this proposal on our next call. Myself, I can see myself agreeing with all parts except possibly 2., even though its a standard requirement, it seems odd making ECB have such special parameters. However, the magic words are "I can live with that", which I can. On 10/02/2012 12:08 AM, Zooko Wilcox-OHearn wrote: > Folks: > > I apologize again for being late to today's call. Here is my current > proposal in light of today's discussion. > > 1. We agreed that WebCrypto should specify ECB. (This is a change from > my earlier position. I agree to specifying ECB because it could be > more efficient to compute AES on a number of blocks at once, such as > when implementing an encryption mode of operation.) > > 2. I propose that the ECB function take a number of input bytes which > is an integer multiple of 16, and raise an exception if the input is > of a different length. That's the standard requirement for ECB. > > 3. I propose that the API and documentation clearly signal that ECB is > not an encryption mode. Specifically, I propose that the algorithms > are grouped like this: > > • Public key encryption: RSA-OAEP, RSAES-PKCS1-v1_5 > • Public key digital signature: ECDSA, RSA-PSS, RSASSA-PKCS1-v1_5 > • Key agreement: ECDH, Diffie-Hellman > • Authenticated encryption: AES-OCB, AES-GCM > • Unauthenticated encryption: AES-CTR, AES-CBC > • Message authentication code: HMAC-SHA256 > • Key-derivation functions: HKDF, PBKDF2 > • Primitives: AES-ECB, SHA256 > > And I propose that the documentation of the AES-ECB function say > something like this: > > "NOTE: This function does not, except in special cases, conceal the > content of the message and cannot, except in special cases, be used > for encryption. It is included only for the use of cryptographers to > implement other cryptographic algorithms. For an encryption function, > please see the functions listed under Authenticated Encryption or > Unauthenticated Encryption." > > > As a framing note: I care a lot about the security of apps. My work is > sometimes used by people who risk suffering not just financial loss > but imprisonment, torture, or murder, if the confidentiality and > integrity that they need from their apps isn't there. Our work here is > destined to be used that way, too. People are already using web apps > such as Crypto.cat to say things that could get them murdered or > imprisoned if the wrong people overhear, and this trend will increase > greatly in the coming years. > > Older crypto libraries such as Crypto++ ¹, Java ², and .NET ³ > typically included ECB among a list of encryption modes, sometimes > with a warning note in the documentation. This has been repeatedly > demonstrated to lead to insecure apps which use ECB mode for > encryption of secret plaintexts. It is not hypothetical that ECB > *could* lead to this -- it is established fact that it has done so, > many times. It is such a common pattern that another instance of it > was announced while we were having this very conversation: ⁴. In that > case, a library which included ECB (with warning documentation) > adjacent to CBC mode and CTR mode led to web sites in which attackers > could take over the sessions of authenticated users. A different > library (which I wrote) which excluded ECB mode was not vulnerable to > that attack. > > So it is important to me that the WebCrypto standard doesn't replicate > these practices which have led to these vulnerabilities. My proposal > above will, I hope, avoid that. > > Regards, > > Zooko Wilcox-O'Hearn > > Founder, CEO, and Customer Support Rep > > https://LeastAuthority.com > > ¹ http://www.cryptopp.com/wiki/ECB_Mode > ² http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#Cipher > ³ http://msdn.microsoft.com/en-us/library/system.security.cryptography.ciphermode.aspx > ⁴ http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0146.html >
Received on Thursday, 4 October 2012 13:09:49 UTC