The password of previously encrypted volume got changed by the Debian installer

Question

I already did some research on my question (see below), and it's as good as a 'done deal' but I would still like to put forward my problem to this knowledgeable community.

Short version of the issue: in partman (the disk partitioner of the Debian installer) the passphrase of a previously dm-crypt/LUKS encrypted volume was changed (or added) by mistake. The data on this volume was not flagged for removal. I cancelled the installation after that point. Later after manually 'decrypting' this volume it was found that only the ‘new’ password could decrypt the volume, but data could not be read (i.e. filesystem and files were not found)...

I was wondering if after changing back to the old passphrase I would be able to properly decrypt the volume's contents.

Previous research: the above question was submitted to the debian-boot mailing list, and there I received the following (very clear) answer:[1]

I don't think the data will be recoverable unless you have a backup of the LUKS header. The way LUKS works is that data is not encrypted with a passphrase directly but with a key that is encrypted to a set of passphrases. If you worked purely through the installer's UI you will have overwritten your LUKS header and hence will be unable to decrypt the data ever again because the key material is lost. The position of the LUKS header on disk is always in the same place.

Data erase is really just about overwriting the existing data with zeros, which I understand is pretty confusing. Technically the data is already erased by the fact that the header is overwritten but some people want to be sure and write random data (or in the case of non-encrypted disks zeros) to the disk before deploying the system into production.

Alas, I do not have a backup of the LUKS header of this volume. As I said above, the intention was only to mount the previously encrypted volume, and not to change anything (so, to my regret, I didn't take the proper precautions).

The question: Is there any way to (re)generate the original LUKS header using the (known) original password against which this volume was encrypted, or is this data permanently lost?

Thank you for your consideration and your time.

Answer 1

There is no way to recover whatsoever. (*)

With LUKS, the passphrase you use to open the encryption, and the master key actually used for the encryption, are completely unrelated to one another.

Basically your passphrase decrypts a completely random key, and this random key is stored in the LUKS header. Losing the LUKS header entirely (or even changing a single bit of key material) renders you unable to obtain the master key used for the volume.

This is also why with LUKS, you can have 8 different passwords, and change each of these passwords any time you like, without re-encrypting all data. No matter how often you change the LUKS passphrase, the master key stays the same.

Master key recovery is explicitely NOT part of the LUKS concept, quite the opposite actually; LUKS takes many steps to prevent you (or anyone) to recover the master key from a (partly) overwritten LUKS header. The LUKS documentation even advises you to NOT backup the header, as a backup header out of your control means losing the ability to declare an old passphrase invalid. As the old passphrase would still be stored and usable in the old header.

(*) The only exception to this rule is if the container is still open. For an active crypt mapping, one might be able to obtain the master key with dmsetup table --showkeys. So if you killed your LUKS header in a running system and realized immediately, you could create a new LUKS header with the known master key.

Without the master key you cannot proceed and it's impossible to brute-force the master key, that's the whole point of the encryption in the first place. Well, you could do it given infinite CPU power and/or time, so if you want to leave your descendants with a puzzle, keep a copy of the encrypted data around and pass it on... ;)