I have read many articles about Key wrapping and tweakable cipher modes. However, I don't understand the main difference between them? What you recommend for Key storage and Key Archive.


Key wrapping and tweakable encryption are actually quite different topics. Key wrapping is more commonly related to keys forage and key archive.

Key wrapping

This is fancy terminology for encryption key with another key. In key wrapping you have a master key that is used to protect one or more keys. It is generally impossible for (computationally constrained adversary) to decrypt wrapped key with no access to appropriate decryption key.

There are key wrapping mechanisms used with asymmetric cryptography, i.e. encryption and decryption with different key (such as RSA-OAEP), and symmetric cryptography, such as AES-KW. Many key wrapping algorithms provide some level of integrity/authenticity protection in addition to encryption.

For purposes of key storage and key archive, key wrapping is very often used.

Key derivation

(As introduction towards tweakable encryption). Key derivation is kind of counterpart of key wrapping. The master key is not used to protect wrapped key, but instead a key derivation algorithm is used to produce other keys from master key. The algorithm may, for instance, generate the keys based on purpose (as identified by "Label") and possibly, other fields related to context. Key derivation can be useful when many keys are needed, but it is not desirable to store all the keys, but only store the master key. (Thus, for key storage, this algorithm is not ideal.)

Tweakable encryption

In some fields, most notably Full Disk Encryption, it is would be desirable to use very large number of cryptographic keys, for instance, to use different cryptographic key per each sector. Conceptually, this is very close to using key derivation to derive per sector keys. Unlike key wrapping, in tweakable encryption the per sector keys are not (usually) stored anywhere.

The tweakable encryption algorithms have been usually implemented with optimization goal that it is very lightweight to change one parameter (tweak). For purpose of key storage and key archive, in many cases, current tweakable encryption algorithms are of little use. Tweakable encryption (for instance XTS-AES), is mainly intended to protect (lower value) bulk data, in situations where data size extension to allow for integrity/authenticity checking is not an option.

  • $\begingroup$ It is very helpful for me.I understand that if I want to store one key secure I must use Key Wrapping modes(for example SIV), but when I want to archive all keys I can use tweakable algorithm, like a XTS-AES. $\endgroup$ – Gev_sedrakyan Mar 6 '14 at 6:25
  • $\begingroup$ "keys forage and key archive" $\: \mapsto \:$ "key storage and key archives" $\;\;$ ? $\;\;\;\;\;$ $\endgroup$ – user991 Mar 6 '14 at 10:23

Key wrapping

Key wrapping is used to... wrap keys :) One example: Suppose you want to encrypt a byte array with a public key algorithm like RSA. Since RSA is slow you would rather choose a random key for a symmetric block algorithm like AES, then encrypt the byte array with AES and just encrypt the AES key with RSA.

Now the question is, how to encrypt the AES key with RSA. The trivial approach is to just convert the AES key into a number (for example by the PKCS#1 standard) and then encrpyt this number with the RSA public key. This has some disadvantages. The biggest disadvantage is, that you have to pad the key, since an AES key is at most 256 bits long while the RSA plain text room is like 1024 bits and above. But padding algorithms are often the source for weaknesses. It is just hard to prove that a specific padding scheme is safe (or at least seems to be safe).

A much smarter way to encrypt the AES key is the following:

  • Let $(n,e)$ be your public RSA key and $(n,d)$ your private RSA key.
  • Choose a random number $x$ with $2 < x < n-1$.
  • Encrypt the random number with $x' = x^e \mod n$ (now $x'$ is what you attach to your encrypted message).
  • Choose a key derivation algorithm (like PBKDF2) and generate a 256-bit hash of your random number $x$ with $k = hash(x)$.
  • Encrypt your byte array with $k$.

To decrypt your message just:

  • Unencrypt $x$ with $x = x'^d \mod n$.
  • Derive the AES key $k$ from $x$ with $k = hash(x)$.
  • Decrpyt your byte array with $k$.

This is an example for a key wrapping algorithm. It's not designed to encrypt predefined large byte arrays. It's designed to encrypt short data. In this particular example it just creates and then wrappes a random byte array.

Tweakable encryption

Tweakable encrpytion is a mode for symmetric block ciphers. For example CBC mode encrypts the first block with your key (and some initial vector). The key to encrypt the second block then depends on your first block and so on. For tweakable encryption you almost use the same key for every block. The only difference is, that you incorporate for example the block number in the key.

This way again every block has its own key, but with tweakable encryption you can parallize the encryption, since the key for block number $n$ does not depend on block number $n-1$.

  • 1
    $\begingroup$ I think you should make the Tweakable section clearer: CBC mode doesn't change the key each block $\endgroup$ – Cryptographeur Mar 5 '14 at 17:50
  • $\begingroup$ Well your right (de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode)... The key itself is not changed, but the plain text block is XORed with the previous cipher text block. Still the point holds: One cannot en- or decrypt a block without knowing the previous block. Tweakable encryption does not have this restriction, since every block is encrypted one its own, but the key is changed (for example by incorporating the block number in the key). $\endgroup$ – Thekwasti Mar 6 '14 at 9:19
  • $\begingroup$ Indeed, but the implication that the key changes (and that therefore the key schedule would need to be rerun) is unclear. $\endgroup$ – Cryptographeur Mar 6 '14 at 9:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.