Re: AF_ALG deprecation fallout

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Jul 08, 2026 at 04:14:04AM +0200, Christoph Anton Mitterer wrote:
> Hey Eric.
> 
> Thanks for your fast reply :-)
> 
> On Tue, 2026-07-07 at 18:11 -0700, Eric Biggers wrote:
> > In 7.3 we'll indeed be introducing an algorithm allowlist for AF_ALG.
> > But I already proposed including "xts(serpent)", "xts(twofish)", and
> > "xts(camellia)" on it
> > (
> > https://lore.kernel.org/linux-crypto/20260705184419.40762-1-ebiggers@k
> > ernel.org/)
> > based on their mention in various online documentation for
> > cryptsetup,
> > which suggests they indeed likely have some (rare) real-world use.
> 
> Good :-)
> 
> 
> 
> > I'm interested in allowing any other algorithms that still have
> > real-world use via AF_ALG, if any exist.  If you're aware of any,
> > please
> > speak up.
> 
> [X]Chacha, IIRC, would anyway be used without XTS...

It's possible that some of the "aead" ciphers will need to continue to
be supported in AF_ALG too (in addition to privileged use of "ccm(aes)",
which already is on the list since bluez uses it).

But we need a specific list.

> Well, I personally don't use any others, but of course other might.
> What about all these legacy modes that were used for years in examples,
> like cast5-cbc-essiv, aes-cbc-essiv, etc.?

First, the essiv component is not relevant, as far as I can tell.
algif_skcipher actually does have essiv support, but it's a relatively
recent addition and cryptsetup doesn't use it.

So the potential AF_ALG uses there would be "cbc(cast5)" and "cbc(aes)".

> Does your list have any effects on things like chained algos (which I
> think cryptsetup allows to use for tcrypt).

AF_ALG has never supported cipher cascades itself.

> I've wrote just before on the cryptsetup mailing list, that we have the
> nice integrity support in cryptsetup for quite some years now, but I
> guess only few people actually use it because all the available
> algorithms/modes were kinda recommended against[0].
> 
> I think XChacha20+Poly1305 might be in reach (but still not actually
> usable?), having finally a large enough nonce (192bits?).

The kernel has had XChaCha20Poly1305 support internally since 2019, but
support for it hasn't been added to dm-crypt yet.

> So any chances that the kernel provides a usable AEAD mode for AES (or
> maybe even Serpent ;-P)? 
> 
> Like with GCM but a larger nonce?

We probably should add XAES-256-GCM support at some point, which takes
192-bit nonces.  Historically it hasn't been feasible to do anything
that uses per-request AES keys in the kernel, since the kernel's crypto
API wasn't designed for that.  But we're now moving to a simpler API
where the algorithms including AES-GCM are implemented using regular
functions.  We can build XAES-256-GCM support on top of that.

- Eric