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

[Richard Barnes <[e-mail]>]

I agree that it's a fair question to ask.  As I'm writing this key wrapping
document (as requested in Orlando), I'm trying to develop a comparison of
the costs of various wrapping schemes.

It would be interesting to get feedback on the group as to how you would
measure cost in this case?  For example:
-- Which algorithms can/cannot be supported
-- How large the encrypted object is
-- How many encryption formats a JOSE library has to support

On the latter point, the request to use GCM for key wrapping has gotten me
thinking that perhaps we should just make JWE self-similar, by using a JWE
to wrap the key for a JWE*.  That would reduce the number of encryption
code paths from two (JWE, key wrapping) to one (JWE).  Again, I'll try to
make a concrete proposal in the forthcoming document.

--Richard




On Mon, Mar 18, 2013 at 11:23 PM, Mike Jones <[e-mail]>wrote:

>  Since you message appears to take it as given that “there should be only
> one way of encrypting keys”, I’ll point out that I don’t think that it’s
> reasonable to assume that.  JOSE is first and foremost an engineering
> exercise, where the cost/benefit generality/complexity tradeoffs matter,
> and the goal is a ubiquitously implemented crypto format for the Web that
> solves the problems that people actually have, rather than a mathematical
> exercise, where the goal is completeness and generality.  Complexity is the
> enemy of adoption.
>
> So it’s fair game to ask “What are the costs and benefits of having only
> one way to encrypt keys”, versus taking that as a given.
>
> I happen to personally believe that encrypting a bare symmetric
> ephemeral Content Master Key is sufficiently different than encrypting a
> key that may be public, private, or symmetric and may have additional
> attributes, that it’s at least worth asking the engineering question
> whether special-casing the encryption of this bare symmetric ephemeral key
> results in engineering benefits.
>
> Encrypting a key with attributes for storage or dissemination is not the
> same kind of operation as wrapping an ephemeral symmetric key to be used
> for block encryption.  I’m personally fine with this being done
> differently.  The engineering benefit if we do it differently in the way
> that Matt’s draft proposed, at least as I see it, is that we have to invent
> nothing new.  We already have a great format for encrypting arbitrary data,
> and keys with attributes are a whole lot like arbitrary data.
>
> I respect that some with disagree with my personal view, but I’d also ask
> you to respect that the engineering tradeoffs may favor having two ways to
> do things that on the surface may seem similar, but are actually fairly
> different in nature.
>
> Best wishes,
> -- Mike
>
>  *From:* Richard Barnes
> *Sent:* March 18, 2013 7:36 PM
> *To:* Jim Schaad
> *CC:* Manger, James H, [e-mail]
>
> *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP allows
>
> Well, I got to 788 by doing math incorrectly*.
>
>  Mike was correct on the other thread that 768 is the right number.
>  However, that's still too big for a 1024-bit RSA key and SHA1, since 768 +
> 320 = 1088 > 1024.
>
>  Regardless, there is clearly an issue here when wrapping a JWK, which is
> much larger, possibly containing an RSA key itself.  So if we accept the
> goal that there should be one way of encrypting keys, then we'll need to
> deal with getting around the OAEP size limitations.
>
>  --Richard
>
> * This is why my degree is in mathematics, and not accounting.
>
>
> On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <[e-mail]>wrote:
>
>> Think in terms of encrypting a JWK directly not an intermediate key.
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>  > Manger, James H
>> > Sent: Monday, March 18, 2013 5:17 PM
>> > To: [e-mail]; [e-mail]
>> > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows
>> >
>> > 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>
>>  > _______________________________________________
>> > jose mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/jose
>>
>>
>