> 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
No I don't believe that all keys would fit into this category -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Tuesday, August 07, 2012 12:03 PM To: 'Manger, James H'; [email protected] Subject: Re: [jose] AESWrap vs ECB key wrap > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Manger, James H > Sent: Thursday, August 02, 2012 12:17 AM > To: [email protected] > Subject: [jose] AESWrap vs ECB key wrap > > 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 > > 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. > > 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
