Re: How to resume decryption on LUKS1 in-place

Hi,

On 21/02/2024 18:22, xndr wrote:
> 
> We followed the steps here on the Arch Linux wiki by converting from
> LUKS2 to LUKS1:-
> 
> https://wiki.archlinux.org/title/Removing_system_encryption#Decrypting_LUKS2_devices_in-place

While I greatly appreciate what Archlinux community does for 
documentation effort this particular hint is quite unfortunate. The hint 
has mistaken the cause and the effect of a dangerous experimentation and 
on top of all, it is outdated (as advertised under section 1.3 heading).

1) Up to (including) 2.4.3 LUKS2 clearly did not support decryption with 
LUKS2 header put in the beginning of data device (regular LUKS2 device). 
Someone tried to force
cryptsetup utility to bypass the limitation by making header device and 
data device the same via cmd line parameters. There was a bug that could 
not detect such dangerous case and initiated decryption anyway. We have 
patched the bug out ASAP. It definitely did not destroyed data but 
decrypted data in-palce at the original data offset (which is not user 
friendly and that's why it was not support from cli).

2) Since 2.5.0 you can decrypt LUKS2 device by specifying a file where 
LUKS2 header is migrated for the decryption to be possible. See man page 
cryptsetup-reencrypt, LUKS2 decryption examples section.

I'll suggest edit to the wiki mentioned above.

> 
> Unfortunately the device suffered an IO error at about 85% after issuing
> the final command:-

If you have suffered IO error due to HW issue the best thing you can do 
now is copy all data to a new device first (by dd utility for example) 
and try to finish the operation on the healthy device.

> 
> cryptsetup-reencrypt --decrypt /dev/sda3

If you have downconverted the device to LUKS1 before the decryption
you'd need to pass the original device UUID via --uuid parameter. LUKS1 
decryption uses files LUKS-<UUID>.[|log|org|new] to track the progress 
and to safe tempory LUKS1 headers. Look for those file in work directory 
from what you have initiated the operation. See cryptsetup-reencrypt man 
page, --uuid option.

But again, migrate your data to a healthy device first, provided the IO 
error had originated in a HW issue.

Also I'd recommend to update the cryptsetup package. The 
cryptsetup-reencrypt binary was replaced fully by "cryptsetup reencrypt" 
command (also for LUKS1) in 2.5.0 release in Jul '22.

> 
>   From the man pages it might seem that the process can be resumed by
> using the command:-
> 
> cryptsetup reencrypt --resume-only --header
> luks2-hdr-file /dev/encrypted_device

That's for LUKS2 only.

> 
> However it seems qualified by being a LUKS2 only facility. Should this
> command still work on LUKS1 or is the process (if there's one at all)
> different.
> 
> Available are copies of the headers (LUKS 1 & 2) in text and binary form
> and what appears to be a log generated during decryption.

If you have converted LUKS2 to LUKS1 before the decryption as the wiki 
suggests there should be only LUKS1 related logs and header backups.

> 
> Any counsel greatly appreciated - thank you.
> 
> 

Kind regards
O.