Re: AF_ALG deprecation fallout

[Milan Broz <gmazyland@gmail.com>]

On 7/9/26 5:35 PM, Eric Biggers wrote:
> 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?

AEAD cannot be used for LUKS keyslot encryption. Decrypted key is validated
against external digest.

If you use AEAD for data, keyslot encryption will fallback to aes-xts (or
whatever length-preserving mode user selects at CLI).

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

Well, the whole point was that it does not need root and it was documented as such from the
beginning. So, no. But I am not saying it must to support everything, Veracrypt
removed old modes - but that makes cryptsetup even more useful for legacy containers.

And this is one place where dmcrypt fallback is not supported - but we possibly could add it.
(It is just different API - tcrypt support was written years before, actually I think
it predates most of AF_ALG users including libckapi...)

Milan