There are a couple of possible reasons
1. If you are using AES-GCM for your CEK algorithm, then this allows you to not have to remember and deal with nonce re-using problems as a new CEK is generated each time that you send a message. 2. If you want to send the encrypted content to more than one person, using a KEK algorithm allows for a single CEK value to be encrypted to multiple recipients. Each of whom has a different KEK value. As with all cryptography, you need to look at the key strength of each algorithm to determine what the effective encryption strength is for the entire message. However there are reasons that a longer KEK key might be used. For example, the KEK value is going to be long term, so making sure that it is hard to crack is of importance, however any individual message is of low importance so allowing it to be cracked is not a problem. This would be especially true if what one is doing is looking for some type of authentication of the sender rather than just encryption. However, it should be noted that this is also a problem if one is matching RSA or ECDH with an AES key as it is not always clear how the impedance matching is done. While NIST has one set of guidelines that are in common use, they are not universally accepted by everyone. Jim From: jose [mailto:[email protected]] On Behalf Of Greg MacLellan Sent: Tuesday, April 07, 2015 1:36 PM To: [email protected] Subject: [jose] Is there a valid scenario for JWE with AES KeyWrap algorithms? Essentially, I am wondering what the purpose of AES/symmetric keywrap algorithms in the context of JWE is. ---- When using asymmetric encryption (RSA, EC) keywrap makes sense: 1. A random content encryption key (CEK) is created 2. Payload is encrypted (using symmetric encryption) using the CEK 3. The CEK is encrypted using the supplied key (which serves as the key encryption key (KEK)) However, when using A*KW, or A*GCMKW, I do not see the purpose of this: 1. A random CEK is created 2. Payload is encrypted (symmetricly) using CEK 3. CEK is encrypted (symmetrically) using KEK JWE RFC section 11.3 (https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40#section-11.3) even says: > Algorithms of matching strengths should be used together whenever possible. > For instance, when AES Key Wrap is used with a given key size, using the same > key size is recommended when AES GCM is also used. If the key encryption and > content encryption algorithms are different, the effective security is > determined by the weaker of the two algorithms. This highlights that there's not even a point in having eg, a 256-bit KEK and using 128-bit CEK (eg: to lower CPU usage with big payload) -- the effective security is still 128-bit. ---- So this boils down to: if I want symmetric encryption, why would I ever choose anything besides the DIR (direct) key algorithm? If there is no good answer, perhaps A*KW and A*GCMKW should be deprecated, which will later lead to simpler libraries and less variation in JWE formats in the wild. Note, I asked this question on security.stackexchange (http://security.stackexchange.com/questions/80966/what-is-the-point-of-aes-key-wrap-with-json-web-encryption) but responses there just seem to reinforce my original suspicion that symmetric KW algorithms have zero benefit to JWE/JWT.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
