Behavior of in-place encryption with --reduce-device-size

Behavior of in-place encryption with --reduce-device-size

[John A. Leuenhagen]

Hi all,

I was looking at doing in-place encryption on a currently unencrypted
volume, and found that this is supported through `cryptsetup reencrypt
--encrypt ...`. This is great, but I was curious as to how it actually
did this, and the details online were scarce for what could potentially
be a destructive operation.

What is unclear to me is that the LUKS header must go at the beginning
of the device, overwriting any data that might be there. The
--reduce-device-size option suggests that space will be taken from the
end of the device; does this mean that data will be shifted to the right
as encryption takes place? If so, how does this process fare against an
interruption (e.g. SIGINT)? The man page suggests this will be fine, but
I was curious about the details here.

Thanks,
John

Re: Behavior of in-place encryption with --reduce-device-size

[Milan Broz]

Hi,

On 5/29/24 7:45 PM, John A. Leuenhagen wrote:
> I was looking at doing in-place encryption on a currently unencrypted
> volume, and found that this is supported through `cryptsetup reencrypt
> --encrypt ...`. This is great, but I was curious as to how it actually
> did this, and the details online were scarce for what could potentially
> be a destructive operation.
> 
> What is unclear to me is that the LUKS header must go at the beginning
> of the device, overwriting any data that might be there. The
> --reduce-device-size option suggests that space will be taken from the
> end of the device; does this mean that data will be shifted to the right
> as encryption takes place?

yes.

> If so, how does this process fare against an
> interruption (e.g. SIGINT)? The man page suggests this will be fine, but
> I was curious about the details here.

This depends on format. For LUKS1, there are external files that tracks
process (basically old and new LUKS header and log where progress is stored).
For not yet encrypted device the old header basically just empty header.

For LUKS2, the reencryption metadata is stored in the header area itself
and reencryption can run online (device can be used during reencryption).

In both cases, ctrl+c interruption is safe - it will store progress and
restarts from it (you just need to run reencryption command manually again
otherwise device will remain in the middle of reencryption).

For unexpected interrupt (power fail) LUKS1 reencryption could lost
some data. For LUKS2 it depends on used resilience mode (--resilience parameter) -
it should completely recover if journal is used (as it stores data twice for
active reencryption region).

For more info read cryptsetup-reencrypt man page and section "4.9 Online Reencryption"
in LUKS2 format definition (https://gitlab.com/cryptsetup/LUKS2-docs)

In short, use the most recent cryptsetup version and LUKS2 format and it should work :)

Milan