Re: Bug # 24410 - AES CTR descriptions

On Thu, Feb 20, 2014 at 4:30 PM, Mark Watson <watsonm@netflix.com> wrote:

>
>
>
> On Thu, Feb 20, 2014 at 4:13 PM, Jim Schaad <ietf@augustcellars.com>wrote:
>
>>
>>
>>
>>
>> *From:* Mark Watson [mailto:watsonm@netflix.com]
>> *Sent:* Thursday, February 20, 2014 2:16 PM
>> *To:* Jim Schaad
>> *Cc:* public-webcrypto@w3.org
>> *Subject:* Re: Bug # 24410 - AES CTR descriptions
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 20, 2014 at 2:04 PM, Jim Schaad <ietf@augustcellars.com>
>> wrote:
>>
>> There is a potential missing check that the length of plaintext be less
>> than 2^length.  It is easy for people to miss the requirement that all of
>> the CTR values be unique.
>>
>>
>>
>> Do you mean that the plaintext length must be less than 2^length blocks
>> for AES-CTR ? Should this actually be an error, or is it just something we
>> should recommend ?
>>
>>
>>
>> [JLS] This is an error in the mode by definition.  From SP 800-38A
>>
>> The sequence of
>>
>> counters must have the property that each block in the sequence is
>> different from every other
>>
>> block.
>>
>>
>>
>> This is only an issue if someone chooses an absurdly small value of
>> length, however it is an error that can and probably should be caught.
>>
>
> I filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24758
>

On reading the text in SP 800-3A, it further states that the condition
must be maintained across all messages encrypted with the same key. So this
is not a condition that can be enforced by the algorithm implementation, it
is in fact a requirement on both the method of generating counters (which
is in a separate section) and *how that is used by the application* - both
the choice of length and the choice of initial counter value.

So, it's ambiguous to me whether an implementation should consider it an
error if the length choice combined with the message size will cause the
same counter value to be repeated.

What we should probably look at is what existing library implementations
do. If some implementations consider this an error - and fail - then it
would improve interoperability if WebCrypto would always fail in this case
by including the length check described. If no existing implementations
consider this an error, then it should be left to the application as only
the application can fully policy the requirement across messages.

...Mark



>
>
>>
>>
>>
>> I realize that the restriction is to be imposed over all uses of the key,
>> but is a simple check that could be included.
>>
>>
>>
>> **
>>
>> Do we really want to allow for wrapKey/unwrapKey to be permitted
>> operations for AES-CTR mode?  There is no integrity on the key and it's
>> value is simple to change.  This could be a potential security attack.  ( I
>> note also that the wrap and unwrap functions are not defined, so I assume
>> this is a cut and paste error).
>>
>>
>>
>> Presently, wrap / unwrap works for any algorithm that supports encrypt /
>> decrypt because we have defined wrap = export + encrypt and unwrap =
>> decrypt + import.
>>
>>
>>
>> If we wanted to restrict to specific algorithms (which I agree could be a
>> good idea), then we could define wrap / unwrap operations for the
>> algorithms that we want to work, so then we would have <warp method> =
>> <export operation> + <wrap operation> and <unwrap method> = <unwrap
>> operation> + <import operation>.
>>
>>
>>
>> That actually seems sensible to me, although it involves duplicating some
>> text (e.g. for AES-GCM the <unwrap operation> will be identical to the
>> <decrypt operation>).
>>
>>
>>
>> [JLS] The purist in me would really prefer that they were treated as
>> different things.  Some algorithms are designed to be able to wrap keys and
>> some are not.   Additionally, there might be additional error checks that
>> need to be done - or different padding that might be used for some
>> algorithms based on either the algorithm that is being wrapped or the
>> format that is being used.  For example, there may be slightly different
>> padding and error checks for RSA depending on if you are using raw or jwk
>> as the format.  (I don't know that this is true, I should probably think
>> about it some day.)
>>
>>
>>
>> If we are going to treat them as the same thing then there are a number
>> of other things that need to be done.  For example, the operation table at
>> the top of AES-CTR needs to add wrapKey and unwrapKey as lines with
>> AesCtrParams as Parameters.
>>
>
> Ok, I'll make them different under 24110 work.
>
> ...Mark
>
>
>
>>
>>
>>
>>
>>
>>
>> ...Mark
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Jim
>>
>>
>>
>>
>>
>> *From:* Mark Watson [mailto:watsonm@netflix.com]
>> *Sent:* Wednesday, February 19, 2014 4:54 PM
>> *To:* public-webcrypto@w3.org
>> *Subject:* Editors' Draft update
>>
>>
>>
>> All,
>>
>>
>>
>> I have just updated the Editors' Draft [1] as follows:
>>
>>
>>
>> Bug 24410 - operation descriptions for AES CTR:
>> https://dvcs.w3.org/hg/webcrypto-api/rev/1d45ba72099d
>>
>> Bug 24410 - operation descriptions for AES CBC:
>> https://dvcs.w3.org/hg/webcrypto-api/rev/50d83a6fae47
>>
>> Bug 24410 - operation descriptions for AES CFB-8:
>> https://dvcs.w3.org/hg/webcrypto-api/rev/f7a0c1209ddf
>>
>> Bug 24410 - operation descriptions for AES GCM:
>> https://dvcs.w3.org/hg/webcrypto-api/rev/1ed0fb7da636
>>
>> Bug 20611 - specify JWK encoding as UTF-8:
>> https://dvcs.w3.org/hg/webcrypto-api/rev/66bec4453de5
>>
>> Bug 24410 - operation descriptions for AES-CMAC:
>> https://dvcs.w3.org/hg/webcrypto-api/rev/768a11dba263
>>
>> Bug 24410 - operation descriptions for AES-KW and associated method
>> updates: https://dvcs.w3.org/hg/webcrypto-api/rev/0fee8e979b4f
>>
>> Stylistic consistency / correctness for operation descriptions:
>> https://dvcs.w3.org/hg/webcrypto-api/rev/fbc6ef272ace
>>
>>
>>
>> Please review these changes and send comments to the list.
>>
>>
>>
>> Best ... Mark
>>
>>
>>
>> [1] https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
>>
>>
>>
>
>