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 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? If a 12 byte overhead (when base64url-encoded) is too small to worry about (and an extra, say, 46 AES operations is immaterial), then JOSE should keep AESWrap as the only choice. It still need to define how to use AESWrap for content keys that are not a multiple of 64-bits. Perhaps one byte of the integrity check is changed to indicate the content key length? If size is going to be absolutely crucial for some use cases, then an ECB key wrap could help. Such a size-constrained situation would probably need other changes as well, such as the choice of a shorted IV and integrity tag for AES-GCM (than the 128-bits and 96-bits picked in JWA). -- James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
