Cryptsetup development
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: Christoph Anton Mitterer <calestyo@scientia.org>,
	cryptsetup development <cryptsetup@lists.linux.dev>
Subject: Re: cryptsetup 2.8.7-rc1
Date: Tue, 30 Jun 2026 07:46:22 +0200	[thread overview]
Message-ID: <dac6de42-1409-477b-ae57-5766c28b5c22@gmail.com> (raw)
In-Reply-To: <7989d6080792b67d7fac3ac9db863e280376a9e5.camel@scientia.org>

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


      reply	other threads:[~2026-06-30  5:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 20:32 [ANNOUNCE] cryptsetup 2.8.7-rc1 Milan Broz
2026-06-29 21:43 ` Christoph Anton Mitterer
2026-06-30  5:46   ` Milan Broz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dac6de42-1409-477b-ae57-5766c28b5c22@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=calestyo@scientia.org \
    --cc=cryptsetup@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox