Re: AF_ALG deprecation fallout

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Jul 09, 2026 at 12:47:06PM +0200, Milan Broz wrote:
> On 7/8/26 5:01 AM, Eric Biggers wrote:
> > On Wed, Jul 08, 2026 at 04:14:04AM +0200, Christoph Anton Mitterer wrote:
> > > [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.
> 
> Cryptsetup can use AF_ALG to check if AEAD is supported, but it tries to use
> it later anyway, just error messages are more cryptic (hidden in DM kernel log).
> 
> So we should not depend on AEAD AF_ALG support.

What about the keyslot encryption?

> > > 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.
> 
> TCRYPT (Truecrypt/Veractypt compatible) supports it, but it handles chain in own code,
> calling always only one cipher to decryot.
> For activation it stacks several dm-crypt devices, so no chain in crypto API is needed.
> 
> My intention was to support all, even historic, combinations, because people
> have old containers. (Note, we only support existing container, we cannot create it.)
> 
> Current Veracrypt supports these individual ciphers (and some chains of them),
> that is what we can use through AF_ALG:
> 
> - AES, Serpent, Twofish, Camellia, Kuznyechik (not in mainline only as external
> package, in Debian as gost-crypto-dkms package), all in XTS mode.
> 
> Historic containers (TrueCrypt) can use:
> - AES, Serpent, Twofish in LRW mode
> - AES, Serpent, Twofish, Cast5, in CBC mode

So all of those need to be allowed in AF_ALG (minus Kuznyechik which
doesn't exist in mainline)?  Can we at least make them privileged only?

> > 
> > > 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.
> 
> See my explanation here
> https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/420#note_2520172869

Again, the kernel supports XChaCha20Poly1305 internally since 2019.
WireGuard uses it.  It's just not supported in dm-crypt yet (or AF_ALG
for that matter).

- Eric