Re: my revised proposal for ECB (was: Support for ECB - proposal for a decision)

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