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

Dear Ryan:

I'm actually quite sympathetic to your argument that the security of
an app is ultimately determined more by the authors of that app than
by the authors of the crypto library's API. That is the sort of
argument that is very plausible to me, and I'm sure that it is often
correct.

However, we also have empirical evidence to the contrary: that
sometimes the design of the crypto API can determine the security of
the apps that use it. There are plenty of historical examples of apps
using ECB mode for encrypting plaintexts and thus failing to provide
confidentiality, but of course the meaning of such examples is open to
interpretation. You can always wonder if the security failure wasn't
due to writers of the app rather than to the crypto library that they
used. Maybe the same app writers would have made a different fatal
mistake if the library hadn't offered them ECB mode.

That's why this recent example of the "Beaker" middleware is so
informative: it is a case where the same people (the maintainers of
Beaker), addressing exactly the same use case, implemented it twice
using two different crypto APIs. One implementation was flawed due to
its use of ECB mode, and users that rely on it are vulnerable to
having their sessions hijacked by an attacker. The other
implementation — using the crypto library that I designed — has no
such vulnerability.

This should be taken as evidence that crypto API design can affect the
safety of actual people.

This is something that I value.

Now, this doesn't mean that all other values pale in comparison and we
have to spend the rest of our lives debating how many security angels
can dance on the head of a pin. Engineering is about trade-offs, and
I'm willing to support trade-offs that sacrifice some of my values in
order to gain more of others. I agreed, in last week's conference
call, to support the inclusion of ECB because it can be used to
implement certain other algorithms efficiently, and among efficient
ways to do that, it is the easiest for everyone to understand.
Efficiency and ease of understanding are things I value, too.

So, if you're willing to go along with this, then let's talk about how
to spell out the standard in a way that is easy for us to finish
writing and for others to read, and also, if possible, avoids leading
our readers into traps. My current proposal is to avoid classifying
ECB as an "encryption mode" like CBC or CTR, since that is what
previous APIs have often done, and it has often led people into
thinking that ECB can be used to encrypt their data, which it can't
safely do. (* Except in the case that their data is <= 16 bytes in
length.)

In addition to the possible benefit of avoiding such security
failures, this kind of documentation may also aid readability, which
you've said is a value to you.

How about 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
 • Hash functions: SHA-2-256, SHA-3-256
 • Primitives: AES-ECB

I also still want us to agree on a clearly worded warning message in
the documentation of ECB. The text I suggested earlier still sounds
good to me:

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

This is more accurate than, for example, the warning about ECB in the
OWASP glossary ¹:

"This mode should not be used under any circumstances."

☺

As to the issues about padding, I think what you wrote is right. ECB's
issues with padding are the same as CBC's and no doubt we'll want
their APIs to handle padding in the same way.

¹ http://owasp.com/index.php/Glossary#Electronic_Code_Book_mode

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com

Received on Monday, 8 October 2012 03:33:16 UTC