> -----Original Message----- > From: Manger, James H [mailto:[email protected]] > Sent: Wednesday, August 08, 2012 7:02 PM > To: Jim Schaad; [email protected] > Subject: RE: [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 > > 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).
The design of AESWrap with a 64-bit integrity value and 64-bit multiple key sizes was a byproduct of the inputs we had at the time. That is why there is a newer version that allows for both having keys which are of a different size. The role of the integrity value has nothing to do with the size, it has everything to do with being able to both deeply protect the key and to know that one is using the wrong key (or it has been tampered with) before getting so far in the process that one needs to rewind and start from scratch to process the input. You already have integrity built into the normal RSA key transport methods. There is no such ability to know that you have the correct pairs for the key agreement world or for the symmetric key world. The additional of the integrity check here is therefore good in determining that your problem is with the key pairs and not with the content. Given that SKI can be a user defined value for the X.509 certificate world, and all users can start with the number 1 and increment. You can have a large number of SKI values that are the same if you are doing static static. The problem can even be true for identifying your own key pairs at times. I will just skip dealin g with how symmetric keys are defined since there is no standard method across all protocols for doing so. Indeed in the jose case the key is going to be implicitly defined in most cases. There are timing attacks that can be made either with or without the integrity value so there is no real advantage from that basis. Jim > > -- > James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
