W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2012

Re: Support for ECB - proposal for a decision

From: Zooko Wilcox-OHearn <zooko@leastauthority.com>
Date: Mon, 1 Oct 2012 03:20:19 -0600
Message-ID: <CAM_a8JxzDUO0WrTZ_p83pwwRg-G=FgRV_b3th10YJvZk0--APA@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: Tom Ritter <tom@ritter.vg>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Wed, Sep 26, 2012 at 1:01 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
> Apologies if I'm misinterpreting, but it seems your argument boils
> down to feeling that the AES function should have special/unique
> semantics from other algorithms. You feel that this will somehow
> result in better security, by virtue of it being harder to use and
> behaving unlike any other algorithms we may specify.

Dear Ryan:

I'm afraid I don't quite understand your interpretation of my
argument, above. I'm sorry if my arguments have been unclear. I'll try
again.

Let me try to separate things I'm claiming are facts from things that
are just my opinions...

In fact, as I compose this letter, it is filling up with things that I
claim are facts, so I'll spare you another rendition of my opinions
this time around!

The first two claims below are the most important ones.

(Here I'm using the phrase "AES function" to mean a function which
takes a 16-byte input and returns a 16-byte output, and "ECB mode" to
mean a function which takes a variable-length input and returns an
output of the same length.)

• I claim as fact: it is very common in practice for ECB mode to be
misused, which leads to a failure of confidentiality. This is very
common. An advisory reporting on a case of this crossed my desk during
this very conversation:
http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0146.html
. The bug described there is a typical example of its kind, and was
fatal to the security of the system.

I hypothesize that this is because ECB mode is typically listed as a
"mode of operation" next to CBC mode and CTR mode and so on (often
accompanied by documentation warning about it) and since ECB mode
doesn't requre an IV it is simpler for programmers to start using
compared to CBC mode.

• I claim as fact: correct use of ECB mode (as distinguished, here,
from an AES function) is rare in practice. I haven't seen any examples
with my own eyes. I've heard tale of one such use, from CodesInChaos,
to implement CTR mode in a platform that offered ECB but not CTR. Ryan
and Vijay on this list suggested possible uses of ECB mode to
implement other modes, but these are hypothetical proposals, not
examples of current usage. More recently, Nick Mathewson suggested to
me on twitter that one could use ECB mode to implement XTS. If you
have other examples of ECB mode being used in practice, I would like
to learn about them.

• I claim as fact: the following security properties hold:

◦ OCB, CCM, EAX, and GCM: you put in a secret plaintext, key, and IV,
and you deal with the resulting ciphertext and tag. It provides
confidentiality as long as the key is secret and unguessable and the
IV is not re-used, and it provides integrity as long as the tags are
tested and handled correctly. The name for this class of mode is
"authenticated encryption mode".

◦ CBC, CTR, OFB, and CFB: you put in a secret plaintext, key, and IV,
and you deal with the resulting ciphertext. It provides
confidentiality as long as the key is secret and unguessable and the
IV is not re-used. It does not provide integrity. (Aside: and since it
is more or less never okay to rely on confidentiality without
integrity protection, any system which stops here is likely to be
unsafe.) The name for this class of mode is "unauthenticated
encryption mode".

◦ ECB: you put in a secret plaintext and key, and you deal with the
resulting ciphertext. It provides confidentiality as long as the key
is secret and unguessable and the plaintext is <= 16 bytes in length.

• I claim as fact: an  AES function is necessary to implement a great
many standard or obscure cryptographic constructions, including to
implement CBC mode, CTR mode, Bitlocker IV generation, cipher-based
hash functions, and thousands of other, more obscure, crypto
constructs. I claim as fact: ECB mode is not necessary to implement
any of them.

• I claim as fact: a vector-AES function which takes an array of
16-byte blocks would probably be at least as efficient as an ECB
function, for example in a program implementing CTR mode or XTS mode.
The vector API might actually be more efficient, if the implementation
uses multiple cores.

• I claim as fact: many other kinds of algorithms, if made available
in a "vector" API, would thereby become amenable to SIMD,
parallelization, or even "batch cryptography" optimizations. SIMD or
parallel computation of a secure hash function tends to be about 2X to
4X as efficient as serial computation of the same hash, and recent
improvements in batch forgery identification offer up to a 3X
reduction in number of required algebraic operations. In order to
facilitate such performance optimization, a future cryptography API
might provide vector versions of all of the standard algorithms: here
is a function which takes a public key and an array of messages and
returns an array of ciphertexts, here is a function which takes a MAC
key and an array of messages and tags and returns an array of booleans
indicating whether each one was valid, etc. In such a vector API, a
vector AES function would fit right in.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep

https://LeastAuthority.com
Received on Monday, 1 October 2012 09:20:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 1 October 2012 09:20:49 GMT