[dm-crypt] Incidentaly partitioned LUKS device - header lost?

Michael Kjörling michael at kjorling.se
Sun Jul 3 22:40:30 CEST 2016

On 2 Jul 2016 12:42 +0200, from bernd at braegelmann.net (Bernd Brägelmann):
> My current last hope is that the salt might be in a redundant part of
> the raid array.

Unfortunately, as Arno has already described, RAID inconsistencies are
really short-lived, so there would be no trace of that data by the
time you realized your error, much less by the time grep had a chance
to finish executing. And we can probably assume that properly done
256-bit AES-XTS is, for all practical purposes, not breakable at the
cryptographic level. Compare <https://security.stackexchange.com/a/6149/2138>
which concludes that, with some _very_ optimistic assumptions,
including using _all of Earth's resources for a decade_, we _might_ be
able to _count_ to 2^138 by 2040 or so. (We'd still not be able to
actually _do anything useful_ with that counter, so it'd be a rather
pointless exercise.) Bottom line, brute forcing AES in anything
resembling realistic time frames is simply not feasible.

I like Jörg W Mittag's description of the difference between
redundancy (RAID) and backups, which feels applicable here:

> If you accidentally overwrite your PhD thesis with garbage,
> redundancy ensures that you have multiple copies of garbage, in case
> one gets bad. A backup ensures that you can restore your PhD thesis.
> (And an archive ensures that you can retrieve multiple older versions
> of your thesis, and a version control system also tells you why you
> made a new version in the first place.)

The above shamelessly borrowed from <https://serverfault.com/a/3697/58408>.

What _would_ have helped in your situation, and I'm noting this in the
tiny hopes that it might help someone else avoid a similar
catastrophe, is a LUKS header backup or the master key for the
container, stored somewhere else. (If you dump the header using
luksHeaderBackup, then the copy is still encrypted with your
passphrase(s), so this is reasonably safe to store. The master key can
be dumped unprotected, which is probably a bad idea in many situations
but may be valid in others.) Or, of course, `sudo file -s /dev/md2` or
`lsblk /dev/md2` before `fdisk /dev/md2`.

Michael Kjörling • https://michael.kjorling.semichael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

More information about the dm-crypt mailing list