Bug 1185291 - Allow more flexible crypt setup
Allow more flexible crypt setup
Status: NEW
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Installation
Leap 15.2
All Other
: P5 - None : Enhancement (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/YEr2VVgX/3433-en...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-04-26 12:50 UTC by Ulrich Windl
Modified: 2022-02-23 10:14 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2021-04-26 12:50:50 UTC
A new installation from last week (with online repositories active and updated auto-installer) created LUKS version 1 devices, while cryptsetup is able to support LUKS version 2.

It would be nice if users were able to select the version to use.
The users should be able to select among the algorithms available (like aes-xts-plain64, argon2i, pbkdf2, sha256).
Likewise the delay to decrypt the key seems to be 10 seconds or more, and the iterations are not configurable. The should be configurable, however.

When encrypting the boot device on a laptop there is an additional problem that grub asking for the decryption password seems to consume considerable power, not timing out. So if someone opens the lid, the system will try to start (resume), but when the lid is closed again, GRUB will drain the battery.

Maybe there should be a timeout for password entry after which GRUB powers off the system (again).
Comment 1 Ancor Gonzalez Sosa 2021-04-29 08:10:07 UTC
(In reply to Ulrich Windl from comment #0)
> A new installation from last week (with online repositories active and
> updated auto-installer) created LUKS version 1 devices, while cryptsetup is
> able to support LUKS version 2.

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.

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

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

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.

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.

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.
Comment 2 Ulrich Windl 2021-04-29 12:57:44 UTC
(In reply to Ancor Gonzalez Sosa from comment #1)
Can we agree that "huge amounts of memory" defaults to 1GB (1048576 kB) and is configurable via --pbkdf-memory, and that "very big compute time" can be controlled via the "iterations" parameter (--iter-time)?

According to https://www.phoronix.com/scan.php?page=news_item&px=GRUB-Boots-LUKS2-Disk-Encrypt (dated January 2020: "The GRUB boot-loader has finally merged support for dealing with LUKS2 encrypted disks."
Comment 3 Joachim Wagner 2021-08-23 17:06:22 UTC
In Leap 15.3, the default during installation seems to be 2 seconds per device. My workaround on my system with 6 LUKS devices is to manually add new keys with --iter-time 100 (time in milliseconds) and to delete the old key slots.

Feature request: Measure the strength of the user-supplied passphrase(s) and offer the user a few options trading off total time spent opening all LUKS devices against effort expected to be needed to break the passphrase(s). This could be a single slider to set iter-time for all LUKS devices on a logarithmic scale, e.g. from 1 to 600000 (10 minutes), updating the effort estimate for the weakest of all provided passphrases. With very strong passphrases it can be expected that 1ms iter-time is already providing excellent security and the default could then be set such that the total time spent in luksOpen is about a second. Having a component in yast that can measure password strength would also be handy in other places, e.g. creation of user accounts.
Comment 4 Ulrich Windl 2021-08-24 07:32:28 UTC
(In reply to Joachim Wagner from comment #3)
> In Leap 15.3, the default during installation seems to be 2 seconds per
> device. My workaround on my system with 6 LUKS devices is to manually add

I also noticed that there seems to be a huge speed difference between GRUB opening a crypt device and the kernel doing that (GRUB is significantly slower).
Here for an AMD Ryzen 4700 it feels like taking 30 seconds to open the crypt device, and it feels like the kernel needs at least 5 seconds or so.

I don't know if there is reliable timing information, but from "systemd-analyze blame" I got:
19.609s systemd-cryptsetup@cr\x2dhome.service                                  >
(slowest of all)
 9.937s systemd-cryptsetup@cr\x2dsys\x2d1.service                              >
 8.483s systemd-cryptsetup@cr\x2dswap\x2d1.service                             >

...
> Feature request: Measure the strength of the user-supplied passphrase(s) and
> offer the user a few options trading off total time spent opening all LUKS
> devices against effort expected to be needed to break the passphrase(s).

Does the strength of the passphrase have an effect on opening time actually?

...

I think it's important to allow half-way reasonable defaults while documenting how to change things later (after installation, maybe in security guide).

> This could be a single slider to set iter-time for all LUKS devices on a
> logarithmic scale, e.g. from 1 to 600000 (10 minutes), updating the effort
> estimate for the weakest of all provided passphrases. With very strong

Salting (in whatever shape) a weak password does not make the password any better; it just tried to make brute-force guessing slower.
But I think that discussion leads off-topic.

> passphrases it can be expected that 1ms iter-time is already providing
> excellent security and the default could then be set such that the total
> time spent in luksOpen is about a second. Having a component in yast that
> can measure password strength would also be handy in other places, e.g.
> creation of user accounts.

The thing with "password strength" is that it cannot be measured, actually: "AAAAAAAA" if picked truly randomly would be as good ad any other 8-character password, but people do not pick passwords randomly (so the likelihood of different passwords vary significantly). So effectively you would exclude all the passwords that do not look random. But as "random" can be anything, it's hard to tell. Maybe the only rule that remains is: "Don't use a password that is being used more frequently as the likelihood would be"
(For the 8 character example (assuming letters and digits) the likelihood of the sample shown would be 1/218340105584896 (1/62^8))