Re: Reencrypt process questions

On 9/30/19 10:51 PM, Yexie2Fe wrote:
> (...)
> 
> I also noticed that `cryptesetup` doesn't have the legacy
> `cryptsetup-reencrypt` option `--keep-key` which is useful to change the
> parameters like the hash function without actually reencrypting the
> data.

With LUKS2 you can have each keyslot with different parameters (hash 
included, with pbkdf2 function) so it did not make sense to do 
'reencryption' just to alter those parameters. As Milan pointed out we 
have luksConvertKey action for this. There's no need to replace whole 
LUKS2 header for it (that's what legacy cryptsetup-reencrypt utility did 
in fact with LUKS1 header).

> 
> Finally, the man page indicates that for `reencrypt
> --reduce-device-size`, "only --encrypt variant is supported". I used
> this option without `--encrypt` and it seemed to work, although the
> behavior was a little bit different compared to the reencryption of a
> non-encrypted device. >
> Using `reencrypt --reduce-device-size 32M` as advised, in the case a
> non-encrypted device, the final data offset is 16777216 bytes, whereas
> in case of a reencryption of an already encrypted device (with the LUKS1
> header size), the final offset is 35618816 bytes. I expected the header
> size to match the `--reduce-device-size` option value in the first case

It works as you describe I can only add more clarification. We advertise 
(currently) only the use case with device encryption because the 
reencryption seemed to us less significant, but it should work in both 
cases (at least on API level we have basic tests coverage).

Let's explain your examples with --reduce-device-size 32M. When you do 
encryption of plaintext device (placing LUKS2 header in the head of data 
device variant) we need spare storage to solve two problems:

1) We need to place LUKS2 header in head of the device (blkid scans for 
LUKS2 headers only at offset 0). But there's data there already. So we 
take 16MiBs of data in head of device and place it in the tail section 
of data device (--reduce-device-size parameter says there's 32MiBs free 
space at the end). After it, we place LUKS2 header in the head of device 
with proper mapping of data originally placed in head of the data device 
at offset 0. If you call "cryptsetup reencrypt --encrypt --init-only 
--reduce-device-size 32M" and "cryptsetup luksDump" afterwards you'll 
see the mapping of linear segment with id 0. The new LUKS2 header will 
have data offset 16MiB (as you've noticed).

2) We need to shift rest of data backwards (towards device tail, while 
performing encryption) so that we can reinstate segment with id 0 at 
offset 16MiB in the end. For the encryption with data shift we use 
second half of area at the tail of the data device (free of real data).

After encryption is completed you have regular LUKS2 device with data 
offset 16MiB and free 16 MiB at the tail of the device (you can extend 
fs to take the remining 16MiBs at the end). That's where my 
documentation fails (I'm going to add note about it).

On the other hand, when you perform reencryption with data shift you 
already have LUKS2 header with some data offset in the beginning of the 
operation. When you call "cryptsetup reencrypt --reduce-device-size 32M" 
we perform device reencryption with data shift and in the end (after 
reencryption is finished) we move the data offset 32MiB further (we 
don't need to consume half the value for LUKS2 header placement).

So only thing that seems odd to me is your offset 35618816 bytes. This 
is strange value. Could provide me with steps how you got that value?

I've run following steps, but failed to get same result:

1) cryptsetup luksFormat --type luks1 /dev/sdx
2) cryptsetup convert --type luks2 /dev/sdx
3) cryptsetup reencrypt --reduce-device-size 32M /dev/sdx

and I've got final data offset 35651584 bytes (2MiB original LUKS1 data 
offset + 32MiB gained by data shift during reencryption).

Did you have original LUKS1 device data offset not aligned to 1 MB?

Anyway for anyone interested, I've uploaded some asciinema videos with 
very basic tutorial for new LUKS2 reencryption code (includes detached 
header examples, LUKS2 in head of data device encryption & more).

Reencryption: https://asciinema.org/a/268573
Encryption:   https://asciinema.org/a/268574

Thank you for your feedback! And please report if you find any issue 
with LUKS2 reencryption code

Ondra
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt