LUKS Header crruption
A message that is not in the archive (sent off-list or not yet received): 1313728220.30.1564401565268.JavaMail.gkos@xpska
Thanks Arno, thought so :(
Its a real pity that metadata is not redundant in luks v1.
Regards,
Konstantin
----- Original Message -----
From: "Arno Wagner" <[email protected]>
To: [email protected]
Sent: Sunday, 28 July, 2019 11:00:49 PM
Subject: Re: [dm-crypt] LUKS Header crruption
Hi Konstantin,
sorry, you data is gone. You overwrote the start of the first key-slot and there is no way to recover from that without backup.
One of the reasons why I think RAID superblocks at the start of the device (and even more so at 4kB offset) are messed up and a sign of clueless designers.
Regards,
Arno
Quoted 56 lines · Konstantin V. Gavrilenko
Hi List,
as a result of executing a command from the history, after a reboot, when the disk letters were changed, I have accidentally overwritten the LUKS header with the raid superblock one :(
Now I can not open the cryptodisk with the "luksOpen" as it states the "No key available with this passphrase."
However, when I run "luksDump" the header information is available
# cryptsetup luksDump /dev/sdd1 LUKS header information for /dev/sdd1Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 256 MK digest: a6 a6 de 04 5a 19 9f 97 54 a9 79 bf f8 c1 37 89 69 44 34 76 MK salt: 7a 0b 8e cc 68 06 35 ec 09 fc 5e f9 90 e3 c9 ef 8b 11 96 10 4c 25 ab 89 a1 48 df fe 6a 88 20 96 MK iterations: 232809 UUID: 0f91c412-6f6a-405d-8040-5cc17ad17b47Key Slot 0: ENABLED
Iterations: 3724958 Salt: c4 52 ac 04 59 8a d1 4f 7a 3c 5d e8 d3 50 1a c4 11 20 0b 66 66 81 78 09 9f 7a f4 c1 dc 80 d4 40 Key material offset: 8 AF stripes: 4000Key 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: DISABLEDThe RAID superblock that was written by mdadm is default, version 1.2 that
is located 4K from the beginning of the device.Providing that I have no backup of the original header and I know wht was written, is there a way to restore the header and get the data?
Konstantin
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt
Signature · 11 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list [email protected] https://www.saout.de/mailman/listinfo/dm-crypt
The key material is quite deliberately made just the opposite of redundant. It is artificially inflated (typically 4000X) to occupy a larger area of the disk, and in such a manner that successfully erasing any portion of that area makes the key unrecoverable.
Signature · 2 lines
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.Quoted 25 lines · Konstantin V. Gavrilenko
Thanks Arno, thought so :(
Its a real pity that metadata is not redundant in luks v1.Regards,
Konstantin----- Original Message -----
From: "Arno Wagner" <[email protected]>
To: [email protected]
Sent: Sunday, 28 July, 2019 11:00:49 PM
Subject: Re: [dm-crypt] LUKS Header crruptionHi Konstantin,
sorry, you data is gone. You overwrote the start of the first key-slot and there is no way to recover from that without backup.
One of the reasons why I think RAID superblocks at the start of the device (and even more so at 4kB offset) are messed up and a sign of clueless designers.
Regards,
Arno
Quoted 4 lines · Robert Nichols
The key material is quite deliberately made just the opposite of redundant. It is artificially inflated (typically 4000X) to occupy a larger area of the disk, and in such a manner that successfully erasing any portion of that area makes the key unrecoverable.
Exactly. And this part is not changed even in LUKS2 (only metadata is stored twice).
For LUKS2, we just store keyslots content in area with higher offset, seems that data corruption (caused by overwriting by random too-clever software) is not so common here (like for the keyslot 0 in LUKS1).
Solution is to backup LUKS header.
Milan