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
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
