On Wed, Feb 18, 2009 at 03:15:32PM +0100, orinoco wrote: [...] > With ... I get ... > > # cryptsetup luksDump /dev/sdb5 > LUKS header information for /dev/sdb5 > > Version: 1 > Cipher name: aes > Cipher mode: cbc-essiv:sha256 > Hash spec: sha1 > Payload offset: 1032 > MK bits: 128 > MK digest: XX (x20) > MK salt: XY (x16) > XZ (x16) > MK iterations: 10 > UUID: <uuid-of-failure-device> > > Key Slot 0: ENABLED > Iterations: 247257 > Salt: YX (x16) > YY (x16) > Key material offset: 8 > AF stripes: 4000 > Key Slot 1: DISABLED > Key Slot 2: DISABLED > Key Slot 3: DISABLED > Key Slot 4: DISABLED > Key Slot 5: DISABLED > Key Slot 6: DISABLED > Key Slot 7: DISABLED > ----------------------------------- > > # cryptsetup luksOpen /dev/sdb5 encdisk0 > Enter LUKS passphrase: > Enter LUKS passphrase: > Enter LUKS passphrase: > Aufruf fehlgeschlagen: No key available with this passphrase. > ----------------------------------- So the header looks good but open fails. Most likely is a defective key block. No way to repair that. > > Unfortunately it looks like the LUKS homepage at > > http://luks.endorphin.org/ > > is down at the moment. However it seems the PDF with > > the on-disk specification is also available here: > > http://code.google.com/p/cryptsetup/wiki/Specification > > > > Rough overview is the figure directly under 1. Overview. > > The actual on-disk header in detail is in Figure 1, > > and the keyslod description is in Figure 2. > > I'm going through this, struggling how to apply ... I think you do not need to bother. It would have been helpful with a damaged LIKS header. But as that seems fine, the problem is likely in the binary key data. > > I think you absolutely need the fields at offsets > > 112 and 132, in addition to a keyslot with > > intact salt data and the actual key-block intact. > > As far as I can see from luksDump there is > MK digest and MD salt. But there seems to be something wrong with it. Indeed. > > There may be other fields you absolutely need, but > > 32-64 bits or so can be brute-forced today without too > > much hassle, depending on what actually need to be done > > for a try. This still costs significant effort and > > may cause significant cost. > > > > The other thing is to think about how much your data is > > worth. It may be cheaptest to regard this as a lost > > cause from the beginning. > > I would consider it "nice to have it back" and worth some effort. > It isn't (or wasn't) vital information. Good to know. I think you have done all the easy steps. My advice is to cut your losses and start over with a new encrypted partition. > > Although I would recomment at least > > one in-detail look at the header. It may basically still > > be there. > > There is a "complete" header information I get from luksDump (see > above), but it does not seem to work with luksOpen and the original > passphrase. > > BTW I noticed that my system keeps mixing the sdXX device order. > After a reboot it changed again. That is really bad, expecially with automated swap creation. I have had one instance of something similar: I have a mainboard that turns the last drive booted from into the first BIOS drive. I get around this by having all raid partitions for Linux (even one-device RAID1) as the md-numbers are independent from the base drive number. What I would advise is that you delegate the swap creation to a script, that at least checks partition size before trashing it. You may also want to, e.g., not use the first kB of the partition and put a magic number in there that you also check. Come to think of it, you could also put your swap on an one-partition RAID1 and then access it by its /dev/md<number> (set partition type to autodetection). That should be stable and circumvent your problem. 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 - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
