RE: Bug # 24410 - AES CTR descriptions

 

 

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 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.   

 

 

 

...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