Ok, so I took to reading http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf. This is what the LUKS header looks like: 0000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 >LUKS....aes.....< 0000016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 0000032 00 00 00 00 00 00 00 00 63 62 63 2d 65 73 73 69 >........cbc-essi< 0000048 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 >v:sha256........< 0000064 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 >........sha1....< 0000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 0000096 00 00 00 00 00 00 00 00 00 00 04 08 00 00 00 10 >................< 0000112 b9 68 70 a2 ac ca f7 f6 f6 8f b8 ba 33 59 3c 61 >.hp.........3Y<a< 0000128 f3 e0 68 98 4a 42 a9 ab e0 74 0f ee 8a 98 5b f8 >..h.JB...t....[.< 0000144 d7 80 f7 73 da a4 dd 16 5f 2e 18 48 f9 28 c7 7e >...s...._..H.(.~< Here is the UUID, at offset 168, as promised: 0000160 e9 07 5f bf 00 00 00 0a 35 38 35 32 64 36 32 36 >.._.....5852d626< 0000176 2d 30 34 32 38 2d 34 33 38 32 2d 62 63 61 36 2d >-0428-4382-bca6-< 0000192 63 30 34 33 35 30 35 35 39 63 65 62 00 00 00 00 >c04350559ceb....< These are the key slot descriptors: #0 (0x0ac71fe, l33t): 0000208 00 ac 71 f3 00 02 29 d4 58 a9 bb e9 4d 31 03 54 >..q...).X...M1.T< [...] #1: 0000256 00 ac 71 f3 00 01 75 6c 41 fc a7 02 38 4d ff 6d >..q...ulA...8M.m< [...] #2: 0000304 00 ac 71 f3 00 01 ac c6 cd 00 34 39 60 d3 0b d3 >..q.......49`...< 0000320 d8 c5 b6 72 b3 a1 cd 01 77 a8 d4 84 0e bf 67 5c >...r....w.....g\< 0000336 c2 73 b2 7e b7 ca de 75 00 00 01 08 00 00 0f a0 >.s.~...u........< 0x01acc6 iterations, salt is cd 00 34 39 [...] ca de 75, key material in sector 0x108 (264). #3-#7 are unused: 0000352 00 00 de ad 00 00 00 00 00 00 00 00 00 00 00 00 >................< [...] 0000592 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< The phdr ends here. So let's see sector 264. I suppose sectors are numbered from 0? In that case, skipping 0 yields the 0th sector, skipping 1 the 1st and so on, so I need to skip 264 to see the 264th: dd if=/dev/md42 bs=512 skip=264 count=1 | od -A x -tx1z 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 000200 [...] Empty. The RAID5 array used a chunksize of 64k, which means that sectors 0-127 were on disk 0, sectors 128-255 on disk 1, sectors 256-383 on disk 3; disk 4 contained a parity block for these; and sectors 384-511 were on disk 0 again. Sector 264 is at the beginning of disk3 and was thus overwritten with a RAID superblock. That means that the offsets from the FAQ don't apply to my LUKS container and that keyslot #2 has been wiped after all. However, in this case, keyslot #0 should still be intact. Its key material started in sector 8 (according to luksDump), which is not empty. The RAID superblock on disk 1 got written to 4k from its start, which is 8 sectors, thus 128+8=136, the offset of the key material for keyslot #1. By all accounts, keyslot #0 is fine after all, having been narrowly missed by mdadm (and dumping it shows no zeroed sections). And indeed it is! I could luksOpen it. I had been mistyping the passphrase all this time. :) Thanks! Andras _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
