Re: cryptsetup 2.8.7-rc1

Hey Milan.


On Tue, 2026-06-30 at 07:46 +0200, Milan Broz wrote:
> 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.

Do you by chance have any idea whether this would help with respect to
Serpent and Twofish?


> The interface cannot be completely removed (I hope the promise to not
> break userspace still holds).

Well, removing these algos would already kinda do so, wouldn't it? I
mean I can understand if things shall be cleaned up and if for example
drivers for decade old hardware is removed, but these alogs aren't
broken or completely outdated.


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

FYI, I've posted[0] to linux-crypto, bringing up the concern of "lost"
algorithms and that this may actually affect users.

So let's hope for some hopefully positive input from there.


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

You mean cryptsetup has a fallback?

At least when I blacklist af_alg before, opening a dm-crypt device with
serpent-xts-plain64 failed (as expected).


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

This I don't quite understand, I'm afraid.

I do use it with LUKS, so should Serpent/Twofish still continue the
work then, I mean even if AF_ALG were to be removed completely?


> For OpenSSL, it can be extended by providers and it should not be too
> complicated
> to write provider for Twofish and Serpent.

Maybe not for a crypto expert and cryptsetup maintainer... ;-P

And while I might be able to hack something together, I'm not really
a=C2=A0crypto developer, and given the nature of the subject, it feels
rather stupid trying to do so - a home-brew provider might look as if
it would work, but still have security flaws.


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

Well and I wouldn't want to deviate from Debian's packaging anyway...=20


Unrelated topic...

Any news on [1] and apart from the questions therein in particular the
availability of usable AEAD algos?
When I just skimmed through linux/crypto/ I noticed that chacha.c seems
to contain XChaCha support... which IIRC uses a 192bit nonce and should
thus hopefully be secure enough for drive encryption?

But even if that were available for cryptsetup/dm-crypt, it would still
be nice to have alternatives, like in particular one with AES?
Well, I don't really know how e.g. AES256 compares security with to
[X]ChaCha20, AES has at least most likely seen far more crypto analysis
than the latter?
Any chance to lobby the kernel crypo folks to add a GCM mode with
larger nonce?

I mean cryptsetup has all that nice integrity support... but I guess no
one is really using it, given that all available algos/modes were
recommended against because of the too small nonce.


Thanks,
Chris.



[0] https://lore.kernel.org/linux-crypto/27816cc353731e8e5484adad7d0fc44777=
[email protected]/T/#u
[1] https://gitlab.com/cryptsetup/cryptsetup/-/work_items/668