If you create a new LUKS device, you can specify the option -hash and -iter-time.

For example like this:

 sudo cryptsetup luksFormat --cipher aes-cbc-essiv:sha256 --key-size 256 --iter-time 2100 --hash sha512 /dev/loop0

From the manpage of cryptsetup:

--hash, -h

For create action specifies hash to use for password hashing.

For luksFormat action specifies hash used in LUKS key setup scheme and volume key digest.

Because of the first sentence I naively assumed that the hash is used in a similar way as in a standard linux system, where a hash value is created by a specified algorithm (for example sha512). To make it harder for an attacker which has the hash and wants to try a dictionary attack, the has is salted and the algorithm is iterated n-times to make computation time longer. In this case the has value is stored in /etc/shadow. If a user logs in, the hash is computed and compared to the value in the /etc/shadows file. If they are equal, the user is accepted to login. In a similar way an attacker which owns the file /etc/shadow (from where he also knows the salt value) can compute hashes from words in a dictionary and compare it to the value in the /etc/shadow file until some string matches.

If the hash in LUKS were used in a similar way, I assumed it must be stored somewhere (for example in the partition header) and if the attacker had access to the partition header (or the file where it is stored) for some reasons, he could proceed in a similar way as above to find out the password. This lead me to the question about how to get the hash: How can I extract the hash value of a LUKS device?

Thinking about how the LUKS system may work, I guess that it is not used in this way. Instead I think, that the password is just used to encrypt the key (and no hash is stored anywhere), which is stored encrypted in the header. But in the LUKS man-page I didn't find any hint, which encryption algorithm is used for key encryption and how to change it. (The options --cipher aes-cbc-essiv:sha256 --key-size 256 refer to the actual algorithm which is used to encrypt the partition but not the key). This indicates for me that this understanding my be also incorrect.

So, how does this all really works and what is the role of the hash described above? Would be great if someone could clarify my misconceptions above (perhaps with some references).

2 Answers 2


The LUKS format has multiple key slots, each one may contain the encrypted master key that is used for data encryption. This master key is encrypted using another key which is derived from your passphrase.

Using plain hash_function(passphrase) to generate a key would be dumb as hashes such as sha1 can be calculated fast (SHA-1 is an example of a MAC algorithm, for authentication of a message, not to be used as plain for a password).

For data encryption based on a passphrase, you want the function to be slow to thwart brute-force attacks. For this purpose, PBKDF2 (password-based key derivation function) is used (see the excellent answers on this Sec.SE question for motivations and other examples).

derivedKey = PBKDF2(hash_function, passphrase, salt, iterations, derivedKeyLen)

The hash_function for my installation is sha1 as is shown in cryptsetup --help:

Default compiled-in key and passphrase parameters:
        Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF2 iteration time for LUKS: 1000 (ms)

Default compiled-in device cipher parameters:
        loop-AES: aes, Key 256 bits
        plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
        LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha1, RNG: /dev/urandom

The derived key length depends on the cipher used for data encryption. The number of iterations depends on your processor speed.

These details can be found in the manual page of cryptsetup (pbkdf2 should ring a bell). For other security details, see the FAQ of cryptsetup.

  • 1
    True, but this doesn't really explain what's going on. PBKDF2 is a slow hash instead of a fast hash, so what? Commented Nov 16, 2013 at 21:30
  • @Gilles I have clarified why PBKDF2 does and how the result is used. Basically, sha1 is fast, useful for quickly verifying the authenticity of a message. The master key needs to be encrypted well. The passphrase itself is not safe enough as key because it can be brute-forced "fast". By slowing down the key function to ± 1 second, it is still practical for use while it makes bruteforce much harder.
    – Lekensteyn
    Commented Nov 16, 2013 at 23:42
  • All of this applies equally to password hashes. In fact, password hashes and password-based key derivation are basically the same problem, cryptographically speaking. However, for authentication, the system stores the hash, whereas for encryption, the system doesn't store the hash; you don't explain that part, and it's what this question is about. Commented Nov 18, 2013 at 0:14
  • By the way, SHA-1 is not a MAC, it's a cryptographic hash (but not a slow cryptographic hash, which makes it unsuitable as a password hash). A hash such as SHA-1 can be used to verify integrity, not for authentication. A hash can be a building block of a MAC in the HMAC construction, for example HMAC-SHA-1 is a MAC. Commented Nov 18, 2013 at 0:15

You're right, storing credentials for encryption and storing credentials for authentication are two different problems.

When a user logs in, the operating system needs to have a reference copy of his password to compare against the password that the user enters. If the entered password is identical to the reference password, the authentication succeeds. To make password recovery difficult, the system doesn't store the password but a hash of it (a slow, salted hash to make brute force attempts to guess the password more difficult).

Encryption works differently. The aim is to protect against an attacker who has access to the storage, so it must not be possible to extract the encryption key from what is stored on the device alone. Hence the key is not stored on the device, but constructed from information stored on the device combined with information supplied by the user. Typically, the key is generated from a salt stored on the device combined with a password supplied by the user. Again, to slow down brute force attempts, the process to combine those values must be slow, and the process uses a per-device value (the salt) in addition to the user's password so that the use of the same password doesn't lead to the same key.

It turns out that cryptographically speaking, a slow password hash and a slow key derivation function are the same problem, known as key stretching. LUKS uses PBKDF2, one of the de facto standard key stretching functions (though technological progress in password cracking makes bcrypt or scrypt preferable). Modern unix systems use a similar mechanism for password hashing (“MD5” or “SHA-512” are actually iterated, similar in construction to PBKDF2)

If the user supplies an incorrect password, then the decryption of the data returns garbage.

Like most other encryption mechanisms, LUKS doesn't use the key derived from the password as the encryption key for the data. Instead, the data encryption key is generated randomly when the device is created, but not stored directly. LUKS stores copies of this key encrypted with each of the password-derived keys. In LUKS terminology, each password-derived key occupies a slot in the volume header; each slot corresponds to one password. You can read the TKS1 paper for the details of the two-layer encryption scheme.

  • Despite the considerable clarification of your answer, I believe the original question in the OP still stands, if translated in these terms: where are the (one or more) copies of the encrypted master key stored? The TKS1 paper is quite clear that the encrypted master key is retrieved from the key storage, then decrypted by means of the encryption key obtained via PBKDF2, and states several times it is located on the disk (besides, where else could it be)? I also presume it is hidden, but do you happen to know how and where? Commented Apr 11, 2016 at 16:30
  • @MariusMatutiae I'm sorry, I don't understand what you think is missing. As I explain, no copy of the master key is stored in plaintext. Copies of the master key are stored in each slot, each encrypted with the key derived from the corresponding password using PBKDF2. The slots are part the LUKS header at the beginning of the partition, at the place where you'd expect to find metadata, they aren't “hidden” in anyway. Commented Apr 11, 2016 at 17:32
  • This is what I wanted to know, thanks: where the slots are. Commented Apr 11, 2016 at 18:12

You must log in to answer this question.

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