Subject: Re: [jose] WebCrypto feedback on key wrapping

From: Vijay Bharadwaj <[email-masked]>
Date: Wed, 20 Mar 2013 07:10:26 +0000

Some clarifications on the WebCrypto discussion:

[RLB] 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of favor with some parts of the cryptographic community.  People prefer to be able to use AEAD algorithms for key wrapping, since they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that IEEE 802.1 uses AES CCM.

[JLS] AES Key Wrap is an AD algorithm and a variant of it exists that is an AEAD algorithm.  So this is a case of not correctly using terminology.  I would also question the issue of perceived security as with AES-KW every bit of the plain text affects every other bit of plain text in the encryption process and this is not true for AES-GW or AES-CCM.  I would agree that there is both a speed advantage and perhaps more importantly the fact that only one side of the AES engine is needed (i.e. you only need to encrypt but not decrypt) for AES CCM and AES-GCM.

Perhaps "fallen out of favor" is a bit strong. It just doesn't seem to have caught on as much as other algorithms. 

The statement was that a number of people seem to prefer other AEAD algorithms for key wrapping. There are various reasons - there is a speed issue as you mentioned, and some worry about provable security. Also, if you are doing a CMS-like format such as JWE, it may be simpler to have a single algorithm for both the content encryption and key wrapping. Regardless, one sees more of the other AEAD algorithms in practice today than of AES key wrap and its variants.

[RLB] 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapped key objects, then we would need something other than OAEP in order to carry arbitrary-length payloads.  I agreed, and suggested that something like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed that KEM is troublesome due to the lack of support by native crypto libraries.

[JLS] Note that using RSA-KEM is not using RSA directly.  RSA-KEM should be thought of as a single party key agreement algorithm and not a key transport algorithm.  You encrypt a large integer and then run a KDF on that large integer to get a key.  I perceive no advantage to using RSA-KEM except for the fact that the security on it is more provable.

The discussion was more mundane than that. The underlying requirement was to be able to use RSA keys to wrap arbitrary-sized key objects. For example, using a 2048-bit RSA key to wrap a key object that itself contains a 2048-bit RSA key. Our observation was that this requires either a CMS-like approach where the wrapping key wraps a content encryption key which encrypts the inner key object, or the use of a mode like KEM, which as you note is basically the same thing.