Re: AF_ALG deprecation fallout

[Eric Biggers <ebiggers@kernel.org>]

On Sun, Jul 26, 2026 at 01:12:32PM +0200, Richard Weinberger wrote:
> On Mittwoch, 8. Juli 2026 03:11 Eric Biggers wrote:
> > Note that cryptsetup 2.8.7 will further reduce the cases in which it
> > even needs AF_ALG at all.  So just because you are using a particular
> > algorithm doesn't necessarily mean you need it in AF_ALG.
> > 
> > No algorithms have been proposed to be dropped from dm-crypt (which is
> > *not* the same thing as AF_ALG), by the way.  Given that dm-crypt allows
> > some "interesting" algorithms like RC4, DES-ECB, and even the null
> > cipher, I do think we can expect an allowlist for it at some point as
> > well.  But that would be separate.
> > 
> > I'd indeed like to remove AF_ALG entirely eventually.  But that's a long
> > term thing that would be many years from now and would occur only after
> > iwd, bluez, cryptsetup etc. have all fully migrated to userspace crypto.
> 
> Since I got already mails from alerted clients, I'd like to highlight
> one particular use case on (deeply) embedded systems and make sure
> this use case is known.
> 
> On systems with very little space, like a few megabytes of flash,
> utilizing dm-crypt with LUKS can be a challenge. Adding a crypto
> library to userspace (e.g. initramfs) is a huge burden.
> 
> 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?

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.

- Eric