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 <[email protected]>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, [email protected] > > *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 <[email protected]>wrote: > >> Think in terms of encrypting a JWK directly not an intermediate key. >> >> > -----Original Message----- >> > From: [email protected] [mailto:[email protected]] On Behalf Of >> > Manger, James H >> > Sent: Monday, March 18, 2013 5:17 PM >> > To: [email protected]; [email protected] >> > 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: [email protected] [mailto:[email protected]] 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 >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/jose >> >> >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
