>> I think diverging from upstream (and other distros) with respect to >> default algorithms requires careful consideration. And in that case, >> compared to PBKDF2 Argon2 has interesting properties (such as resistance >> to GPU cracking) which would be a shame not to benefit from out of the >> box.
For this case you need to specify PBKDF parameters directly and skip benchmark (these PBKDF options were added exactly for this use case). This problem is there even with PBKDF2 for the iterations time - on some IoT devices with LUKS device (formatted on developer's machine) the unlocking time increases to many minutes. (With Argon PBKDF it is just worse because memory can be unavailable.) So the suggestion above is correct - you need to measure some viable parameters and use them directly. If you run luksFormat on a small IoT system directly, it trims parameters and memory use according to system (it will never use more than half of physical available memory). ... > I guess dracut with systemd in the initrd might be affected worse, > than initramfs-tools. I wonder if I should open a bug report in > systemd, to potentially execute luks2 unlock with some locking / > sequentially. FYI we know about that parallel unlocking problem already and we are trying to find (with systemd people) some solution (perhaps based on cgroups memory limits and some locking). (Parallel unlocking can cause OOM killer to kill even different processes here.) You can change PBKDF parameters for existing device (preserving data) with cryptsetup luksConvertKey command, it takes the same PBKDF options. (So you can "downgrade" to PBKDF2 or decrease limits.) Milan
