Re: [jose] #14: Support longer wrapped keys than OAEP allows

["Manger, James H" <[e-mail]>]

Richard,

How do you get a 788-bit key length?

draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES-128/192/256 and SHA-1/256/384/512. The total key lengths range from 256 bits to 512 bits.

Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key.

Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key. JWA already says RSA key sizes MUST be at least 2048 bits.

This already looks sufficient.
 
--
James Manger


> From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
> Sent: Tuesday, 19 March 2013 10:25 AM
> Subject: [jose] WebCrypto feedback on key wrapping
>
> 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapped key objects, then we would need something other than OAEP in order to carry arbitrary-length payloads.  I agreed, and suggested that something like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed that KEM is troublesome due to the lack of support by native crypto libraries.
>
> Point number 2 likely applies for some scenarios of JWE, especially if we adopt the McGrew approach.  For example, if using HMAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, which is too long to be encrypted with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve it.  The best idea I've got is to allow wrapped keys to nest, so that you can wrap a key inside of another wrapped key.
>
> --Richard


>> ----------
>> Sent: Tuesday, 19 March 2013 10:23 AM
>> Subject: [jose] #14: Support longer wrapped keys than OAEP allows
>> 
>> #14: Support longer wrapped keys than OAEP allows
>> 
>>  The use of RSA-OAEP for key wrapping imposes a limit on the length of
>>  the key package being wrapped. With SHA1, this length is N-320, where
>>  N is the length of the RSA modulus.  Especially with larger hash
>>  functions, and especially for wrapping private keys, the size of key
>>  packages will be larger than this bound.  We should incorporate a
>>  mechanism to accommodate these situations.
>> 
>> 
>> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/14>