Hi, I let Ondra reply to the reencrypt questions, but few notes below On 30/09/2019 22:51, Yexie2Fe wrote: > 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? It is just additional countermeasure if some issue with RNG is found later. Attacking volume key directly should be infeasible through brute force, so attacking salted digest of it is even worse. Moreover, an attacker will perhaps use some known plaintext (fs signature), not attacking digest. IOW you can run one block cipher decryption of one particular sector with the known signature and check for validity of decrypted plaintext instead of running full volume key digest check. Anyway, I kept the digest the same as in LUKS1. > - Why are they defined in this fashion (computed vs fixed value when > reencrypting)? It should not be fixed value, digest iterations should be benchmarked (the same as in LUKS1). Onlyy if you require too low iteration time, the minimum (1000) is used. What parameters were used for the reencryption command? There is one exception - if you use --pbkdf-force-iterations for the keyslot iterations, the minimum iteration for digest is used (to avoid benchmark run in automated setups). > - Is there an option similar to `--pbkdf-force-iterations` to define > this value manually? No, I am not sure we really need it. Maybe we need to always just run PBKDF2 benchmark for a new digest (and possible add generic "disable benchmark" switch). Dunno. > > 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. We can do it with luksConvertKey already. (Ondra can provide details here.) Milan > 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 > dm-crypt@xxxxxxxx > https://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
