Re: cryptsetup 2.8.7-rc1

Milan Broz <[email protected]> Tue, 30 Jun 2026 07:46:22 +0200
Newsgroups dev.linux.lists.cryptsetup
Message-ID <[email protected]>
On 6/29/26 11:43 PM, Christoph Anton Mitterer wrote:
> Hey.
> 
> On Mon, 2026-06-29 at 22:32 +0200, Milan Broz wrote:
>>   Also, ciphers like Serpent or
>>     Twofish (in XTS mode) are missing from several userspace
>> libraries.
> 
> Uff... bummer. I use both in some special cases.
> 
> 
> Uhm, can I somehow verify this in advance (ideally by actually
> testing)?

You can try to disable kernel af_alg module.

There is an ongoing effort to provide "crippled" af_alg, but I do no think
it is a quite sensible approach. But if it lands in kernel, we adapt to it.

The interface cannot be completely removed (I hope the promise to not
break userspace still holds). Anyway, AF_ALG s is already marked as deprecated.
I am sure kernel people underestimated how many people using it.
Anyway, I gave up discussions in kernel lists, it is still a very toxic environment.

The whole point of this exercise was to prepare for people disabling AF_ALG themselves.
We had already fallback, so it is used for everything now.

> I'm using Debian's cryptsetup packages, which (AFAICS) use OpenSSL as
> backend, which (AFAICS) supports neither serpent, nor twofish.

> Are there any alternatives to keep those running?

Depend how you use it, but if it is for LUKS, we can now fallback to old
temporary dm-crypt mapping even for LUKS2, you just need to be root.

For OpenSSL, it can be extended by providers and it should not be too complicated
to write provider for Twofish and Serpent.
Even Camellia does not support XTS, but that should be fixed inside OpenSSL.

Libgcrypt backend should support all of these, but definitely we do not want to switch
to it by default.

Milan