[dm-crypt] LUKS keyslot invalid

[dm-crypt] LUKS keyslot invalid

[wpc95]

Hello,

i am running LUKS for the last years without any problems, but now have
encountered a strange behaviour of cryptsetup. A workstation has 4
SATA-drives, 3 of them encrypted with LUKS. Running Ubuntu 10.04 (cryptsetup
1.1.0-rc) all encrypted drives can be opened and accessed without any
hassle. Running Ubuntu 12.04 (cryptsetup 1.4.0) LUKS claims for 2 of the
encrypted drives, that 'LUKS keyslot 4 is invalid'. Due to the fact that the
option 'repair' was launched with cryptsetup 1.4.1, i have started the
computer with an actual live-linux. But the result with cryptsetup 1.5.0 is
the same as with 1.4.0: it claims, that 'LUKS keyslot 4 is invalid. Invalid
offset 1576471435 [first drive] 3746914134 [second drive] in keyslot 4.' The
repair option says that repair failed with code 22 and a manual repair is
required. How is a 'manual repair' done and why does the error does not
appear with cryptsetup 1.1.0-rc? I have - of course - backups of the
4K-headers and the complete data of all drives. :-)

Thanks for any suggestions,
Jan

Re: [dm-crypt] LUKS keyslot invalid

[Milan Broz]

On 12/29/2012 11:03 PM, wpc95 wrote:
> i am running LUKS for the last years without any problems, but now have
> encountered a strange behaviour of cryptsetup. A workstation has 4
> SATA-drives, 3 of them encrypted with LUKS. Running Ubuntu 10.04 (cryptsetup
> 1.1.0-rc) all encrypted drives can be opened and accessed without any
> hassle. Running Ubuntu 12.04 (cryptsetup 1.4.0) LUKS claims for 2 of the
> encrypted drives, that 'LUKS keyslot 4 is invalid'. Due to the fact that the
> option 'repair' was launched with cryptsetup 1.4.1, i have started the
> computer with an actual live-linux. But the result with cryptsetup 1.5.0 is
> the same as with 1.4.0: it claims, that 'LUKS keyslot 4 is invalid. Invalid
> offset 1576471435 [first drive] 3746914134 [second drive] in keyslot 4.' The
> repair option says that repair failed with code 22 and a manual repair is
> required. How is a 'manual repair' done and why does the error does not
> appear with cryptsetup 1.1.0-rc? I have - of course - backups of the
> 4K-headers and the complete data of all drives. :-)

Previous versions silently ignored error (so once you use that invalid
keyslot, you risk something is overwritten).
(But workaround is downgrade cryptsetup :)

But it is strange that repair cannot fix this... 

If you send me (privately) header backup I can fix the header
(and add check to code so repair can do that automatically).
I do not need password, perhaps not even the keyslot data (so first 4kB should
be enough)

Please note that backup of 4kB is only visible header, the real keyslot
data are located next to this area.

If you do not want to send this, please post luksDump and
log from repair command with added --debug (it should print more info).

You can also try keyslot checker in source code (written by Arno).
But I think here we need repair the header first.

Thanks,
Milan

Re: [dm-crypt] LUKS keyslot invalid

[Milan Broz]

On 12/29/2012 11:03 PM, wpc95 wrote:
> Running Ubuntu 12.04 (cryptsetup 1.4.0) LUKS claims for 2 of the
> encrypted drives, that 'LUKS keyslot 4 is invalid'. Due to the fact that the
> option 'repair' was launched with cryptsetup 1.4.1, i have started the
> computer with an actual live-linux. But the result with cryptsetup 1.5.0 is
> the same as with 1.4.0: it claims, that 'LUKS keyslot 4 is invalid. Invalid
> offset 1576471435 [first drive] 3746914134 [second drive] in keyslot 4.' The
> repair option says that repair failed with code 22 and a manual repair is
> required.

Just for the archive - the current repair code is able to fix this problem
(it was just simple 4 bytes overwrite, fortunately on unused keyslot metadata).

I was just too cautious and did not enabled repair of 512bit (XTS mode) keys.
That restriction is now removed, so next time repair code should work.

Milan