# LUKS multiple key slots - what's the intuition?

The intuition behind basic encryption with a single key is pretty straightforward.

ciphertext = BIG_FUNCTION(plaintext, key)
plaintext = BIG_FUNCTION^(-1)(ciphertext, key)

Can anyone explain how a LUKS volume can permit independently usable passwords? I'm just looking for the intuition - not necessarily a detailed explanation of how LUKS in particular handles this.

Roughly your password is used to encrypt a MasterSecretKey. Then you use this MasterSecretKey with a symmetric algorithm to encrypt or decrypt your data (the disk sectors). They eight key slots in LUKS are eight different encryptions of the same MasterSecretKey under eight different passwords.

Actually LUKS does not encrypt the MasterSecretKey with a password but with a key, generated with a PBKDF.

A similar approach is used by GPG when you send a message to a set of distinct recipients.

This is usally know as KEM/DEM paradigm: Key Encapsulation Method/Data Encapsulation Method and it is the standard method when you use public key to encrypt something.

• Thank you, that's very clear. Does that have any negative impact on security, other than the obvious practical one that a brute-force attacker is up to (say) 8x more likely to guess a valid password? Feb 19, 2015 at 20:15
• Nope. Under the hypothesis that the encryption scheme used to encrypt the MasterSecretKey is secure. A standard encryption scheme does not leak any information about the plaintext if it is encrypted under multiple and different keys. Feb 19, 2015 at 20:18
• Actually in general some related keys attacks exists but it is very unlikely for this context. Feb 20, 2015 at 7:15
• Anything you could point me toward, out of curiosity? Feb 20, 2015 at 13:35
• @SauceCode How about wikipedia: related-key attacks and related-key attacks on AES.
– tylo
Aug 4, 2015 at 11:06

There's an important point to understand in the design of Luks thats rarely mentioned: the master key remains constant throughout the life of the encrypted partition, because all the blocks of the partition have already been encrypted using it. Changing the master key would require updating every block of the partition, which could take hours (and must not be interrupted).

Hence their decision to encrypt the master key using another key (the key-encryption-key) and store the encrypted master key in the header of the same partition. The key-encryption-key is never stored on disk - its derived from the passphrase.

Once this design is understood, the caveats explained in the FAQ will make sense:

• You cannot recover data if your partition header is damaged. Possessing the passphrase (and thus the key-encryption-key) is useless since the encrypted master key is missing.
• Changing your passphrase does not stop an attacker who knows your old passphrase and has a copy of your old header. He can simply write the old header on top of the new one, enter the old passphrase, and open the partition.
• If a previous admin was granted a key slot, and a later admin deletes that key slot to secure the system, in reality its not as secure as he thinks it is.

The only secure solution in these scenarios is to use cryptsetup-reencrypt to change the master key and update all blocks on the partition.