[dm-crypt] Recreation of LUKS header when the master key is known

[dm-crypt] Recreation of LUKS header when the master key is known

[Mikhail Morfikov]

My friend zeroed out the first 3 GiB of a drive, including the partition table,
LUKSv1 header, and EXT4 superblock + some data of the first partition. He
realized what he did, and before rebooting the system, he recovered the master
key via the following command:

-----------------------------
# dmsetup table --showkeys /dev/mapper/encrypted | awk '{ print $5 }' | xxd -r
-p > /tmp/master_key
-----------------------------

He saved the key and later on (offline) he wanted to recreate the LUKS header
using the following command:

-----------------------------
# cryptsetup luksFormat -v -y -c aes-xts-plain64
--master-key-file=/tmp/master_key /dev/sdd1
-----------------------------

But he was unable to decrypt the data (I know the ext4 superblock is damaged,
but the volume can be tested whether it is decrypted or not, and in this case it
wasn't).

He said that the original container was created (probably) using this command:

# cryptsetup -v -y -c aes-xts-plain64 -s 512 -h sha512 -i 5000 --use-random
luksFormat /dev/sdd1

He ultimately found the header backup and everything went well, but I have a
question -- what parameters are needed in order to recreate the header when the
master key is known?

Re: [dm-crypt] Recreation of LUKS header when the master key is known

[Michael Kjörling]

On 5 Aug 2018 23:53 +0200, from mmorfikov@gmail.com (Mikhail Morfikov):
> # cryptsetup luksFormat -v -y -c aes-xts-plain64
> --master-key-file=/tmp/master_key /dev/sdd1
> 
> But he was unable to decrypt the data (I know the ext4 superblock is damaged,
> but the volume can be tested whether it is decrypted or not, and in this case it
> wasn't).
> 
> He said that the original container was created (probably) using this command:
> 
> # cryptsetup -v -y -c aes-xts-plain64 -s 512 -h sha512 -i 5000 --use-random
> luksFormat /dev/sdd1
> 
> He ultimately found the header backup and everything went well, but I have a
> question -- what parameters are needed in order to recreate the header when the
> master key is known?

Well, the cipher spec for one would obviously need to match exactly
for the newly created header to be useful for decrypting the existing
data. So depending on the defaults, the missing `-s 512` absolutely
could make a difference.

My cryptsetup says the default for LUKS1 is aes-xts-plain64 with 256
bits of key. So if your friend's system is similar to mine, chances
are good that the missing key length specifier had something to do
with it. The man page doesn't seem to say anything about what happens
if the provided master key file has a length different from the key
length that ends up being used by the selected cipher.

Keep in mind that with XTS you're effectively running the cipher
itself in half the key length mode (so if you specify AES-XTS and 256
bits of key, then the actual key used by AES is a 128 bit one). Thus,
the difference between specifying 512 bits and 256 bits means running
AES with a 256 bit key or a 128 bit key, respectively. Specifically
for AES, this also means running a different number of rounds; IIRC,
with a 256 bit key, AES uses 14 rounds, whereas with a 128 bit key, it
uses 10 rounds. So it's effectively a _very_ different cipher if you
use a different key length.

Personally, I have written down the exact commands used to create the
LUKS containers, just in case.

At least in this case your friend _had_ a header backup.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

Re: [dm-crypt] Recreation of LUKS header when the master key is known

[Arno Wagner]

It may also be a good idea to go with the defaults, unless there is
a very good way not to.

Regards,
Arno

On Mon, Aug 06, 2018 at 00:33:59 CEST, Michael Kjörling wrote:
> On 5 Aug 2018 23:53 +0200, from mmorfikov@gmail.com (Mikhail Morfikov):
> > # cryptsetup luksFormat -v -y -c aes-xts-plain64
> > --master-key-file=/tmp/master_key /dev/sdd1
> > 
> > But he was unable to decrypt the data (I know the ext4 superblock is damaged,
> > but the volume can be tested whether it is decrypted or not, and in this case it
> > wasn't).
> > 
> > He said that the original container was created (probably) using this command:
> > 
> > # cryptsetup -v -y -c aes-xts-plain64 -s 512 -h sha512 -i 5000 --use-random
> > luksFormat /dev/sdd1
> > 
> > He ultimately found the header backup and everything went well, but I have a
> > question -- what parameters are needed in order to recreate the header when the
> > master key is known?
> 
> Well, the cipher spec for one would obviously need to match exactly
> for the newly created header to be useful for decrypting the existing
> data. So depending on the defaults, the missing `-s 512` absolutely
> could make a difference.
> 
> My cryptsetup says the default for LUKS1 is aes-xts-plain64 with 256
> bits of key. So if your friend's system is similar to mine, chances
> are good that the missing key length specifier had something to do
> with it. The man page doesn't seem to say anything about what happens
> if the provided master key file has a length different from the key
> length that ends up being used by the selected cipher.
> 
> Keep in mind that with XTS you're effectively running the cipher
> itself in half the key length mode (so if you specify AES-XTS and 256
> bits of key, then the actual key used by AES is a 128 bit one). Thus,
> the difference between specifying 512 bits and 256 bits means running
> AES with a 256 bit key or a 128 bit key, respectively. Specifically
> for AES, this also means running a different number of rounds; IIRC,
> with a 256 bit key, AES uses 14 rounds, whereas with a 128 bit key, it
> uses 10 rounds. So it's effectively a _very_ different cipher if you
> use a different key length.
> 
> Personally, I have written down the exact commands used to create the
> LUKS containers, just in case.
> 
> At least in this case your friend _had_ a header backup.
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
>   “The most dangerous thought that you can have as a creative person
>               is to think you know what you’re doing.” (Bret Victor)
> _______________________________________________
> 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] Recreation of LUKS header when the master key is known

[Michael Kjörling]

On 6 Aug 2018 09:30 +0200, from arno@wagner.name (Arno Wagner):
> It may also be a good idea to go with the defaults, unless there is
> a very good way not to.

Absolutely, but the defaults can and do change over time, so that's
not completely foolproof especially for long-lived containers. In my
case I do have good reason to provide some extra parameters with
non-obvious values, and safekeeping those only seems prudent. From
there to even being explicit about using what's default is a pretty
small step.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

Re: [dm-crypt] Recreation of LUKS header when the master key is known

[Milan Broz]

There was a script in cryptsetup repo, that did exactly this task
(re-create LUKS header according to active device parameters).

See misc/luks-header-from-active in git.

But it is probably no longer working (definitely not with LUKS2 where
we store dm-crypt key in keyring), but some parts can be useful still.

I will need to fix it later... Patches welcome :)

Milan

On 05/08/18 23:53, Mikhail Morfikov wrote:
> My friend zeroed out the first 3 GiB of a drive, including the partition table,
> LUKSv1 header, and EXT4 superblock + some data of the first partition. He
> realized what he did, and before rebooting the system, he recovered the master
> key via the following command:
> 
> -----------------------------
> # dmsetup table --showkeys /dev/mapper/encrypted | awk '{ print $5 }' | xxd -r
> -p > /tmp/master_key
> -----------------------------
> 
> He saved the key and later on (offline) he wanted to recreate the LUKS header
> using the following command:
> 
> -----------------------------
> # cryptsetup luksFormat -v -y -c aes-xts-plain64
> --master-key-file=/tmp/master_key /dev/sdd1
> -----------------------------
> 
> But he was unable to decrypt the data (I know the ext4 superblock is damaged,
> but the volume can be tested whether it is decrypted or not, and in this case it
> wasn't).
> 
> He said that the original container was created (probably) using this command:
> 
> # cryptsetup -v -y -c aes-xts-plain64 -s 512 -h sha512 -i 5000 --use-random
> luksFormat /dev/sdd1
> 
> He ultimately found the header backup and everything went well, but I have a
> question -- what parameters are needed in order to recreate the header when the
> master key is known?
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] Recreation of LUKS header when the master key is known

[Mikhail Morfikov]

On 2018-08-06 00:33, Michael Kjörling wrote:
> On 5 Aug 2018 23:53 +0200, from mmorfikov@gmail.com (Mikhail Morfikov):
>> # cryptsetup luksFormat -v -y -c aes-xts-plain64
>> --master-key-file=/tmp/master_key /dev/sdd1
>>
>> But he was unable to decrypt the data (I know the ext4 superblock is damaged,
>> but the volume can be tested whether it is decrypted or not, and in this case it
>> wasn't).
>>
>> He said that the original container was created (probably) using this command:
>>
>> # cryptsetup -v -y -c aes-xts-plain64 -s 512 -h sha512 -i 5000 --use-random
>> luksFormat /dev/sdd1
>>
>> He ultimately found the header backup and everything went well, but I have a
>> question -- what parameters are needed in order to recreate the header when the
>> master key is known?
> 
> Well, the cipher spec for one would obviously need to match exactly
> for the newly created header to be useful for decrypting the existing
> data. So depending on the defaults, the missing `-s 512` absolutely
> could make a difference.
> 
> My cryptsetup says the default for LUKS1 is aes-xts-plain64 with 256
> bits of key. So if your friend's system is similar to mine, chances
> are good that the missing key length specifier had something to do
> with it. The man page doesn't seem to say anything about what happens
> if the provided master key file has a length different from the key
> length that ends up being used by the selected cipher.
> 
> Keep in mind that with XTS you're effectively running the cipher
> itself in half the key length mode (so if you specify AES-XTS and 256
> bits of key, then the actual key used by AES is a 128 bit one). Thus,
> the difference between specifying 512 bits and 256 bits means running
> AES with a 256 bit key or a 128 bit key, respectively. Specifically
> for AES, this also means running a different number of rounds; IIRC,
> with a 256 bit key, AES uses 14 rounds, whereas with a 128 bit key, it
> uses 10 rounds. So it's effectively a _very_ different cipher if you
> use a different key length.
> 
> Personally, I have written down the exact commands used to create the
> LUKS containers, just in case.
> 
> At least in this case your friend _had_ a header backup.
> 
Thanks for the answer.