[dm-crypt] Missing keyslot or broken header or still some hope?

zero.tonin at web.de zero.tonin at web.de
Sat Nov 5 22:58:30 CET 2016

Hi again, everybody, 
and yet another sorry - it is indeed weird to work on an unknown system and I ask ye to please accept my apology for causing any inconvenience with html or TOFU posts. I am slowly getting my debian VM to a workable degree, so I hope less errors occur from now on!

I did another ddrescue today after formatting one of my drives, as Michael suggested the missing 100 or so GB wouldn't cause the "no key with this passphrase" issue. 

Running the keyslotchecker from /misc results in the same as before (start: 0x001000, end: 0x03f800) , which, if I understood correctly, would indicate that the keyslot technically is still there and no bytes have been accidentally overwritten. 

The hexdump also still indicates the LUKS header where, as far as a layman like me can understand in this short period of time, it should be, with a hexdump resulting in
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

The drive is also (isLuks) recognized as a LUKS drive, still so - in theory- it al looks well and "I don't understand"

I tried adding a key to keyslot1, hoping that maybe this somehow would work with the original key in slot0, but, alas, no joy, the same, naturally, goes for attempting to luksChangekey, --dump-master-key or crptsetup-reencrypt

I was going through the options fro the man page and treid all those that looked somehow relevant to my situation, I thus created a luksDump, which resolves to this:
Key Slot 0: ENABLED
        Iterations:             342245
        Salt:                   72 3c b6 82 b3 33 a7 f6 5a 55 f9 3d 6b f3 8c b8 
                                d9 6a 66 31 9e 03 b1 57 b9 bf 00 5d d7 4a dd c9 
        Key material offset:    8
        AF stripes:             4000

I see there is a folder /test in the cryptsetup folder, but I could not locate a readme or something like it for them - would there be anything relevant I could try? 

I am also curios what my debian (or my HW, for that matter) could have done t the drive to render this state, as after the decrypt, when I realised the issue, I shut down the laptop immediately without "playing" with the LUKS. The only thing I could imagine would be some evil wizzard genius having somehow gotten luksErase into my cronjobs (which, of course would result in an empty keyslot 0, if I understand correctly...) or something like that. I suppose that's rather unlikely, though. Could the corrupt OS have ... changed the passphrase whilst the drive had been unlocked, without further user input?

I also see there is a "repair" mentioned in man, but I do not understand how to call this one (I have created a header backup in the meantime) or whether it would even make sense, as I am unsure what exactly is broken in the first place...

I also understand that the mailinglist is not a personal support tool, so again my gratitude for the comments and help I receive here!

Is there anything left to try with this drive or, at this stage, is "all lost" and I might as well wipe the drive, reinstall an OS and see (as it seems to be HW related) where I can safe up some money for a new machine?

Kind regards and thanks a mill,

More information about the dm-crypt mailing list