> > I noticed an "ECB key wrap" option was discussed at the IETF meeting, > > as an alternative to AESWrap [RFC 3394]. > > > > I hadn't looked closely at AESWrap before. Its important features > > seem to be: > > 1. Only defined for content keys that are a multiple of 64-bits > > 2. Adds an overhead of 64 bits (= 8 bytes = 12 B64 chars) > > 3. Offers a 64-bit integrity check (from the overhead) > > 4. Performs 12 AES operations for each 64-bits of the content key
> Do you believe that there is an issue with saying that key sizes are > going to be a multiple of 64 bits? If so please speak up now and we can > change this Hopefully JOSE is about to use draft-mcgrew-aead-aes-cbc-hmac-sha2. That draft includes AEAD_AES_128_CBC_HMAC_SHA1 that uses a 288-bit key (128+160). Of course, JOSE may only pick the SHA2 variants whose key lengths are multiples of 64. Even the SHA2 family has a SHA-224 variant that, if used in say HMAC mode, is likely to use a key length that isn't a multiple of 64. > > I assume an ECB key wrap, in contrast, would avoid the 64-bit > > overhead by dropping the integrity check and only use 1/24th > > of the AES operations. > > Would it also use, say, ciphertext stealing so there is no size > > overhead for any content key size? > There however is an issue where you cannot encrypt more than 128-bits > of key material. This means that it would not be usable for many algorithms > that are in the current specification. Is the 64-bit integrity check in AESWrap crucial for its ability to wrap more than a block size of key material? No, was my guess. In which case it should be theoretically possible to save that little bit of space when wrapping a key using some ECB/CBC/ciphertext-stealing mode (though it might only be safe if every possible plaintext of the given length is a valid key, and an AEAD-layer provides integrity over the wrapped key). -- James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
