AF_ALG deprecation fallout

Hey folks.

While I've had read already earlier about AF_ALG's deprecation plans, only when the recent cryptsetup 2.8.7-rc1 came out, it occurred to me that I'm actually be affected by it.

In particular, the release notes mention[0] that along with AF_ALG's looming removal, support for some ciphers will probably also disappear, mentioning Serpent and Twofish as examples.

Now these two, I do use for long term backups... so it would really be quite unfortunate, if sooner or later I couldn't use them with dm-crypt anymore.
In particular, I use them stacked with AES, it's not really just a matter of switching to that. And yes I do know that this is most likely crypto-overkill. O:-)

Also, I can imagine that others may use these or other possibly disappearing as well, even though admittedly a majority will simply use AES.

It's not that I'd oppose clean-ups respectively phasing out unused stuff (I mean things like i486 or ancient graphics card), but at least sometimes one gets the impression that when such deprecation is started, devs ask around at the developer mailing lists whether anyone still uses that, and when no one raises his hands they go on.

But the majority of users most likely never saw that inquiry, only noticing that some feature they're using is gone, when such kernel actually lands in their system - which may be only many years after if has even been removed in the main tree.
Then of course, it's typically far too late to bring anything back.

Now for drivers for ancient hardware, I kinda agree, one cannot keep them forever, especially when most likely no one uses them anymore (with current kernels).
But things like these algos are IMO a bit different, neither of them is broken yet, and even if they were people might still have some old data which they eventually might want to read.

So, here I am, raising my hand, asking whether perhaps anything's already done (cryptsetup's maintainer indicated something) to keep Serpent and Twofish usable for dm-crypt... and, if so, how sure I can be that this will actually be done.

And if not, I'd kindly ask whether it could be considered to have something done, so that dm-crypt can still use them.

Thanks,
Chris.

[0] https://gitlab.com/cryptsetup/cryptsetup/-/blob/5723601af5e5c14ccdf3cda0b13756e3ea1b511b/docs/v2.8.7-rc1-ReleaseNotes#L10-29

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.

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.

  In particular, if you could confirm that the "xts(serpent)" and "xts(twofish)" allowlist entries are necessary and sufficient for you, that would be helpful.

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.

Hey Eric.

Thanks for your fast reply :-)

Quoted 9 lines · Eric Biggers

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

Quoted 4 lines

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

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

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

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

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?

Quoted 1 line · Christoph Anton Mitterer

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

Quoted 3 lines

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

Quoted 2 lines

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.

Quoted 8 lines

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.

Quoted 4 lines

So any chances that the kernel provides a usable AEAD mode for AES (or maybe even Serpent ;-P)?

Quoted 1 line

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.

See my explanation here
https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/420#note_2520172869

Quoted 6 lines

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.

Hey.

Am 9. Juli 2026 12:47:06 MESZ schrieb Milan Broz <[email protected]>:

Quoted 3 lines · Eric Biggers

See my explanation here
https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/420#note_2520172869

Do you strictly need an RFC?

Nevertheless, I've mailed to the author of draft-irtf-cfrg-xchacha whether he has still any plans with it. At least then we'd know if it's worth waiting.

Quoted 7 lines · Eric Biggers

Quoted 1 line · Christoph Anton Mitterer

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

Quoted 1 line

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 6 lines

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

Quoted 2 lines

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

Quoted 6 lines

Quoted 6 lines

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

Quoted 5 lines

Quoted 2 lines

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

Quoted 8 lines · Milan Broz

Quoted 7 lines · Eric Biggers

Quoted 1 line · Christoph Anton Mitterer

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

Quoted 6 lines

Quoted 1 line

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?

Quoted 29 lines

Quoted 9 lines

Quoted 4 lines

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.

Quoted 6 lines

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

Quoted 2 lines

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.

Quoted 3 lines

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?

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.

Quoted 10 lines · 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.

Quoted 3 lines

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.

Quoted 3 lines

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.