Re: Bug 24457 - AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long

+1


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

> I would concur with this analysis.
>
>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Thursday, February 20, 2014 12:44 PM
> *To:* public-webcrypto@w3.org
> *Subject:* Bug 24457 - AES-KW can only wrap a JWK key if its
> serialization happens to be 8*n bytes long
>
>
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24457
>
>
>
> I truely wish bugs would get copied to the list...
>
>
>
> Here is my latest post on this bug for more general comment:
>
>
>
> I discussed this issue with our security experts.
>
>
>
> The contention is that the security assumptions underlying the design AES Key Wrap make it unsuitable for wrapping keys in a format which does not have a canonical representation for a given key. (For example JWK, where there can be arbitrary additional members which will be ignored on reception).
>
>
>
> We don't agree with this contention.
>
>
>
> >From the introduction of http://csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf (pay special attention to the first sentence, and then the second paragraph):
>
>
>
> "This specification is intended to satisfy the NIST Key Wrap requirement to: Design a cryptographic algorithm called a Key Wrap that uses the Advanced Encryption Standard (AES) as a primitive to securely encrypt a plaintext key(s) with any associated integrity information and data, such that the combination could be longer than the width of the AES blocksize (128-bits). Each ciphertext bit should be a highly non-linear function of each plaintext bit, and (when unwrapping) each plaintext bit should be a highly non- linear function of each ciphertext bit. It is sufficient to approximate an ideal pseudorandom permutation to the degree that exploitation of undesirable phenomena is as unlikely as guessing the AES engine key. This key wrap algorithm needs to provide ample security to protect keys in the context of a prudently designed key management architecture.
>
>
>
> Throughout this document, any data being wrapped will be referred to as the key data. It makes no difference to the algorithm whether the data being wrapped is a key; in fact there is often good reason to include other data with the key, to wrap multiple keys together, or to wrap data that isn't strictly a key. So, the term "key data" is used broadly to mean any data being wrapped, but particularly keys, since this is primarily a key wrap algorithm. The key used to do the wrapping will be referred to as the key encryption key (KEK). In this document a KEK can be any valid key supported by the AES codebook. That is, a KEK can be a 128-bit key, a 192-bit key, or a 256-bit key."
>
>
>
> I also note that NIST SP800-38F states, in Section 3.1:
>
>
>
> "Although KW can be used in conjunction with any reversible padding scheme,.." suggesting that the design of the padding scheme does not, in fact, affect the security properties.
>
>
>
> and
>
>
>
> "Similarly, KW, KWP, and TKW are each approved for the protection of general data, as well as cryptographic keys."
>
>
>
> Also,
>
>
>
> "KW, KWP, and TKW are each robust in the sense that each bit of output can be expected to depend in a nontrivial fashion on each bit of input, even when the length of the input data is greater than one block"
>
>
>
> in contrast to, say, AES-GCM where each bit of ciphertext depends only on plaintext bits in the same or preceding blocks. One might naively expect that the above property of AES-KW makes attacks based on modification of the trailing end of the ciphertext (padding attacks) *more* difficult than with AES-GCM.
>
>
>
> The security considerations of NIST SP800-38F do not make reference to any assumptions about the nature of the plaintext.
>
>
>
> Finally, as far as we're aware, no practical attacks against AES-KW are known.
>
>
>
> So, I would conclude from the above that there is no issue using AES-KW to wrap JSON data. Yes, the specification must state that it is an error to provide data that is not a multiple of 64 bits to AES-KW, but I see no problem with implementations that wrap JSON ensuring that the JSON object is a multiple of 8 characters - whilst still remaining a valid JSON string - by whatever means they choose, without needing any requirement in the specification to do so (of course, adding such a requirement would improve interoperability.)
>
>
>
> ...Mark
>
>