Re: Support for ECB - proposal for a decision

On Wed, Sep 26, 2012 at 4:25 AM, Zooko Wilcox-OHearn
<zooko@leastauthority.com> wrote:
> Hi Tom, thanks for the reply.
>
> On Tue, Sep 25, 2012 at 8:58 PM, Tom Ritter <tom@ritter.vg> wrote:
>>
>> without ECB mode, I don't believe it would be possible to implement OpenPGP's CFB variant: http://tools.ietf.org/html/rfc4880#section-13.9
>
> I don't follow. Wouldn't you use a simple AES function to implement
> PGP CFB? It isn't amenable to parallel processing since the N+1'th
> block depends on the output of the N'th block's encryption. (Is that
> right? I don't understand that mode very well.)
>
> Just to be clear, I consider these two things to be very different:
>
> 1. A function which, if its input is ≤ 16 bytes, returns the
> encryption of that input with AES, and if the input is > 16 bytes,
> raises an exception.
>
> 2. A function which, it its input is ≤ 16 bytes, returns the
> encryption of that input with AES, and if the input is > 16 bytes,
> leaks the input (or at least partial information about the input) to
> any eavesdroppers.
>
> I regard the former, which I call a "bare AES function" as an
> unquestionable necessity for the WebCrypto low-level API, and the
> latter, which I call "ECB mode" as both dangerous and unnecessary. The
> fact that some people think that the difference between these two
> functions isn't worth formalizing just perplexes me, quite honestly.
>
> I understand how they are quite close to each other in the abstract,
> but to my mind, the difference between them matters a great deal in
> practice. A bare AES function is necessary for all sorts of useful
> crypto such as Bitlocker. ECB mode is used either never or very
> rarely, except in unsafe ways that can endanger the lives and safety
> of innocent users.
>
> If I understand correctly, to implement PGP CFB mode, you could use a
> simple AES function, and an ECB mode or a vectorized AES function such
> as I suggested recently wouldn't be a performance improvement. Is that
> right?
>
> Thanks!
>
> Regards,
>
> Zooko Wilcox-O'Hearn
>
> Founder, CEO, and Customer Support Rep
>
> https://LeastAuthority.com/
>

Zooko,

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.

Instead of calling such a raw AES function "ECB", as the inputs and
output behaviours are fundamentally indistinguishable, and which might
take an ArrayBufferView of 64 bytes, you would prefer to see a
"vectorized AES function", which instead takes 4 ArrayBufferViews of
16 bytes.

I'm sorry, but if that's a correct understanding of your position, I
would find it unacceptably complex with no actual security benefit. It
sounds like even you agree that a raw AES function plays an important
part in at least some of these use cases, and so now we're simply
discussing how it should look.

I think it's unreasonable to think the complexity will be of any
value. I imagine that within hours of the first implementation of your
proposed scheme going live, people will have polyfilled it to simply
do

function wrappedUpdate(CryptoOperation operation, ArrayBufferView buffer) {
  var blocks = (buffer.length + 15) / 16;
  for (i = 0; i < blocks; ++i) {
    var tmp_buffer = new DataView(buffer.buffer, buffer.byteOffset +
(i * 16), 16);
    operation.processData(tmp_buffer);
  }
}

Alteratively, with vectorized update
function wrappedUpdate(CryptoOperation operation, ArrayBufferView buffer) {
  var blocks = (buffer.length + 15) / 16;
  var vectors = []
  for (i = 0; i < blocks; ++i) {
    vectors.push(new DataView(buffer.buffer, buffer.byteOffset + (i * 16), 16);
  }
  operation.vectorizeData(vectors);
}

With those few (probably buggy) lines, any benefits of "security
through complexity" are undermined so completely that it simply
becomes an added cost for every developer who knows what they're
doing, and absolutely no deterrent for anyone who doesn't.

That's why I think the proposal for some distinct operation is
unacceptably complex and fails to achieve what it sets out to, and
calling it ECB, given that it's functionally indistinguishable, is
simply the correct approach here.

Received on Wednesday, 26 September 2012 19:02:20 UTC