Re: Support for ECB - proposal for a decision

On Mon, Oct 1, 2012 at 2:20 AM, Zooko Wilcox-OHearn <
zooko@leastauthority.com> wrote:

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

Hi Zooko,

Your response seems to confirm what I was describing as unacceptably
complex - that is, that the only "security" being afforded here is that
through making it complex.

The question of "vector AES" vs "streaming AES", is, I think, a misdirect.
A well-behaved implementation can make optimizations to treat the
"streaming" AES "as if" it was vectorized, but the converse does not hold.
You're conflating a calling style (that is, forcing the caller to chunk it)
with the implementation (that is, a parallel implementation), which is
further misleading as to the actual benefits.

What's clear is that there does seem to be consensus on the need for what
you call a "raw" AES function, and the only disagreement is on the method
signature. I see no benefit from creating an entirely new set of calling
sequences and method signatures just to satisfy the need for
security-through-complexity, especially when the complexity is trivial to
defeat, by making the more complex example follow the simple one. Such a
solution would only have benefit for the first two or three consumers of
the API, and then the remaining users would simply use the wrapped solution.