Answer below inline. On Fri, Jan 25, 2013 at 05:53:19PM +0000, Sebastian wrote: > Hello, > > I have quite a problem here with my notebook (debian squeeze and luks/dm-crypt > encrypted LVM). > After shutting it down yesterday, it did not let me unlock the encrypted disk > this morning. > > I already found the post from September 2012 in the mailing list, but it did not > exactly match my case (everything looks fine, not overwritten by SWAP data) > > > Header Information looks OK to me: > > # cryptsetup luksDump /dev/sda2 > LUKS header information for /dev/sda2 > > Version: 1 > Cipher name: aes > Cipher mode: cbc-essiv:sha256 > Hash spec: sha1 > Payload offset: 2056 > MK bits: 256 > MK digest: 53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad > MK salt: 50 5f a9 69 21 6e 21 ac db 09 bd 79 b0 9b 9b 1e > 14 2a 5d e4 46 2b 4d 9c 49 e3 9f 7d f9 d7 64 84 > MK iterations: 10 > UUID: b89fe8ad-3aea-4f27-9448-06e75fd8a05a > > Key Slot 0: ENABLED > Iterations: 75899 > Salt: 2d 2b 66 4c 57 eb ff e7 7f 63 14 8f c5 3b 6b aa > 38 53 2d 52 52 b6 d9 cc 84 b0 1a 11 bd cf 88 70 > 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 > > > Looking closer to the header (exported to file via luksHeaderBackup), right > after the initial information also shown by luksDump up to address 0x1000 (first > keyslot) is filled with zeroes, from 0x1000 until the end of the file random > data with no ASCII that would indicate files (e.g. header informations) or a > partition table. > > The key slot checker though, gives me this output: > > > ./chk_luks_keyslots /home/r4pt0r/notebook/luksheader.img > > Sectors with entropy below threshold (0.850000): > > Keyslot 0: start: 0x1000 > position: 0x10000 entropy: 0.625023 That is far too low. Your key-slot has been compromised. Have a look specifically at offset 0x10000, the problem seems to be only in the 512 bytes starting there. You can use option -v to get a hex-dump of that sector. > Keyslot 1: start: 0x21000 > keyslot not in use > > Keyslot 2: start: 0x41000 > keyslot not in use > > Keyslot 3: start: 0x61000 > keyslot not in use > > Keyslot 4: start: 0x81000 > keyslot not in use > > Keyslot 5: start: 0xa1000 > keyslot not in use > > Keyslot 6: start: 0xc1000 > keyslot not in use > > Keyslot 7: start: 0xe1000 > keyslot not in use > > > > So the entropy seems to be too low? But where does the address 0x10000 come > from? shouldn't the key start at 0x1000 similar to its slot? > > > I HAD an backup of the header on USB stick - the Notebook was set up around 3-4 > years ago but i really found my old backup-stick (32MB) where also gpg-keys and > other small files were backed up. > BUT: the stick seems to be broken :( It's not recognized by any PC and the LED > doesn't light up... > > > > As the Notebook is usually put to sleep-mode I really can't remember what > updates were installed since the last reboot. > > > > Is there any possibility the key is not damaged and data can be recovered? No. Sorry. Maybe professional data recovery for the stick? The only thing without header backup is to find out what actually did the damage. Interesting in its own right, for prevention. Please post your findings here! Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
