Re: [PATCH] crypto: af_alg - Allow additional ciphers for cryptsetup

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Jul 06, 2026 at 01:24:45PM -0700, Eric Biggers wrote:
> On Mon, Jul 06, 2026 at 08:20:10PM +0200, Milan Broz wrote:
> > On 7/5/26 8:44 PM, Eric Biggers wrote:
> > > Add "xts(camellia)", "xts(serpent)", and "xts(twofish)" to the allowlist
> > > for af_alg_restrict=1.  These niche AES alternatives have continued to
> > > see rare but persistent use via cryptsetup, which has historically
> > > relied on the AF_ALG support for these ciphers in XTS mode for
> > > performing the keyslot encryption.  (cryptsetup v2.8.7 and later fall
> > > back to a temporary dm-crypt mapping, but that requires root.)
> > > 
> > > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > > ---
> > >   crypto/algif_skcipher.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> > > index 2b8069667974..49ae779b3b6b 100644
> > > --- a/crypto/algif_skcipher.c
> > > +++ b/crypto/algif_skcipher.c
> > > @@ -45,6 +45,9 @@ static const struct af_alg_allowlist_entry skcipher_allowlist[] = {
> > >   	{ "ecb(des)", true }, /* iwd */
> > >   	{ "hctr2(aes)", false }, /* cryptsetup */
> > >   	{ "xts(aes)", false }, /* cryptsetup benchmark */
> > > +	{ "xts(camellia)", false }, /* cryptsetup */
> > > +	{ "xts(serpent)", false }, /* cryptsetup */
> > > +	{ "xts(twofish)", false }, /* cryptsetup */
> > >   	{},
> > 
> > Well, if we are going this way, I would also add Aria and SM4
> > (currently usable only in cryptsetup main branch).
> 
> I'm adding these three because they seem to have a history of occasional
> use, as can be seen by web search results including their mentions in
> various forums, documentation, etc.  So I worry about breaking users of
> them who upgrade their kernel and still have cryptsetup < 2.8.7.
> 
> It doesn't seem like the same as true of aria-xts or sm4-xts.  And as
> you said they are usable only on the cryptsetup main branch -- which I
> understand now consistently uses the fallback to a temporary dm-crypt
> mapping (at least when run as root).  So perhaps we don't actually need
> to allow "xts(aria)" and "xts(sm4)" as well?
> 
> The point isn't to add things that could theoretically be used, but
> rather add the minimum set that's needed to keep actual existing users
> working.

Do we need to add cbc(...) for these algorithms as well?

- Eric