RE: Bug # 24410 - AES CTR descriptions

[Mark]> 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.

[Mark]> 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.

Windows crypto APIs (CAPI and CNG) do not expose CTR mode except as a component of GCM or CCM. However it does seem to me like the counter increment rule and message size give a way for the implementation to identify some cases of insecure usage. It seems reasonable to block these cases - I don't see any legitimate use for them.

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Friday, February 21, 2014 9:16 AM
To: Jim Schaad
Cc: public-webcrypto@w3.org
Subject: Re: Bug # 24410 - AES CTR descriptions



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


On Thu, Feb 20, 2014 at 4:13 PM, Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:


From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
Sent: Thursday, February 20, 2014 2:16 PM
To: Jim Schaad
Cc: public-webcrypto@w3.org<mailto: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<mailto: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<mailto:watsonm@netflix.com>]
Sent: Wednesday, February 19, 2014 4:54 PM
To: public-webcrypto@w3.org<mailto: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