Reencrypt process questions

Yexie2Fe <yexie2Fe-g/[email protected]>
Newsgroups gmane.linux.kernel.device-mapper.dm-crypt
Message-ID <VQzJMuDkN2eRdmvqePRAHCN8CStEk_n7FopZhllwtjTLYidETKLZ1RGtPlEXAgxh13sDPEOhWuZirxbB1c9YtIlPYdzdwvu70cfk5TJsbZY=@protonmail.ch>
Hi,

After going through the process of reencrypting a non-encrypted disk and
an old LUKS1 volume, I have a couple of questions.

I noticed that the digest iteration count is set to the fixed value of
1000 (cryptsetup 2.2.1 / LUKS2). With a regular luksFormat (or even a
first reencrypt of a non-encrypted disk), it is properly computed from
the key-derivation "benchmark". The FAQ mentions that the "MK iterations
are not very security relevant".

- What is the purpose of these iterations?
- Why are they defined in this fashion (computed vs fixed value when
  reencrypting)?
- Is there an option similar to `--pbkdf-force-iterations` to define
  this value manually?

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.

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.

Best regards,

--
yexie
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.