cryptsetup built with argon2 as the default key derivation function instead of PBKDF2

To provide more context in terms of business need. We use cryptsetup for full disk encryption, and cryptsetup correctly delegates its cryptography to other components such as openssl and kernel. However for key derivation cryptsetup switched to argon in 18.04 via a 3rd party library, and as this is not a FIPS validated library (as well as the algorithm is prohibited), the problem starts.

To comply with the regulations we need to be offering PBKDF by default because disk encryption currently is done at the installer that is not aware of the FIPS mode. It may be possible for the user to override, and cryptsetup should continue to be able to decrypt old volumes that use argon2 of course.

The ideal state is that in FIPS mode, cryptsetup should not allow to create a new volume with argon2, though it should be able to use it (see here about detecting fips mode https://ubuntu.com/security/certifications/docs/fips-devel).

Note that there is an --enable-fips flag that may be helpful towards that goal, though I haven't verified.

One thing I noticed that the fips validation done in the package is for the RHEL fips mode. To convert it to ubuntu one would need to remove a check:

diff --git a/lib/utils_fips.c b/lib/utils_fips.c
index 640ff0e3..e52da51d 100644
--- a/lib/utils_fips.c
+++ b/lib/utils_fips.c
@@ -47,7 +47,7 @@ bool crypt_fips_mode(void)
        if (fips_checked)
                return fips_mode;

- fips_mode = kernel_fips_mode() && !access("/etc/system-fips", F_OK);
+ fips_mode = kernel_fips_mode();
        fips_checked = true;

        return fips_mode;

Crypto defaults in Ubuntu should always be driven by our understanding of what is the most secure solution for our users; it should not be driven by certification standards, FIPS or otherwise. We should support FIPS compliance for encrypted volumes, but support for that should be orthogonal to the cryptsetup defaults on a system not in FIPS mode.

It sounds like cryptsetup upstream already has support for FIPS-compatible selection (and certainly, PBKDF algorithm selection is selectable from the cryptsetup commandline at LUKS container creation time), we just want to make sure FIPS mode is functional on Ubuntu. For full-disk encryption driven from the installer, because the installer does not use the FIPS kernel and therefore cryptsetup behavior will not automatically be FIPS-compliant, we would need some way to say we want the system to be FIPS-compatible post-install. This should probably be a simple toggle saying that you want FIPS mode, which would drive the options when invoking cryptsetup but could be extended later to handle other things (such as ua enablement, installing from the fips package repository, etc). I expect that should go through a process with the Design Team.

I do not disagree that ubuntu security decisions are not driven by a national standard but it should also be consistent technically in a way that we do not need to be maintaining multiple versions of packages or multiple interfaces and knobs.

PBKDF2 is an algorithm with reasonable security properties, compatible with FIPS, and has configurable security level. Argon2 is the latest and greatest but it is not compatible with our FIPS offering, and pulls in main additional crypto libraries, putting us in a position of risk. If our switch from argon2 as default to pbkdf2 would reduce the security of Ubuntu, I do not think we should be considering it, but I do not believe that this is the case.

Once we have the fips knobs in place on the installer, we can reevaluate but for 18.04 and 20.04 treating this as a bug in my view is the right thing to do, because there are no such knobs.

On Tue, Nov 02, 2021 at 12:32:10PM -0000, Nikos Mavrogiannopoulos wrote:
> I do not disagree that ubuntu security decisions are not driven by a
> national standard but it should also be consistent technically in a way
> that we do not need to be maintaining multiple versions of packages or
> multiple interfaces and knobs.

> PBKDF2 is an algorithm with reasonable security properties, compatible
> with FIPS, and has configurable security level. Argon2 is the latest and
> greatest but it is not compatible with our FIPS offering, and pulls in
> main additional crypto libraries, putting us in a position of risk. If
> our switch from argon2 as default to pbkdf2 would reduce the security of
> Ubuntu, I do not think we should be considering it, but I do not believe
> that this is the case.

Ok, if it's your position that PBKDF2 is as secure as argon2 and is an
appropriate, secure default for Ubuntu, then we can consider this change on
that basis, thanks.

However, I am not qualified to assess this claim; I think we need the
Security Team to weigh in on the question of suitability as a default
algorithm, including any questions of how it should be configured (since
"configurable security level" is only of relevance if you have an
opportunity to configure it).

BTW, cryptsetup depending on argon2 doesn't increase our exposure, because
there are other packages in main which also depend on it (openldap and php).

Argon2 is a genuinely memory hard algorithm - when processing each block of memory, its indexing function can select any other block of memory to feed into its compression function, so you can't run the derivation iteratively in a small amount of memory. If the algorithm is tuned to require 1GiB of memory, then you need 1GiB to run the key derivation. This reduces the feasability and increases the cost of brute force attacks on dedicated hardware such as FPGAs which might have small amounts of fast memory.

AFAICT, PBKDF2 doesn't have the memory hardness properties of Argon2. It's executed in a small amount of memory with the number of iterations being the only tunable parameter to increase its cost.

I'd be strongly opposed to changing the default in the distro from Argon2 to PBKDF2.

Cryptsetup can disable the use of Argon2 automatically in FIPS mode, as long as cryptsetup is built with --enable-fips, which I don't think is the case right now.