On Fri, Apr 15, 2011 at 09:37:52PM +0200, Jonas Meurer wrote: > Hey, > > On 15/04/2011 Arno Wagner wrote: > > On Fri, Apr 15, 2011 at 03:52:34PM +0200, Cristian KLEIN wrote: > > > I assume there is no way to recover the original file system. Ubuntu has > > > most likely overwritten the LUKS header where the pretious salt is being > > > stored. The unencrypted disk most likely looks like random data now. > > > According to the FAQ [1], you can still resort to the dm-crypt > > > mailing-list to get over the five stages of grief. > > > > This may sound like sarcasm, but it is not. I wrote that and I > > realize the pain is real. This passage however serves a dual > > purpose and the second one is to warn people. > > > > > A posteriori, I cannot help wonder why such pretious information isn't > > > kept redundantly. > > > > The FAQ discusses this. It is a design-choice as keeping the > > header redundantly lowers security significantly. There is > > really no way to keep a backup header without making the > > anti-forensic measures ineffective. > > can you please elaborate on that? why not consider the following:? > > luksFormat could choose a random sector at the second half of the > to-be-encrypted device, save the sector number in the primary header, > and store a backup of the primary header at this place. > obviously, all commands that write to the LUKS header would need to > write to primary and backup header in that case. First, a single sector does not cut it. You need to store the keyslots as well, giving you 10 or 20MB to store. Second, LUKS has no idea about the device size and what is to be put in it. It can therefore not reserve any sectors. The sectors ''reserved'' at the beginning are done by ''shifting'' the start, but that does not work in any other place. > in case that one accidentially overwrites the primary header (which > is easily done as many device tools write to the first sectors of a > device), you still may grep the device for 'LUKS' in order to find the > backup header. that even would work in most cases if the device is > luksFormated again: the likeliness that luksFormat chooses the same > random sector for its backup header both times, is not very high, and > decreases with the size of device. > > as all luks commands write to both primary and backup header, shredding > the device would still be easy enough with luksKillSlot/luksRemoveKey. > nly thing that wouldn't work anymore, is overwriting the first few MB > of the device. And that is what kills the anti-forensics. > but then, it could be configurable by commandline whether luksFormat > creates a backup header at all, and everybody would be happy, no? Not possible, see above. I really do not see the point. Many filesystems are gone if you overwrite the start of the partition. It is one of the things careful users guard against by backing up. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
