Re: Bug #23500 - Raw AES Access

On Thu, Feb 20, 2014 at 12:29 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:

>  Can someone please write the note that Jim described on how to use CTR
> to build new modes, including ECB?  Then I'm ok with closing.
>

Do you mean a note in the specification ?

Isn't Jim just referring to the fact that if I encrypt a single block with
AES-CBC with IV = 0 I get the same result as ECB applied to that single
block ?

Or if I encrypt a zero block with AES-CTR with IV = X I get the same result
as ECB applied to X ?

...Mark




>
> -- Mike
>  ------------------------------
> From: Richard Barnes <rlb@ipv.sx>
> Sent: 2/20/2014 12:26 PM
> To: Mark Watson <watsonm@netflix.com>
> Cc: Jim Schaad <ietf@augustcellars.com>; public-webcrypto@w3.org
> Subject: Re: Bug #23500 - Raw AES Access
>
>  Fine with me.
>
>
> On Thu, Feb 20, 2014 at 3:19 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>>  So, does anyone object to closing Bug 23500 as WONTFIX ?
>>
>>  ...Mark
>>
>>
>> On Wed, Feb 19, 2014 at 9:42 AM, Jim Schaad <ietf@augustcellars.com>wrote:
>>
>>>  Take #2 on this issue.
>>>
>>>
>>>
>>> Looking at things last night, as long as we don't have a streaming mode
>>> of operation, it does not appear that using a ECB mode is going to be any
>>> more efficient than using either CBC or CTR as the basis for building
>>> something like an SIV mode.  Since one is going to need to create a new
>>> encrypt Promise for each block in order to chain things together.
>>>
>>>
>>>
>>> Since this means that currently the only way to  be use ECB mode in an
>>> efficient manner is to use it as ECB, I would say that we should not
>>> include it.  It might however be worth having a note about how to use CTR
>>> mode to build new modes in the future in script.
>>>
>>>
>>>
>>> This decision would then be re-visited when we have streaming as a
>>> primitive operation.
>>>
>>>
>>>
>>> Jim
>>>
>>>
>>>
>>
>>
>