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

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