Change LUKS KDF to argon2id when upgrading in-place from Qubes 4.1 to 4.2

[no-usernames-left]

The problem you're addressing (if any)

QubesOS 4.1 seems to use argon2i (not argon2id) by default for the LUKS KDF.

It would appear as though argon2i is less resistant to attack by sophisticated adversaries than initially thought (1,2).

The solution you'd like

QubesOS should switch to using argon2id for all new installs, period.

Ideally, existing installs should have their KDF converted at their next QubesOS update (sudo cryptsetup luksConvertKey /dev/whatever --pbkdf argon2id etc).

Ideally, memory cost should be 1024 MiB, ops cost 4, parallelism 1.

The value to a user, and who that user might be

This will help protect all Qubes users against compromise of their data at rest by sophisticated adversaries.

[ldeso]

In my experience this is already the case with Qubes 4.2.

[rustybird]

Yes, R4.2 has a new enough cryptsetup in the installer that defaults to argon2id.

When converting existing installations (manually, or maybe as an addition to qubes-dist-upgrade) just make sure to shut down all VMs first, so as not to end up with an unnecessarily weak low memory configuration for argon2id.

[andrewdavidwong]

Since this is an enhancement request for the installer, and since this is already done for 4.2, this issue will be actionable only if 4.1 gets another patch release, which seems unlikely with 4.2 around the corner.

[rustybird]

Yeah it should probably be about qubes-dist-upgrade rather than the installer

[no-usernames-left]

Yes, R4.2 has a new enough cryptsetup in the installer that defaults to argon2id.

What are the default memory cost, ops cost, and parallelism on 4.2 RC? Perhaps there is still some room for improvement here since the minimum system requirement for Qubes is significant enough to avoid causing problems by using i.e. 1024MiB memory cost.

[marmarek]

During installation you have a lot more RAM available than later during system runtime, because later you have several VMs running that occupy memory. I'd rather avoid situation where you need to shutdown everything just to unlock some partition...

[no-usernames-left]

But this RAM would be needed at boot, before any qube other than dom0 is even running... and once the volume encryption key (well, the KEK, i suppose) is derived from the LUKS passphrase, it's held in RAM until the LUKS device is closed at shutdown and doesn't need to be derived again... no?

If so, it's actually the perfect situation to insist on a RAM-hard KDF.

(My suggestion is only for the default pool; advanced users with multiple pools which may not all be set up at boot can handle those extra pools themselves.)

[marmarek]

Unless you want for example to change the passphrase.

[no-usernames-left]

I mean, sure, but how often do people do that?

Don't underestimate the power (and stickiness) of defaults. Is it really the right choice to weaken the security of every user by watering down the default Argon2 settings just to make sure everyone can rekey LUKS with low free RAM?

[andrewdavidwong]

Is it really the right choice to weaken the security of every user by watering down the default Argon2 settings just to make sure everyone can rekey LUKS with low free RAM?

Isn't this backwards? I was under the impression that you were suggesting strengthening the settings over and above the defaults inherited from upstream. Aren't the current defaults in Qubes 4.2 just the unmodified defaults inherited from upstream?

Anyway, this is all off-topic for this issue. If you believe that Qubes should use stronger settings than the inherited upstream defaults, please open a separate issue for that.

[no-usernames-left]

Isn't this backwards? I was under the impression that you were suggesting strengthening the settings over and above the defaults inherited from upstream.

I am indeed suggesting that. The wording I used was confusing; my apologies.

Aren't the current defaults in Qubes 4.2 just the unmodified defaults inherited from upstream?

I don't know, but they probably shouldn't be given the emphasis on high security in Qubes OS.

[andrewdavidwong]

I am indeed suggesting that. The wording I used was confusing; my apologies.

Ah, I see what you meant. No worries.

I don't know, but they probably shouldn't be given the emphasis on high security in Qubes OS.

But LUKS is also security software, so there should also be an emphasis on high security in LUKS. (If there is not, then we shouldn't use it, and neither should anyone else. And yet, LUKS is the standard.) If LUKS doesn't ship with secure defaults, then a bug report should be submitted to the LUKS devs.

I think it's a mistake to assume that we should reject the upstream defaults of a piece of security software just because we also care about security. The mere fact that they're the defaults doesn't automatically make them insecure or unsuitable for us. The LUKS devs probably know what they're doing and have good reasons for selecting those defaults. We should reject the defaults only if we have specific, well-informed reasons to do so backed by some kind of evidence or expert advice.

For example, if you ask the LUKS devs about this, and they say that certain default parameters were chosen to accommodate less powerful devices and that all devices capable of running Qubes OS will work with more demanding parameters that would provide a real-world security benefit, then we certainly should consider making those more demanding parameters the defaults in Qubes OS. However, for all I know, they might instead say that this is already covered by the default iter-time parameter, which inherently adapts to more powerful hardware, since it's a function of the speed of the machine on which it is run. (This is just an example. I am not a cryptographer and have no idea what the LUKS devs will say. Please don't get caught up in the details of this specific example.)

So, my suggestion would be to try asking the LUKS devs (or, if they're unavailable, perhaps other cryptographers) for their advice and/or gather some relevant evidence. Then, if your findings indicate that it would actually be beneficial to change the default parameters for Qubes OS (e.g., there will be a real-world security gain that won't break things for any Qubes users), open an issue presenting your findings and requesting specific parameter changes.

[no-usernames-left]

So, my suggestion would be to try asking the LUKS devs (or, if they're unavailable, perhaps other cryptographers) for their advice and/or gather some relevant evidence.

I included the advice of a well-respected cryptographer in my initial message: https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-cryptography-with-passwords/#recommendations

If you’re deriving an encryption key from a password, use any of the following algorithms:

• scrypt with N = 1048576, r = 8, p = 1 and a random salt at least 128 bits in length (256 preferred)
• Argon2id with a memory cost of 1024 MiB, ops cost of 4, and parallelism of 1

In fact, you absolutely nailed it:

if you ask the LUKS devs about this, and they say that certain default parameters were chosen to accommodate less powerful devices and that all devices capable of running Qubes OS will work with more demanding parameters that would provide a real-world security benefit

Yes, that's exactly what I am saying, and it's obvious to me as a security professional even though I'm not a cryptographer -- but @Soatok is a cryptographer with a known and proven track record, and they're saying the same thing. Qubes has significant system requirements so there is no need to run with the upstream defaults (which, as you state, are chosen to be usable on all sorts of gear) given that Qubes users are typically higher-value targets than the average population and therefore we should adjust our defaults accordingly.

[andrewdavidwong]

@no-usernames-left: Okay, then please open a separate issue with for this. (This issue is only about changing the KDF for in-place upgrades from 4.1 to 4.2, whereas changing the default Argon2id parameters will also affect fresh 4.2 installations, for example.)

[no-usernames-left]

You're right! #8600 opened.

[andrewdavidwong]

@no-usernames-left: No, you've misunderstood. There are two logically separate things here:

1. Changing the KDF to Argon2id.
2. Changing the Argon2id parameters.

This issue is about (1), because Qubes 4.1 and Qubes 4.2 use different KDFs by default, because they use different LUKS versions by default. Someone who upgrades in-place from Qubes 4.1 to 4.2 will still have the old KDF (unless this issue is completed).

The other issue you just opened (#8600) is about (2), because changing the Argon2id parameters is applicable only when the KDF is Argon2id. Issue #8600 could also include changing the Argon2id parameters in the case of in-place upgrades, but that's impossible until this issue is completed, because you can't turn the knobs until the knobs exist to be turned.

[no-usernames-left]

I understand that there are two separate issues here -- my point is that if the decision is made to change the KDF for existing installs at update time, then we should also line up with current expert recommendation given the points I've raised.

I see that you have adapted #8600 to cover both scenarios, which is fine by me, in which case indeed this should stay simply as "let's change the KDF for existing installs" and that's that.