Re: AF_ALG deprecation fallout

[Milan Broz <gmazyland@gmail.com>]

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.

However, it would be nice to have simple API to check (usable by normal user)
if kernel supports some cipher/mode/keysize/... without trigerring module load
(as AF_ALG does).


>> 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

There is also very old support for DES3_EDE and Blowfish, these need some tricks,
I would ignore them.

See cryptsetup lib/tcrypt/tcrypt.c for details.


> 
>> 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

> 
>> 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.

That would be nice.

Milan