To my humble opinion, please correct me if I'm wrong, RSA-PSS (PKCS#1 ver 2.1) advantage over RSA as described in PKCS#1 ver. 1.5 is in its security proofs. Does this proof and the advantage is still there even if the "salt" in the RSA-PSS scheme is constant over all messages, or it conditioned in generating a random salt each and every signature? That is, does the security proof of RSA-PSS assumes random salt over messages?

• – fgrieu
Dec 3 '18 at 11:46

Even if we make RSASSA-PSS deterministic by fixing its seed, it remains with a security proof in the Random Oracle Model per Full Domain Hashing (Jean-Sébastien Coron, On the Exact Security of Full Domain Hashing, in proceedings of Crypto 2000). We can't say the same for RSASSA-PKCS1-v1_5, because a lot of the message representative is fixed.

In practice, a better argument to use deterministic RSASSA-PSS rather than RSASSA-PKCS1-v1_5 is that vulnerable implementations of verification of RSASSA-PKCS1-v1_5 abound, when I know no vulnerable implementation of RSASSA-PSS verification (regardless of randomization), and this is less likely to happen accidentally.

However a practical argument against RSASSA-PSS is that it requires careful specification of the hash and the mask generation function: even if the later is almost universally MGF1, that could be with another hash (e.g. stuck to SHA-1) depending on implementations.

• Could you give an example on how RSASSA-PKCS1-v1_5 is vulnerable and an example? Or should I ask this in a separate question? Maarten. Dec 4 '18 at 14:46
• @Maarten Bodewes: RSASSA-PKCS1-v1_5 as specified has no known vulnerability. Some incorrect implementations of its signature verification step are vulnerable. Example among dozens: CVE-2014-9934. For something more detailed, a questions seems in order, but I do not know if it is for crypto.se or security.se.
– fgrieu
Dec 4 '18 at 14:55
• Yeah, if you skip validating the padding in its entirety then it may be vulnerable :P The incompetence of some people in the field is just astonishing. Goodness gracious. Thanks anyway. I'll leave it at that. Dec 4 '18 at 15:13
• It could be easy to use XOF instead of MFG1, isn't it? Oct 20 '19 at 19:55
• @kelalaka: in theory, XOF can be used instead of MGF1; see this. In practice, modifying existing code, library, and test vectors is work. And that can only be done with new applications.
– fgrieu
Oct 21 '19 at 6:04