On Sat, Aug 07, 2010 at 02:06:59PM -0700, epvdm@xxxxxxxxxx wrote: > > I'm trying to discover what happened to a Luks encrypted partition that's > become impossible to unlock following a reboot. The partition is a md > mirror of two disk partitions. > > I'm assuming that something has managed to corrupt the LUKS header, as > trying to unlock gives "No key available with this passphrase." I'm quite > confident the passphrase is correct, as it worked after a reboot a few > days ago, and i'm irresponsibly consistent in my passphrase choices, sad > to say. :) > > I have a bunch of mirror copies of the partition and the luks header data on > all of them (from luksHeaderBackup) is identical. So this is an n-way (n>2) RAID1? > luksDump shows what looks > like plausible data: > > Version: 1 > Cipher name: aes > Cipher mode: cbc-essiv:sha256 > Hash spec: sha1 > Payload offset: 1032 > MK bits: 128 > MK digest: a4 5e 29 97 a6 01 0c c8 f7 be ad e2 75 18 19 07 0b a2 e9 cd > MK salt: <...> > MK iterations: 10 > UUID: eab03b35-6945-4608-9ae3-14c4bda8c8df > > Key Slot 0: ENABLED > Iterations: 250772 > Salt: <...> > Key material offset: 8 > AF stripes: 4000 > Key Slot 1: DISABLED > ... > > All the necessary kernel modules, etc, are in place, as far as I can tell. > Again, it was mounted and working until a recent crash and reboot. > > I'm wondering if the header area ever gets written to under normal operation > such that a crash could have left it corrupted, or if it's only written when > modifying keyslots, etc... As far as I am aware of, nothing gets written unless you change a key-slot. > There are other partitions on the disks which don't appear to have become > corrupted. My main suspect so far is that md had something to do with it, > but it seems odd that it'd selective corrupt a small area of disk that > wouldn't have been written recently, that's well off in the middle of the > drive, and not damage more widely. > > Naturally I'd be thrilled to find some way of recovering the data but I'm > more concerned at the moment with finding out why it's suddenly stopped > working in the first place. > > I don't believe corruption to other parts of the volume, outside of the > header area, could cause it to fail to unlock like this; is that correct? AFAIK the above error will also happen if the key has been corrupted. As you can see from the FAQ, every key is about 128kB in size. Any bit changed in the key-stripes will result in unrecoverability. I have been using md-RAID for a long time, also in a 3-way RAID1 configuration and never had any corruption that I know of. For the time I would rule that out, especially if the data area on all mirrors is equal. I think you should compare the header, keyslots and key-stripes though. One way to do that would be to use 'cmp' on the raw devices and see where the first different byte is. The one possibility when md will ever corrupt somethin is when you get a manual mapping of the RAIDed area wrong and the RAID superblock happens to fall into a data area. There is a second possibility: Keyboard input problems. I know it sounds stupid, but try every character and symbol you have in your passphrase and see whether it echos right. 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
