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