#372 Suggest upgrading KDF (Key Derivation Function) for encrypted drives
Closed: Won't fix 10 months ago by otaylor. Opened 11 months ago by maureece.

It is non-trivial for technically inexperienced users to:
1. Know that a memory-weak KDF like PBKDF2 is creating an exposure risk for the content of their encrypted drives,
2. Find out what KDF is used on their encrypted drives and
3. Upgrade to a memory-strong KDF like Argon2.

Fedora as a responsible user agent should:
1. Inform users in case a memory-weak KDF like PBKDF2 is used on an encrypted drive by showing an appropriate warning message and
2. Provide an easy upgrade path to Argon2 without placing user data at risk.


@chrismurphy any comments here?

From a user experience perspective, my question would be - which app would be responsible for presenting this information and allowing the user to fix the issue? Disks might be the obvious choice.

We discussed this some at the meeting today, and it definitely sounds like a good idea to have this in Fedora, but not very simple to do.

The difficulty here is that Fedora doesn't do off-line upgrades via booting a separate media - the upgrade environment runs after the system has already been unlocked. So this isn't a step we can make part of the upgrade environment.

So, it would need to be done inside the initramfs - something like after we prompt for password, instead of running cryptSetup luksOpen, we run a script that checks for the need for an upgrade, upgrades if necesssary, and then does the cryptSetup luksOpen.

Questions might include:

  • Can we just go ahead and do this without asking the user?
  • Matthew Garrett in his blog shows using cryptsetup luksHeaderBackup first. This seems difficult when upgrading from the initramfs. How necessary is that actually?
  • Details of how the passphrase is handled. (If we need to upgrade, we write it to a --key-file on tmpfs or something, but use current stdin handling otherwise?)

Next step is that @chrismurphy and @ngompa will reach out to Fedora cryptsetup maintainers to see what their thoughts and concerns are.

Metadata Update from @catanzaro:
- Issue assigned to chrismurphy
- Issue tagged with: pending-action

10 months ago

OK I see that LUKS2 by default (Fedora 30) predates Btrfs by default (Fedora 33).

Would we convert arbitrary layouts? Or would we somehow test for certain configurations an dlayouts, and constrain the conversion only to a subset we recognize? The default layout at the time would have been a single large partition formatted LUKS, with LVM, three LVM LV's: ext4 /, ext4 /home, and swap. But it's likely there are other configurations out there including multiple device LVM and Btrfs (pooling a.k.a. concatenation), and RAID.

Another possible conversion is for LUKS2 partitions using Argon2i PBKDF, rather than the current Argon2id algorithm.

@mbroz

Do you have an opinion on what we should or shouldn't do for a non-interactive approach to converting LUKS1 to LUKS2 for Fedora users during system upgrade? Or should this just be a case of reprovision? Can it be done in a fail safe manner? The obvious single downside is if there's even a small chance of data loss.

For LUKS1->LUKS2 convert:

Automatic conversion is a very bad idea. DO NOT do it.

I can imagine this for security-enabled distros (like Tails) but not for a generic distro.

First, there is nothing wrong with LUKS1 and PBKDF2. The whole article is overreaction (read https://dys2p.com/en/2023-05-luks-security.html).

If you have a strong password, PBKDF2 still does its job.

If you read the manual page for cryptsetup-convert, you can see this warning:

WARNING: The convert action can destroy the LUKS header in the case of a crash during conversion or if a media error occurs. Always create a header backup before performing this operation!

IOW, you should make a header backup. The convert operation is not (and cannot be) an atomic step.
Data will be lost if something fails (like a temporary medium error) during the update.
And automatic backup of the LUKS header is an incredibly stupid idea, as it allows opening the device even if you change the password afterward (the user must control where to store it and/or destroy it later).

Also, the conversion cannot be done with the LUKS device activated (because kernel dm-crypt device UUID cannot be changed, and we use LUKS version as a prefix).
A restricted environment like initramfs can cause degradation of Argon2 parameters (some distros used libargon with threads disabled in boot systems; this is not the case for Fedora, but I know how complicated it can be to do anything in the dracut environment).

For LUKS2 keyslot upgrade if it uses PBKDF2:

The problem is that some users use PBKDF2 intentionally - either because they need to activate it in memory-constrained systems, need compatibility with old systems, or just need to use FIPS-compliant systems (Argon2 is not FIPS approved algorithm yet - in FIPS mode PBKDF2 is the default KDF).

And for upgrading Argon2i to Argon2id - this is utter nonsense. Matthew made a mistake in the post mentioning that Argon2i is problematic (later corrected it).
Argon2i is a data-independent version (avoiding side channels), in fact, I would prefer it as default. But once RFC 9106 (Argon2 spec) made Argon2id the only mandatory algorithm, we switched to it too.
I do not see a reason to update Argon2i to Argon2id (we use a minimal iteration set to 4, so some old attacks do not apply here).

Just document how to upgrade LUKS or a keyslot and let people decide.

Thanks very much for providing this guidance.

We discussed this issue again during today's WG meeting. @otaylor will provide a summary.

Hi @mbroz. Thanks for the detailed response!

I don't fully agree with some of your premises here:

First, there is nothing wrong with LUKS1 and PBKDF2. The whole article is overreaction (read https://dys2p.com/en/2023-05-luks-security.html).

If you have a strong password, PBKDF2 still does its job.

I'm pretty sure many Fedora users with full disk encryption do not have a passphrase that would count as a "strong password" in this sense.

Just document how to upgrade LUKS or a keyslot and let people decide.

I can also say with some degree of confidence that most Fedora users will not find an entry in the release notes documenting a scary-looking manual procedure and proceed to do it.

WARNING: The convert action can destroy the LUKS header in the case of a crash during conversion or if a media error occurs. Always create a header backup before performing this operation!

Just because there's a chance of data loss without a backup doesn't mean that we shouldn't proceed without a backup - there's some equation involving:

  • Percentage of users that will upgrade if the process is automated
  • Percentage of users that will upgrade if the process is manual and requires a backup step
  • Chance of power loss/crash/media error during an automated upgrade
  • Harm from irrevocable loss of data on Fedora partitions
  • Chance that user's hard drive encryption will be attacked by a GPU
  • Chance they have a "weak" passphrase
  • Harm from exposure of their data

That would determine that :-)

But all that being said, this is clearly something that we can't proceed on without your buy-in, so I'm going to close this as won't fix.

Let's hope that the users with the most sensitive data will be using strong passwords.

Metadata Update from @otaylor:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

10 months ago

Metadata Update from @catanzaro:
- Issue untagged with: pending-action

5 months ago

Login to comment on this ticket.

Metadata