On Wed, Jan 21, 2026 at 2:14 AM Eric Biggers <[email protected]> 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
