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

Sven Eschenberg sven at whgl.uni-frankfurt.de
Sat Nov 5 23:41:24 CET 2016

Hi there,

I did not have the opportunity to read all of the discussion, but 
thought I might add in some bits.

Am 05.11.2016 um 22:58 schrieb zero.tonin at web.de:
> 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.

In fact only the header is really relevant to cryptsetup. If the image 
was truncated the filesystem might have been partially damaged (within 
the image that is), but you'd at least be able to unlock() and see the 
fs-signature if you captured enough sectors at the beginning of the LUKS 

> 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.

Exactly, the slot itself seems to be intact, as far as analysis can go.

> 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"

Well, if the key material was damaged, then even when your password is 
correct, the hash value would not match and even worse, the retrieval of 
the actual disk key would fail. There is no redundancy in the keyslot 
that can compensate for bit-errors.

> 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

Adding a key needs the drive key, which would have to be restored from a 
working slot. Well, it could be retrieved from mem, when the container 
is open, but that does not apply in your case.

> 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?

Did you actaully try to luksDump on the original drive from some live 
system? And maybe dump the first 8MB of the LUKS container, including 
the header and see if the dump is stable?(i.e. do multiple dumps and 
compare hashes or diff) If it changes then you are really having issues 
with unstable read results and would have to have enormous luck to get 
the correct data to unlock the slot.

> 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?

Well of course a keyslot can be overriden purposefully, cryptsetup, when 
unlocking the container, does however not write to the header area at 
all. The results so far do not show signs of typical errors like 
overwriting with fs-signatures or so. Since the header structure seems 
to be okay, something would have had to overwrite some parts of the 
actual keyslot area. There are a lot of possibilities how this could 
happen if there's some defect.

> 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...

Sorry, never had any need for it so far, better wait for an answer from 
someone else regarding this.

> 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,
> Mark
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Final words: You said, you are sure the PW is correct. Are you 100% sure 
that the keyboard layout was correct and no character mapping issues are 
involved? Double checked on the live env?



More information about the dm-crypt mailing list