I got curious to know when the encryption/decryption task actual starts, to get a better understanding of the inner workings of luks. I started wondering this when using detached headers, I tried (intentionally) using a wrong header, to decrypt a disk. When running luksOpen, it was successful, but when running mount on the /dev/mapper path it failed with an error about a possibly bad fs, or suberblock. When using the correct header, it was successful. I saw that when running luksFormat, using the path directly pointing to the header file it was saying it will overwrite that file and wants to know if that ok (by typing uppercase yes), instead of saying it'll overwrite the drive itself.

So why is it that luksOpen will be successful when its wrong header for a luks device, though correct password? Does luksOpen only perform the decryption of the header, placing encryption key in ram, and the mount command will only be successful if correct master key to decrypt it?

Thank you


The reason why you can successfully open a LUKS volume with a wrong detached header is probably that your passphrase does not decrypt the actual data on the volume, it only decrypts the master key which is contained in the header, which is in turn used to decrypt the volume. The master key is 256 bit long in LUKS1, much stronger than the average passphrase a human can memorize.

So when you do a luksOpen, it actually only checks if the passphrase is correct (or exists in one of the keyslots), then uses it to decrypt the master key. The actual data volume is, as far as I understand, just encrypted in "plain" mode with the master key as passphrase. That means it does not "know" if the key used to decrypt it is correct or not.

That's also why it is usually sufficient to overwrite the header part to destroy a LUKS-encrypted volume, since it is next to impossible to brute-force it with a 256 bit passphrase.

You probably found it already, but here is some valuable information about how LUKS works.


I wondered this myself too, if replacement of the header would accomplish what I believe you were testing, and found that it helped to thoroughly understand the process by which the unlocking or decryption method happens that helped me gain the necessary clarity that you might be seeking. An article by Darell Tan explains in a more generalized sense fairly well:

  1. The user-provided password goes through the standard Password-Based Key Derivation Function 2 (PBKDF2), with the parameters specified in the LUKS header.
  2. This forms a key, which is then used to decrypt (using the specified block cipher and mode) the encrypted master key (MK) that is stored in anti-forensics (AF) stripes. The AF stripes cause the key to be stored across a large amount of disk space, such that the erasure of a single stripe renders the key unrecoverable.
  3. Once the master key (MK) is decrypted, it can be used to decrypt the data stored in the volume.
  4. LUKS provides a means for verifying the master key by having stored the MK digest. This digest is also computed using PBKDF2, but using a different set of parameters. By comparing the computed MK digest against the one stored in the header, the correctness of the MK (and hence the user password) can be verified.

This explanation more or less generalizes the entire process and is based on TKS1, an anti-forensic, two level, and iterated key setup scheme, while LUKS is actually an implementation of TKS2, a variant of TKS1, but it's still considered a proof of concept and helps understand the basic ciphering method applied, which helps breaks down the LUKS1 specifications more easily, if you ever get around to reading it, but if not, then here's a simplified answering attempt for you:

So why is it that luksOpen will be successful when its wrong header for a luks device, though correct password?

Let's first clarify that the "success" of luksOpen merely translates into it accepting the passphrase entered by the user for that particular header, but since the wrong header is on the drive, then it won't be successful (WILL NOT) in giving you access to the data that is protected by the LUKS encryption.

This is because the data on the volume of the LUKS device is encrypted by the master key and the master key is NOT derived from the LUKS passphrase. This is where Darell Tan's explanation in number 2 might be misinterpreted when misread as he mentions how "this forms a key to decrypt the master key" but it's well-noted that the passphrase itself is not the master key and it is not used in deriving the master key. (Section 1.2 Warnings Paragraph 11, Cryptsetup FAQs)

To be sure, I am NOT using "passphrase" and "master key" (or "keyphrase") interchangeably. I will, however, use "passphrase" and "password" interchangeably.

So when you say luksOpen was successful, it just means you entered the right password for the header. That's why it will work with the... well, the "correct" password.

Does luksOpen only perform the decryption of the header, placing encryption key in ram, and the mount command will only be successful if correct master key to decrypt it?

The simple and generalized answer, is yes, and aside from minor semantics, the conceptualization is correct.

In its layout, a LUKS partition starts with the header and is followed by 8 slots of "key material" which is associated with the 8 available "key" slots or otherwise represents the 8 possible passphrases that can be used and, after the "key material" is where you will find the bulk of data which is encrypted by the master key.

Most people only use one "key slot" which translates to one passphrase being used. But for each "key slot" that is active, which means each slot filled with a given passphrase, will store an encrypted copy of the master key in its key material section. And that encrypted copy, is locked by the user password. When you provide the correct password, it unlocks the decryption for the key material, which stores the master key. The master key in turn unlocks the bulk data. For a key slot, all parameters how to decrypt its key material with a given user password are stored in the header (i.e. the password's salt, iteration depth).

Explore A tour of LUKS: Linux Unified Key Setup

LUKS Operations

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.