Re: Support for ECB - proposal for a decision

I'm sorry I missed the conference call yesterday. I'll endeavour to
attend the next one.

I had an idea inspired by Ryan's arguments about efficiency, that I
haven't had time to properly write up and send to the list. Ryan's
argument that ECB mode could used as a more efficient way to apply the
AES function to a series of input blocks does motivate me. Efficiency
is (sometimes) important.

The idea is: we define a "vector AES" function or "SIMD AES" function,
which takes as its arguments an array of 16-byte blocks and a key.
This would hopefully be more discoverable to someone who is looking
for applying AES in vector form for efficiency (so that they won't be
like I was, and overlook the option of using ECB mode for that
purpose), and it would hopefully be *less* discoverable to someone who
is looking for AES encryption of a variable-length plaintext.

Other operations could also be more efficient in a vector, or "batch",
application, such as application of an HMAC to an array of messages,
yielding an array of tags, which could be performed in parallel
instead of in series if the spec provided a "vector HMAC" call. Or
vector application of a hash function to an array of inputs, yielding
an array of hash values in a "vector SHA-256" call. That could be much
more efficient (on certain architectures involving SIMD and/or
multiple processors) than the equivalent loop over a "single SHA-256"
call.

Some crypto operations can be optimized in even funkier ways than the
normal parallelization/SIMD optimization, such as "batch forgery
identification" in digital signatures.


I think the proposal of providing ECB mode as one of the listed modes
of operation, but including documentation warning about it, is the
same thing that has been tried many times before and has lef to
failures. As I've said, misuse of ECB mode is very common. It happens
so often that another such security failure crossed my desk during
this very conversation. Well, those libraries that have been misused
in that way often include documentation warning about ECB mode. The
recent one that I mentioned — PyCrypto — had this warning in the
documentation of its implementation of ECB mode: “This mode exposes
frequency of symbols in your plaintext. Other modes (e.g. CBC) should
be used instead.” ¹.

Perhaps such warnings have historically not been phrased strongly
enough. Perhaps instead the documentation could say something like
“This mode is insecure when used to encrypt plaintext. It leaks
information about the plaintext, and in many cases the entire
plaintext can be recovered from that information. Do not use this mode
of operation for encryption. It is provided only for use as a
parallelized application of the AES function to non-secret inputs,
such as for implementing a custom CTR mode with a non-standard counter
sequence.”.

However it seems likely that the programmers don't really read or
understand the warning in the PyCrypto documentation. Perhaps they
look at the list of the modes of operation, see that one of them is
easier to use because it doesn't require a mysterious object called an
"IV", and so they use that mode.

The suggestion that we should specify a standard for ECB mode for
efficiency reasons carries some weight with me. Efficiency (sometimes)
matters. I wonder if the proposal above to make a feature which is
explicitly useful for vector efficiency would satisfy that need.

But I don't agree with reason that we should specify a standard for
ECB mode because people currently use it. I haven't seen evidence that
our users use ECB mode. I've never seen a use of ECB mode which wasn't
fatally insecure and didn't require immediate alteration or
mitigation. I've *heard* of one (from a fellow named "CodesInChaos" on
IRC a couple of weeks ago), but he hasn't published his work, and
anyway if he is the only person who has done that then it is a very
rare usage. I think the idea that people use ECB mode might be a
mistaken impression from people using a straight AES function, such as
Vijay saying that Microsoft's Bitlocker software uses ECB mode, when
in fact it does not.

If anyone else has examples of people using ECB mode in practice,
either securely or insecurely, please share them with me.

Thanks, folks!

Regards,

Zooko

¹ https://www.dlitz.net/software/pycrypto/api/current/

Received on Wednesday, 26 September 2012 02:51:14 UTC