Skip to contentSkip to conversation

LUKS Header crruption

dm-crypt Konstantin V. Gavrilenko 3 participants 3 messages Jul 29, 2019 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 1313728220.30.1564401565268.JavaMail.gkos@xpska

#1 lore raw

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/sdd1
Version:        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-5cc17ad17b47

Key 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:             4000

Key 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: DISABLED

The 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
#2 lore raw

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

#3 lore raw
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