Re: AF_ALG deprecation fallout

[Christoph Anton Mitterer <calestyo@scientia.org>]

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

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


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

For me they are. Actually I would want to replace my use of twofish by
something xchacha based (see * below), but I would want to keep xts-
serpent in the long term.


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

I see. Well at least 2.8.6 still needed it for opening a dm-crypt
device that used serpent-xts-plain64.


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

While these cases won't affect me, legacy users should be kept in mind.

Perhaps waiting a few years where opening such dm-crypt mapping merely
gives a warning that this is about to go away, then - if possible - for
a few years allowing read-only mappings.


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

Good to hear that you guys have it already on your radar, that some
people may use these non-AES algos and may want to continue doing so
even in the long term.
So please keep this in mind. :-)


Thanks,
Chris.


* A bit off topic, but since some of the relevant people are already in
CC:

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

Now I'm not a crypt export, so don't really know which of [X]Chacha20
vs. AES256 is considered stronger.
At least AES has probably received far more scrutiny than any other
crypto algo ever.

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?
Or what about EAX, OCB? I blindly assume, that the patents have all
expired, given that OpenPGP now uses them since RFC 9580.


[0] https://gitlab.com/cryptsetup/cryptsetup/-/blob/5723601af5e5c14ccdf3cda0b13756e3ea1b511b/docs/v2.0.0-ReleaseNotes#L259-274