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

Re: Support for ECB

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 11 Sep 2012 11:15:47 -0700
Message-ID: <CACvaWvZAop2CeRBGr7ddwjbi_cRiRn2VmtzOveM4D1WLkk6=Cg@mail.gmail.com>
To: public-webcrypto@w3.org
Sorry, Zooko and I accidentally dropped the list from the cc.
Forwarding Zooko's response and mine inline.

---------- Forwarded message ----------
From: Ryan Sleevi <sleevi@google.com>
Date: Mon, Sep 10, 2012 at 3:39 PM
Subject: Re: Support for ECB
To: Zooko Wilcox-OHearn <zooko@leastauthority.com>

On Mon, Sep 10, 2012 at 3:28 PM, Zooko Wilcox-OHearn
<zooko@leastauthority.com> wrote:
>>> Why not include a naked AES function, but don't list it among the
>>> optional modes and don't call it "ECB mode"? Call it "bare_AES" and
>>> specify it to raise an exception unless the data input is exactly one
>>> block long.
>> While I understand the desire to make it "harder to use == harder to
>> get wrong", I'm concerned that the latter requirement would be a real
>> loss for possible performance.
> You mean if someone wants to use ECB mode. But, ECB mode is insecure,
> so why make it fast? Whereas using a bare AES block function (i.e. as
> a component in a larger cryptosystem or a custom CTR mode or
> something) never invokes the AES block function with anything other
> than a 16-byte input.
>> (like implementing CCM atop ECB)
> I'm not that familiar with CCM, but wouldn't you implement it on top
> of CTR, not on top of ECB?

However, that's only if an implementation supports CTR. I imagine not
all will. I'm sure Mitch and Mark can speak more to this, but my
experience is that a number of set top boxes that have crypto hardware
only support ECB. So there's a question about whether the user agent
will polyfill the CTR implementation, or if it will expect the content
script to do so.

My own vote would to avoid *requiring* user agents to implement CTR
themselves, regardless of how 'easy' it may be.

> As far as I'm aware there are only two kinds of use cases for bare AES:
> 1. "ECB mode": applying "AES(k1, blockN)", with the same k1, to each
> successive 16-byte block of some input. This is insecure and I'm not
> aware of any good reason to do it.

To bootstrap any of the following modes with suitable performance

CTR || CCM (which starts with CTR) || GCM (which starts with CTR)

> 2. Using an AES block function: applying "AES(k1, block1)" to a single
> specific 16-byte value. Used in constructs like MACs (UMAC, Poly1305,
> VMAC), Davies-Meyer hash functions, etc.
> Regards,
> Zooko Wilcox-O'Hearn
> Founder, CEO, and Customer Support Rep -- Least Authority Enterprises
> https://leastauthority.com
Received on Tuesday, 11 September 2012 18:16:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:13 UTC