You can, but it breaks security, because the cloned container has the same header and hence the same master key. You cannot change the master key on a LUKS container, even if you change the passphrase(s), the master key stays the same. That means whoever has access to one of the clones can decrypt them all, completely bypassing the passphrases.

If we set a new secret user key, the encrypted master key stored on disk changes but the master key does not. Hence, users can change password frequently without re-encrypting all the data.

My questions:

1. If we can have up to 8 slots for decryption does that mean we have 8 corresponding Master Keys split in anti-forensic stripes or is it still ONE MK ?
2. If it is ONE MK how the passphrase from slot 2 decrypt it when it is already encrypted with the passphrase from slot 1 (yes I know it is not the passphrase itself, but I keep it like that for simplicity).

3. Regarding the second quotation. So per my understanding while changing the LUKS passphrase we first provide the current passphrase, we then provide a new one and that changes the encrypted representation of the MK but after decryption it is still the same that was randomly generated during first initialization, correct?

4. Then regarding the first quotation. I simply don't get it, at least notthe last sentence

That means whoever has access to one of the clones can decrypt them all, completely bypassing the passphrases

Does that mean that if a have server A with LUKS encryption protected by a high-entrophy passphrase and clone that drive I would be able to decrypt that drive without even knowing or having to provide that passphrase ? If yes how would I do that ? Dump the MK from memory on server A, or how ?

• Whoever had access to the volume and a working passphrase could have extracted and saved the DEK Extracted exactly from where ? Once decrypted where is the key stored ? RAM ? – blabla_trace May 26 '19 at 18:48