I'm looking at JSON Web Encryption (JWE) and am left a bit confused about why you would use AES key wrapping.

The document even talks about using matching key algorithm strengths:

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.

Essentially I'm wondering why you would use AES key wrap at all.


So for an example comparison, using the A256GCM encryption algorithm I need a 256-bit key. Just to be easy my key will be "secret0123456789secret0123456789" and I'm encoding "Test".


Using direct (DIR) key algorithm (so using my key as the content key), I get:


This breaks down as:

         JWE Header:  {"alg":"dir","enc":"A256GCM"}
Encrypted key (CEK):  (blank)
                 IV:  Vlf_WdLm-spHbfJe
         Ciphertext:  RxMPrw
 Authentication Tag:  5VC8Y_qSPdSubbGNGyfn6A


Matching the key wrap algorithm with the encryption algorithm, I'll use a AES 256 bit key, which yields:


This breaks down as:

         JWE Header:  {"alg":"A256KW","enc":"A256GCM"}                         
Encrypted key (CEK):  66xZoxFI18zfvLMO6WU1zzqqX1tT8xu_qZzMQyPcfVuajPNkOJUXQA   
                 IV:  X5ZL8yaOektXmfny                                         
         Ciphertext:  brz-Lg                                                   
 Authentication Tag:  xG-EvM-9hrw0XRiuRW7HrA                                   

As I understand it, the content key is encrypted using JSON Web Key (JWK), but essentially what this is doing is:

  • creating a random 256 bit content encryption key (CEK)
  • encrypting the actual data with this CEK (and a random IV)
  • encrypting the CEK with my supplied key

The encrypted CEK, IV, and encrypted data are all part of the resultant JWE object (all base64url encoded).

Direct JWE results in a smaller payload to be sent over-the-wire, and I would presume it's slightly faster to both encrypt and decrypt because it's skipping a step.

Does using AES key wrap yield higher security, and if so, why? If not, why would you use it instead of just direct content encryption?

  • I'm not too up on JSON stuff, but does the key get transmitted in the DIR case? If so that would mean that it's transmitted in the clear. The AES key wrap encrypts the key so that only you can decrypt it. And therefore are the only one to decrypt the JSON blob.
    – RoraΖ
    Commented Feb 5, 2015 at 20:26
  • Nope, the DIR key is never transmitted. With either DIR or A256KW, you are required to have a secret shared key on both ends. With DIR it's used to encrypt the contents; with A256KW (and the other keywrap methods) it's used to encrypt a key which in turn encrypts the contents, and the encrypted key IS included in the message (it's the "66xZ...UXQA" value in my example). This is essentially my question: what's the point of symmetrically encrypting a key that symmetrically encrypts the contents, instead of just symmetrically encrypting the contents?
    – gregmac
    Commented Feb 6, 2015 at 2:54
  • Interesting anecdote: just came across github.com/square/js-jose/blob/master/README.md that says "A128KW/A256KW: (supported, but not recommended for use)", though does not say why
    – gregmac
    Commented Feb 7, 2015 at 20:27
  • I had the same question but this time about PBES2-HSXXX+AXXXKW. It does the same thing by using passing a passphrase in PBKDF2 before encrypting a randomly generated CEK to eventually encrypt the final plaintext content. It seemed unnecessary to have that extra randomly generated CEK, why not just use the PBKDF2's generated seed as the actual CEK itself. I guess the only benefit is the ability to rotate the passphrase without changing the CEK and re-encrypting the plaintext. Commented Sep 16, 2022 at 1:21

4 Answers 4


If you need to store a large amount of data, the advantage of wrapping the key within an encryption layer means that if you needed to change the key at a later time then you would not have to reencrypt all your data. You simply change the KEK (Key Encrypting Key) and reencrypt the CEK without having to transfer all the ciphertext again.

For example, say you were using JSON in order to transmit data to your server for safe storage. You could transmit all this data using A256KW and your server at the other end simply stores this.

That is, the following is transferred and then stored server-side:

Encrypted key (CEK):  66xZoxFI18zfvLMO6WU1zzqqX1tT8xu_qZzMQyPcfVuajPNkOJUXQA   
                 IV:  X5ZL8yaOektXmfny                                         
         Ciphertext:  brz-Lg                                                   
 Authentication Tag:  xG-EvM-9hrw0XRiuRW7HrA       

If you needed to change the key you could simply pull the CEK to the client, decrypt with the old KEK and encrypt the CEK with the new key and then send it back to the server to update all relevant records.

For short-term transmission purposes only, this is not important and it would be easier to use Direct for a smaller payload.

  • Makes sense in general, but I've not seen a JWT library that could change the CEK (at least not without decrypting the entire thing anyway and defeating the speed benefit). The primary use case for JWT seems to be over-the-wire transmission, so it still seems a bit strange that so much effort was put into designing and documenting key wrapping (not to mention implementing it in all the libraries) if the only (fairly minor, IMHO) benefit is something not actually realized by ANY of the libraries.
    – gregmac
    Commented Feb 6, 2015 at 20:12

KW allows you to establish a long term secret but still use a different CEK for each message, this is important for some use cases, but not all.

In the case of using JWE to send a single message to multiple recipients who all have different long term keys, this is essential as you need to wrap the CEK multiple times once for each recipient.

JWE supports a number of advanced use cases, but the common use is to encrypt JWT between two parties using direct.

When we were developing JWE some people wanted to only support the KW option and drop the direct optimization. At the end of the day we wound up with two options depending on the use case. Direct creates smaller tokens and is easier to implement. If you don't need KW then don't sweat it.

  • The use case of same message / multiple recipients is where KW shines. You can use the same CEK & ciphertext for everyone, instead of having to encrypt everything separately for each recipient & cause a large amount of bloat.
    – AFOC
    Commented Feb 2 at 0:46

There is a reason for using AES key wrapping. Once you have encrypted something the key is the weak part. All attempts to get at the data require knowing the key. Since the key and encrypt/decrypt software isn't encrypted an attacker could steal your key and use it. That is the point of key wrapping, it helps protect your key.

  • 5
    How? There is still a shared secret key, but now it's being used to encrypt another key (the content encryption key (CEK)), instead of the content directly. If the shared secret key itself is compromised, it can be used to decrypt the CEK which in turn decrypts the content. Protecting your secret/private keys within the software is an entirely different concern.
    – gregmac
    Commented Feb 6, 2015 at 3:55

The use of key wrapping is to create a one time session key that is generate a random seed and encrpt the public key that is used to encrypt the content of the message that the other hand will decrypt by unwrapping the public key with the session key and use his private key to decrypt the message.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .