I read the RFC 8017 and understood the pkcsv1.5 and pss padding techniques. I understood that in RSASSA-PSS signing scheme the signature will be appended at the end of M.

In some websites I read both RSASSA-PSS and RSA-PSS both are same, is it true? If not what is the fundamental difference between RSASSA-PSS and RSA-PSS, can you also please provide me the API's to sign and verify using OpenSSL for RSASSA-PSS.

Thank You.


Some authors draw a distinction between:

  • RSA-PSS, analyzed by Bellare and Rogaway in 1996[1] and proposed for IEEE P1363 in 1998[2], which is roughly defined in terms of $H(r \mathbin\| m)$, and
  • RSASSA-PSS, standardized in IEEE P1363-2000 and RSA PKCS #1 v2.1, which is roughly defined in terms of $H(r \mathbin\| H(m))$.

This distinction is significant: RSA-PSS relies only on target collision resistance[3] (or universal one-way hash function…ness[4]) of $H$, while RSASSA-PSS relies on full collision resistance of $H$.

Another way to view it is that RSASSA-PSS—like RSASSA-PKCS1-v1_5 and any other signature scheme where the message figures in only via $H(m)$—is vulnerable to collisions in $H$. This spells bad news when $H$ is MD5, as many people used in practice for many years. Academic cryptographers publicly demonstrated certificate forgery using an MD5 collision attack on RSASSA-PKCS1-v1_5[5][6]; the United States and Israel forged a Microsoft software update signing certificate using an independently developed MD5 collision attack[7] to sabotage Iran's nuclear program. But as far as anyone can tell, MD5's target collision resistance still holds up to this day, so RSA-PSS would have thwarted this entire avenue for certificate forgery even with MD5.

Why IEEE P1363-2000 and RSA PKCS #1 v2.1 standardized $H(r \mathbin\| H(m))$ instead of $H(r \mathbin\| m)$ is a mystery to me. Coincidentally, this standardization happened around the same time that RSA, Inc., accepted a 10e6 USD bribe from the NSA to deploy Dual_EC_DRBG to all their RSA-BSAFE customers[8].

Modern signature schemes like Ed25519 use the design principle $H(r \mathbin\| m)$ in order to rely only on the weaker property target collision resistance like PSS or at least enhanced target collision resistance[9], and as such are advertised to have collision resilience. (More on the history of these and related concepts in a previous answer.)

  • $\begingroup$ The actual hashclash attack was on a CA using MD5 + "v1.5" (RSASSA-PKCS1-v1_5), although I concur it would have worked on MD5 + the PKCS1 version of PSS -- if any public CA was using that in 2009, which I very much doubt. $\endgroup$ Apr 7 '19 at 4:09
  • $\begingroup$ @dave_thompson_085 I had intentionally left it a little vague because I couldn't recall whether it was RSASSA-PSS or RSASSA-PKCS1-v1_5. I have updated the text to (a) point out the design mistake common to RSASSA-PSS and RSASSA-PKCS1-v1_5, (b) confirm that hashclash attacked RSASSA-PKCS1-v1_5, and (c) continue to leave it vague what Flame attacked because in five minutes of searching I can't find a reference to support anything more specific than an MD5 collision attack in the Microsoft Terminal Software Licensing Service. Better? $\endgroup$ Apr 7 '19 at 15:56

There is only one standard cryptographic mechanism that uses both the RSA trapdoor function family and the PSS padding scheme, and that's RSASSA-PSS defined by PKCS#1 v2.1 and above (RFC 8017 being the current version of this standard). So “RSASSA-PSS” is the formal name of a cryptographic mechanism, and “RSA-PSS” is an unambiguous abbreviation of “RSASSA-PSS”.

I understood that in RSASSA-PSS signing scheme the signature will be appended at the end of M.

This is not necessarily the case. RSASSA-PSS signature generation takes an RSA key and a message as inputs, and produces a signature as output (unless it fails, in which case it produces a failure indicator but no output). You can append the signature to the message if you want, but you don't have to. In fact, you shouldn't just append the signature to the message: if you want to store or transmit the message and the signature together, always encode them in an unambiguous way. There are multiple ways to do that, for example with a header that indicates the length of the message and the length of the signature, and then concatenating this header, the message and the signature. But if you want to use a different encoding, that's fine.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.