[pkg-cryptsetup-devel] Bug#924560: Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Milan Broz]

>> 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