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

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 Monday, 1 October 2012 22:08:43 UTC