RE: Support for ECB

The biggest problem with "unsafe namespace" ideas is that they lead to an ongoing maintenance nightmare.

At some point in the future, an algorithm which is considered good today will be broken. How will we move it to the unsafe namespace without breaking apps wholesale? And how will we ensure that all browsers make the change at the same time, to avoid inconsistencies? And who gets to decide when an algorithm is broken?

And that's leaving aside the issue of who gets to decide the initial list of unsafe algorithms. For instance, would SHA-1 be considered unsafe today? What to do about algorithms that are unsafe only under certain conditions (e.g. SHA-1 may be unsafe for collision resistance but not for preimage attacks, GCM is unsafe if you repeat nonces, there are many unsafe ways to use RC4 but also some safe ways)?

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Thursday, September 13, 2012 10:38 AM
To: Richard Barnes
Cc: Emily Stark; Zooko Wilcox-OHearn; public-webcrypto@w3.org
Subject: Re: Support for ECB

On Thu, Sep 13, 2012 at 10:28 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> By "unsafe namespace", do you mean that we would put things like ECB under a special namespace to say "Don't use these unless you know what you're doing?"

Yes.

The exact details of how to do that are not immediately clear. Under the current spec, this might require using a separate algorithm name -
eg: UNSAFE-AES-ECB - or require using a separate implementation of the Crypto interface (eg: window.crypto.unsafe.createEncrypter('AES-ECB'
...)


>
>
>
> On Sep 13, 2012, at 12:41 PM, Emily Stark wrote:
>
>> I can't find discussion on the mailing list about the unsafe namespace idea (maybe my search skills are failing me) -- are there arguments against it?
>>
>>
>> On Thu, Sep 13, 2012 at 12:17 PM, Zooko Wilcox-OHearn <zooko@leastauthority.com> wrote:
>> On Tue, Sep 11, 2012 at 12:15 PM, Ryan Sleevi <sleevi@google.com> wrote:
>> >
>> > To bootstrap any of the following modes with suitable performance
>> > characteristics:
>> >
>> > CTR || CCM (which starts with CTR) || GCM (which starts with CTR)
>>
>> I don't understand how a situation could arise where a programmer 
>> would need to use ECB mode to implement these (or for any other 
>> purpose). It seems like that situation would arise only if the 
>> underlying platform offered ECB mode but not CTR mode. But why don't 
>> we just discourage implementors from offering ECB mode and encourage 
>> them to offer CTR mode? (And, as previously suggested, encourage them 
>> to offer an AES block-encryption function that operates on only a 
>> single block.)
>>
>> Regards,
>>
>> Zooko Wilcox-O'Hearn
>>
>> Founder, CEO, and Customer Support Rep -- Least Authority Enterprises
>>
>> https://leastauthority.com
>>
>>
>

Received on Friday, 14 September 2012 14:18:57 UTC