[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALrw=nHLzGjBgvfE9caovw21cpwZkkjLM3Ss47gVZveT1MNRnQ@mail.gmail.com>
Date: Wed, 21 Jan 2026 08:15:19 +0000
From: Ignat Korchagin <ignat@...udflare.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: David Howells <dhowells@...hat.com>, Lukas Wunner <lukas@...ner.de>,
Jarkko Sakkinen <jarkko@...nel.org>, Herbert Xu <herbert@...dor.apana.org.au>,
Luis Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>,
Daniel Gomez <da.gomez@...nel.org>, Sami Tolvanen <samitolvanen@...gle.com>,
"Jason A . Donenfeld" <Jason@...c4.com>, Ard Biesheuvel <ardb@...nel.org>, Stephan Mueller <smueller@...onox.de>,
linux-crypto@...r.kernel.org, keyrings@...r.kernel.org,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
Tadeusz Struk <tadeusz.struk@...el.com>, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v13 07/12] crypto: Add RSASSA-PSS support
On Wed, Jan 21, 2026 at 2:14 AM Eric Biggers <ebiggers@...nel.org> wrote:
>
> On Tue, Jan 20, 2026 at 02:41:11PM -0800, Eric Biggers wrote:
> > On Tue, Jan 20, 2026 at 02:50:53PM +0000, David Howells wrote:
> > > Add support for RSASSA-PSS [RFC8017 sec 8.1] signature verification support
> > > to the RSA driver in crypto/.
> >
> > This additional feature significantly increases the scope of your
> > patchset, especially considering that the kernel previously didn't
> > implement RSASSA-PSS at all. This patchset also doesn't include any
I just wanted to point out that RSASSA-PSS "existed" as supported in
kernel documentation [1] for quite a while now. So it is a matter of
actually fixing "the bug" of it not being implemented as it should
have been from UAPI perspective
> > explanation for why this additional feature is needed. It might make
> > sense to add this feature, but it needs to be properly explained, and it
> > would be preferable for it to be its own patchset.
This does seems reasonable to separate ML-DSA and RSASSA-PSS into
separate patchsets
> > > The verification function requires an info string formatted as a
> > > space-separated list of key=value pairs. The following parameters need to
> > > be provided:
> > >
> > > (1) sighash=<algo>
> > >
> > > The hash algorithm to be used to digest the data.
> > >
> > > (2) pss_mask=<type>,...
> > >
> > > The mask generation function (MGF) and its parameters.
> > >
> > > (3) pss_salt=<len>
> > >
> > > The length of the salt used.
> > >
> > > The only MGF currently supported is "mgf1". This takes an additional
> > > parameter indicating the mask-generating hash (which need not be the same
> > > as the data hash). E.g.:
> > >
> > > "sighash=sha256 pss_mask=mgf1,sha256 pss_salt=32"
> >
> > One of the issues with RSASSA-PSS is the excessive flexibility in the
> > parameters, which often end up being attacker controlled. Therefore
> > many implementations of RSASSA-PSS restrict the allowed parameters to
> > something reasonable, e.g. restricting the allowed hash algorithms,
> > requiring the two hash algorithms to be the same, and requiring the salt
> > size to match the digest size. We should do likewise if possible.
>
> Looking into this a bit more, I'm increasingly skeptical that RSASSA-PSS
> would be a worthwhile addition, especially when integrated into CMS and
> X.509. It seems that while in theory it's an improvement over PKCS#1
> v1.5 padding, the specifications were messed up and it has way too many
> unnecessary and error-prone parameters. Here are some references that
> describe some of the issues in RSASSA-PSS:
>
> * https://boringssl-review.googlesource.com/c/boringssl/+/81656
> * https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html
>
> It seems it might not be very widely used either.
>
> I think the fact that this patchset implements RSASSA-PSS verification
> incorrectly (by not verifying that the leading bit is zero) further
> validates these concerns.
>
> With RSA also being two generations behind the current generation of
> signature algorithms (RSA => elliptic curves => lattices), I'm wondering
> what the motivation for this feature is.
>
> - Eric
[1]: https://docs.kernel.org/security/keys/core.html
Powered by blists - more mailing lists