https://bugzilla.suse.com/show_bug.cgi?id=1185291 https://bugzilla.suse.com/show_bug.cgi?id=1185291#c8 --- Comment #8 from Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> --- (In reply to Ancor Gonzalez Sosa from comment #1)

Offering LUKS2 comes with some challenges.

By default, LUKS2 uses an algorithm with a very big compute time and that consumes huge amounts of memory to derive the key (by design, it floods the memory as a protection feature). Moreover, the algorithm does not allow to specify a limit to the amount of memory able to be used.

According to the manual page you could still use PBKDF with LUKS2 format (with the option to add a key slot using something more modern). Still the challenge might be whether GRUB2 can decrypt that.

That's quite a problem during installation if there is no swap space, which is the most common scenario since swap is only created after the partitioning and encryption is done (and likely the user wants to encrypt the swap itself resulting in a chicken-egg problem).

Would it be a problem for a machine that has 2GB RAM "only"? (I doubt that there are PCs in use with less than 8GB of RAM today) Still there could be an option saying "for device encryption using algorithm X, you need at least Y GB of RAM".

We could workaround that problem by using PBKDF2 as algorithm (which is the less memory hungry alternative). But that would to a certain extent defeat the purpose of using LUKS2. We consulted with the SUSE security team and they told us: "PBKDF2 really isn't particularly good. Without having looked into the cryptanalysis of Argon2, I'd say it's always better than PBKDF2, even when memory requirements are dialed all the way down."

Independent of the algorithm being used, LIKS2 seems to be more flexible than LUKS1 was, and most of all, it seems tricky to impossible to upgrade an existing container.

So, as you can see, offering all the reasonable options during installation in a way that makes sense (ie. being fully understandable), that is deterministic enough and that still makes the installation possible in a wide range of hardware is quite a challenge. It wouldn't be nice if we run out of memory in the most critical part of the installation process.

Well, the machine I had originally reported the issue had 16GB of RAM; for the recent case the machine had 96GB RAM. Running out of memory during installation should be controllable (e.g. run cryptsetup in a memory-restricted cgroup; then it either succeeds, or it fails), or monitorable at least.

As a cherry on top, Grub2 currently does not support LUKS2 (unless without patches) so we would need a separate /boot partition in many cases, which doesn't play well with btrfs snapshots of the system.

We are talking about a GRUB newer than grub2-2.06-150500.29.31.1.x86_64, right? That should support LUKS2 (with PBKDF2) since 2021.

In other words, we want to go there. But it still will need time and a lot of decision making. I wouldn't expect it for 15.4, but who knows.

With "all-in-one" BtrFS filesystem that may be actually hard, but with an unencrypted /boot that should work. Someone also suggested that an unified UEFI boot image may solve this (my newer laptop doesn't support legacy (MBR) boot anyway). -- You are receiving this mail because: You are on the CC list for the bug.