Key Wrap constructions are a class of symmetric encryption algorithms designed to encapsulate (encrypt) cryptographic key material. The Key Wrap algorithms are intended for applications such as (a) protecting keys while in untrusted storage, or (b) transmitting keys over untrusted communications networks. The constructions are typically built from standard primitives such as block ciphers and cryptographic hash functions.

What are the advantages of using AES Key wrapping instead of ordinary AES, for example CCM mode (Counter with CBC-MAC)? What are the pros and cons?

Could someone point me to good readings/papers about AES Key wrapping, other than my primary resource, NIST Key wrapping specification?

Or, could someone shortly explain how it works?

  • I think key-wrapping algorithms are usually secure when used without a unique IV whereas many normal modes, whereas CCM totally breaks when you reuse a nonce. Aug 5, 2013 at 7:16
  • This might be better for crypto than security Aug 5, 2013 at 10:28

1 Answer 1


The key wrap algorithm can be envisioned as an extended Feistel scheme which uses AES as the round function, combined with a running state which serves as a rough MAC. If you look at the algorithm definition, you will see that for each of the s rounds, one 64-bit block of data is updated, with a combination function which includes an AES invocation and another 64-bit block. The blocks are also "rotated" so that the next round updates another block, and so on. This really is akin to defining a big block cipher operating over the complete plaintext as a single "block".

As symmetric encryption systems go, this one is quite inefficient, because it involves an average of 1.5 AES invocation per input byte (12 AES invocation for a 64-bit block), whereas GCM would use only 0.0625 AES invocation per input byte (one AES every 128-bit block). It also needs to process each input byte several times, so the entire plaintext message must be fully buffered: this will be inadequate for bulk encryption.

The key wrap algorithm was designed to protect keys and suffers from some ritualistic overkill: a lot of accumulated AES invocations on the hope that it will make so much scrambling that the result will be strong. This is not a bad bet; if we look at it as an extended Feistel cipher, then there is some empirical data that many rounds will bring security. This should deserve some decent analysis, though, and, to my knowledge, this has not occurred yet. This is probably related to the fact that this key wrap algorithm appears not to be much used in the wild.

Good properties of the AES key wrap algorithm include the following:

  • It does not need randomness. Randomness is a scarce resource on many embedded systems, so having a scheme which is secure without it is nice.

  • It does not need state. No EEPROM or Flash bit to modify, if only to keep a counter.

  • It is deterministic. This means that wrapping the same plaintext with the same key will yield the same sequence of bytes. Determinism is mostly neutral, but occasionally useful in some protocols.

  • It uses a single primitive, which is "the AES": code size is also a scarce resource on embedded systems.

  • It has low size overhead: it adds only 64 bits to the input size, and includes a MAC, so that's about the smallest than can be achieved.

Bad properties are mostly these ones:

  • The algorithm is inefficient, with a high CPU cost per byte, and the need for full buffering. This is why the algorithm is meant for key wrapping, where "keys" are short entities, keeping the wrapping costs under reasonable limits.

  • Despite its 12 years, the AES key wrapping algorithm did not benefit from a lot of analysis or even attention from the cryptographic community, probably because of its restrictive use cases.

  • "This is probably related to the fact that this key wrap algorithm appears not to be much used in the wild." it is used on iOS devices to protect the keys which are used to encrypt the file content. If you are interested take a look at this whitepaper iOS Security especially the "Data Protection" section of the paper.
    – enigma
    Aug 5, 2013 at 14:12
  • Tom, I wouldn't label the properties "good" or "bad". Efficiency is just one of many qualities, all of which must be weighed together. Most important would be security, of course, followed closely by integrity. Size obviously would matter greatly on an embedded device, but would mean nothing on a server. In the highly specialized use case of key wrapping for export, I would argue that efficiency is one of the least important qualities, especially as it would likely be used only infrequently. Aug 5, 2013 at 14:25
  • AES-KW is used with encrypted filesystems, such as LUKS and TrueCrypt. The file system AES is key wrapped with a key created from the user supplied passphrase. The user can change their pass phrase at any time, and the file system key is just rewrapped. Thus, there is no need to re-encrypt the entire file system on pass phrase change. It wouldn't surprise me to learn that iOS and Android deploy it with the PIN or pattern as well. Apr 11, 2016 at 1:13
  • 1
    @Aaron Toponce, this is not correct. LUKS (at least the version found in 1.6.6 of cryptutils) does not use AES-KW. LUKS is one of those applications where the original input can be a user-supplied password. The password passes through a PBKDF2 transform to form a wrapping key. The wrapping key is used to decrypt the volume key. A separate PBKDF2 transform of the volume key is also calculated and acts as a checksum, i.e. it provides a mechanism to check if the user provided the correct password. The number of iterations of these two PBKDF2 functions can be configured separately. I believe PBKDF
    – D. Glynos
    Jun 9, 2017 at 8:48

You must log in to answer this question.

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