Re: AF_ALG deprecation fallout

On Sonntag, 26. Juli 2026 17:37 Eric Biggers wrote:
> > cryptsetup's --with-crypto_backend=kernel helps a lot here.
> > So, by completely removing AF_ALG these systems would unnecessarily
> > suffer. Please keep both AF_ALG and --with-crypto_backend=kernel around.
> 
> I assume the key on these systems tends not to come from user input
> (such as a passphrase).  So do you know why cryptsetup and LUKS is being
> used at all, instead of just using dm-crypt directly?

LUKS is not only about passphrases, you can also pass key files.

It's also convenient to store other meta data in the LUKS header,
especially in combination with a TPM chip.
We commonly use the same format as systemd-cryptenroll does.

Having LUKS has also the benefit of having a clear indication whether the key
is correct or not.
In contrast to a mount failure where the super block contains garbage.
 
> Even if LUKS is used, it should be feasible to implement with neither
> AF_ALG nor an external userspace crypto library, saving space over your
> requested solution which bloats the kernel with AF_ALG.  Indeed, in
> cryptsetup, LUKS keyslot en/decryption already falls back to a temporary
> dm-crypt mapping; see lib/utils_storage_wrappers.c.  I understand this
> wasn't done consistently in old versions, but in v2.8.7 it is.
> 
> For key derivation, assuming the LUKS2 defaults are used, cryptsetup
> already has built-in Argon2 code, including an implementation of the
> BLAKE2b hash function; see lib/crypto_backend/argon2/blake2/.
> 
> So it seems the only missing piece for LUKS is actually the metadata
> checksums.  (I'll assume that 'cryptsetup benchmark' and support for
> formatting a file in LUKS format as non-root users aren't needed here;
> those seem to be for testing purposes.)  For LUKS2 that's SHA-256.
> Built-in SHA-256 could be added to cryptsetup; this would be much
> smaller than the code for AF_ALG.  Alternatively, for new volumes,
> support for configuring these to use BLAKE2b could be added, simply
> reusing the BLAKE2b code that is already built-in for key derivation...
> 
> So it seems quite feasible.  But I strongly suspect that direct use of
> dm-crypt would be a better solution for these systems, which would
> eliminate the need for cryptsetup entirely.

If cryptsetup can offer itself everything to open a LUKS volume without the need
of an external crypto library, I'm more than happy.

My main goal is avoiding disasters after a kernel upgrade.
We at $dayjob we help to maintain systems with support times of 20 years and more,
kernels are regularly upgraded. So, regressions do hurt.

Thanks,
//richard