On 2 Jul 2016 12:42 +0200, from bernd@xxxxxxxxxxxxxxx (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.se • michael@xxxxxxxxxxx “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
