Re: [dm-crypt] LUKS Header crruption

Re: [dm-crypt] LUKS Header crruption

[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" <arno@wagner.name>
To: dm-crypt@saout.de
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

On Sun, Jul 28, 2019 at 13:57:50 CEST, Konstantin V. Gavrilenko wrote:
> 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
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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
dm-crypt@saout.de
https://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] LUKS Header crruption

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

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

On 7/29/19 7:08 AM, Konstantin V. Gavrilenko wrote:
> Thanks Arno, thought so :(
> Its a real pity that metadata is not redundant in luks v1.
> 
> Regards,
> Konstantin
> 
> 
> 
> ----- Original Message -----
> From: "Arno Wagner" <arno@wagner.name>
> To: dm-crypt@saout.de
> 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

Re: [dm-crypt] LUKS Header crruption

[Milan Broz]

On 29/07/2019 15:56, Robert Nichols wrote:
> 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


 

[dm-crypt] LUKS Header crruption

[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 

Re: [dm-crypt] LUKS Header crruption

[Arno Wagner]

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

On Sun, Jul 28, 2019 at 13:57:50 CEST, Konstantin V. Gavrilenko wrote:
> 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
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] LUKS Header crruption

[Uwe Menges]

On 7/28/19 11:00 PM, Arno Wagner wrote:
> 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.

Depending on the md metadata version, it's either at the start, at the
end, or 4k from start - each with its own drawbacks. The metadata needs
to reside somewhere, quite the same as with LUKS, or filesystem
metadata. If you have a hint on how to get around that, please tell.. :)

Yours, Uwe

Re: [dm-crypt] LUKS Header crruption

[Arno Wagner]

On Mon, Jul 29, 2019 at 09:25:15 CEST, Uwe Menges wrote:
> On 7/28/19 11:00 PM, Arno Wagner wrote:
> > 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.
> 
> Depending on the md metadata version, it's either at the start, at the
> end, or 4k from start - each with its own drawbacks. The metadata needs
> to reside somewhere, quite the same as with LUKS, or filesystem
> metadata. If you have a hint on how to get around that, please tell.. :)

Maybe read what I wrote, because you seem to not have done so? 
And yes, I am aware of the different problems. 

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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