Thanks for your answer (and Milan's).
> > 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).
I was actually referring to the MK digest. Consider the following
example:
$ dd if=/dev/zero of=luksVolume bs=1M count=1024
$ cryptsetup luksFormat luksVolume
$ cryptsetup luksDump luksVolume
Data segments:
0: crypt
offset: 16777216 [bytes]
Digests:
0: pbkdf2
Hash: sha256
Iterations: 98402
Now we reencrypt.
$ cryptsetup reencrypt --reduce-device-size=32M luksVolume
$ cryptsetup luksDump luksVolume
Data segments:
0: crypt
offset: 50331648 [bytes]
Digests:
0: pbkdf2
Hash: sha256
Iterations: 1000 # iterations value is wrong
The iterations are not computed properly, but the offset matches the
expected device size shrinking. That's the issue I mentioned in my
first message.
Now, in order to update this value (or changing the hash function for
instance), I can either use the `cryptsetup-reencrypt --keep-key` or the
following method, which requires a little more care (like writing the MK
to volatile memory):
$ cryptsetup luksDump --dump-master-key --master-key-file=luksKey luksVolume
$ cryptsetup luksFormat --master-key-file=luksKey luksVolume
$ cryptsetup luksDump luksVolume
Data segments:
0: crypt
offset: 16777216 [bytes] # the offset is "wrong"
Digests:
0: pbkdf2
Hash: sha256
Iterations: 101685
But since I "forgot" to specify the offset, it is now invalid. So I was
essentially asking for a `luksReset` function that does the job of
`luksFormat` while keeping the master key and the proper encrypted data
offset.
> > 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
>
> 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 wrongly copied the keyslot area size instead of the offset.
> and I've got final data offset 35651584 bytes (2MiB original LUKS1 data
> offset + 32MiB gained by data shift during reencryption).
And thus I get the exact same value.
> 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).
Thanks for your explanation. I did not understand why I would get an
header size of reduce-device-size / 2 when first encrypting (which might
actually be useful if one needs that extra keyslots space but it is not
my case).
Maybe is it possible to be more explicit by allowing to specify
`--luks2-keyslot-size` and `--luks2-metadata-size` when reencrypting,
checked against `--reduce-device-size` and computed based on the
existing header if any?
> Thank you for your feedback!
You're welcome.
--
yexie
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
