Subject: [jose] AESWrap vs ECB key wrap

From: "Manger, James H" <[email-masked]>
Date: Thu, 2 Aug 2012 17:16:30 +1000

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

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 2 Aug 2012 17:23:58 +1000

> ...[JOSE] still need to define how to
> use AESWrap for content keys that are not a multiple of 64-bits.

I just noticed that this has already been done:
RFC 5649 AES Key Wrap with Padding Algorithm

So we just need to reference this spec in JWA.

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 7 Aug 2012 12:02:46 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Manger, James H
> Sent: Thursday, August 02, 2012 12:17 AM
> To: [email-masked]
> 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].
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 8 Aug 2012 19:10:42 +0000

> 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-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Tuesday, August 07, 2012 12:03 PM
To: 'Manger, James H'; [email-masked]
Subject: Re: [jose] AESWrap vs ECB key wrap

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Manger, James H
an
> 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.
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?
> 
key
tag for

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 9 Aug 2012 12:01:35 +1000

> 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

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 9 Aug 2012 13:07:25 -0700

> From: Manger, James H [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2012 7:02 PM
> To: Jim Schaad; [email-masked]
> 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].
> > >
> > > 64-bit integrity check (from the overhead) 4. Performs 12 AES
> > > operations for each 64-bits of the content key
> 
> > 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.
> 
> 
> > > overhead by dropping the integrity check and only use 1/24th of the
> > > AES operations.
> > of key material.  This means that it would not be usable for many
> > algorithms that are in the current specification.
> 
> 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 dealing 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