AF_ALG deprecation fallout

AF_ALG deprecation fallout

[Christoph Anton Mitterer]

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

Re: AF_ALG deprecation fallout

[Eric Biggers]

[+Cc Milan Broz]

On Wed, Jul 08, 2026 at 02:31:05AM +0200, Christoph Anton Mitterer wrote:
> 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

I think the cryptsetup release notes may have given you a slightly wrong
impression.  So far the only things that have been removed from AF_ALG
are zero-copy and async execution support, which have zero impact on
cryptsetup.  There are indeed more people turning off AF_ALG in their
kernels now; however, general-purpose distros aren't doing that.

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

- Eric

Re: AF_ALG deprecation fallout

[Christoph Anton Mitterer]

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

Re: AF_ALG deprecation fallout

[Eric Biggers]

On Wed, Jul 08, 2026 at 04:14:04AM +0200, Christoph Anton Mitterer wrote:
> 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...

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.

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

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

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

- Eric

Re: AF_ALG deprecation fallout

[Milan Broz]

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

Re: AF_ALG deprecation fallout

[Christoph Anton Mitterer]

Hey.

Am 9. Juli 2026 12:47:06 MESZ schrieb Milan Broz <gmazyland@gmail.com>:
>On 7/8/26 5:01 AM, Eric Biggers wrote:
>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.


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

Indeed. Would be great if that could come in the foreseeable future... in particular with the uncertain future of XChaha.

Also, blindly assuming that so far people mostly used integrity support in dm-crypt for testing and not production (due to the algos), it might take a while until enough trust[0] has built up for seeing broad use.


I guess it might also help end users if cryptsetup might give recommendations on which algo to use for what (like most secure vs. secure enough but better performance, or so).

With non AEAD, this had been rather easy, and aes-xts-plain64 with 256 bit keys was simply like the gold standard.


Cheers,
Chris.


[0] Not that I'd think the contributing developers weren't capable,... but you know... if one puts all precious data in it (including for backups), one doesn't want any surprises.

Re: AF_ALG deprecation fallout

[Eric Biggers]

On Thu, Jul 09, 2026 at 02:38:50PM +0200, Christoph Anton Mitterer wrote:
> Hey.
> 
> Am 9. Juli 2026 12:47:06 MESZ schrieb Milan Broz <gmazyland@gmail.com>:
> >On 7/8/26 5:01 AM, Eric Biggers wrote:
> >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.

XChaCha is seeing significant use in practice, both in the kernel
already and in the broader community.  It is secure if ChaCha is secure.
An RFC would be nice but I would not consider it necessary.

- Eric

Re: AF_ALG deprecation fallout

[Eric Biggers]

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

Re: AF_ALG deprecation fallout

[Milan Broz]

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