cryptsetup header in-place decryption - reporting about a bug alert

cryptsetup header in-place decryption - reporting about a bug alert

[doffloster]

Hi all,

In this email I'm reporting about an issue that I read about:

Regarding the webpage "Removing system encryption" in website
"archlinux.org" - link:

https://wiki.archlinux.org/title/Removing_system_encryption#Decrypting_LUKS2_devices_in-place

There is the following text under the subtitle "Decrypting LUKS2
devices in-place":

> Warning: As of 2020, and version 2.3.3, when using cryptsetup to
> decrypt a LUKS2 block device the program requires you to provide a
> LUKS --header file. If you do not use the "detached header" feature
> of LUKS, and naively try to pass the block device itself (which
> contains a LUKS2 header) as the subject of the --header, cryptsetup
> will accept this and go ahead with alleged decryption. Afterwards the
> block device will show up as a LUKS2 device with no key-slots, and
> your data will be lost. If you try to use cryptsetup luksHeaderBackup
> as the header file used with --header, your data will be lost. If you
> try to restore a backed-up header after this faulty decryption, your
> data will still be lost.
>
> If you still went ahead with the decryption, the data might be
> recoverable by shifting the partition start after the now defunct
> LUKS header: [1], still, do not rely on this.

Note: I did NOT test this, though I'd rather let you know about it.

Thank you.
David.

Re: cryptsetup header in-place decryption - reporting about a bug alert

[Ondrej Kozina]

Hi,

On 12. 08. 22 17:04, doffloster@gmail.com wrote:
> Hi all,
> 
> In this email I'm reporting about an issue that I read about:

Yup, we've seen the issue: 
https://gitlab.com/cryptsetup/cryptsetup/-/issues/614

At the time of the report, cryptsetup did not support decryption of 
LUKS2 devices with header put in head of data devices. The original 
Stack Exchange reporter managed to force/trick cryptsetup CLI into 
operation that even though correctly executed did not satisfied user's 
expectations. Data was not lost as incorrectly claimed in the wiki 
description.

We do not have fuzzy testing for CLI options yet. So from time to time, 
yet another funny options combination might pop up as long as people 
throw random options to it. We do our best to cover it in testsuite but 
sometimes it's not enough.

> There is the following text under the subtitle "Decrypting LUKS2
> devices in-place":
> 
>> Warning: As of 2020, and version 2.3.3, when using cryptsetup to
>> decrypt a LUKS2 block device the program requires you to provide a
>> LUKS --header file. If you do not use the "detached header" feature
>> of LUKS, and naively try to pass the block device itself (which
>> contains a LUKS2 header) as the subject of the --header, cryptsetup
>> will accept this and go ahead with alleged decryption. Afterwards the
>> block device will show up as a LUKS2 device with no key-slots, and
>> your data will be lost.If you try to use cryptsetup luksHeaderBackup
>> as the header file used with --header, your data will be lost. If you
>> try to restore a backed-up header after this faulty decryption, your
>> data will still be lost.

It's outdated since 2.4.0 upstream release (fix was also backported to 
latest 2.3.7 bugfix release).

Nevertheless, the missing decryption feature for LUKS2 devices (with 
header in head of data device) was added in cryptsetup 2.5.0 in the 
meantime: 
https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.5/v2.5.0-ReleaseNotes

Regards
O.