22

Is RSASSA-PKCS1-v1_5 a good signature scheme to recommend that people use in new systems? Is it believed to be secure and represent the state-of-the-art in RSA-based signatures?

I understand that RSA-PSS is a newer signature scheme, also standardized in PKCS #1. I found a memo from RSA recommending that people transition to RSA-PSS. Is that right? Would it be better to recommend that people use RSA-PSS, instead of RSA-PKCS1-v1_5? If you were going to recommend a single RSA-based signature scheme, which would you recommend that new systems use?

Practical relevance: for instance, at the moment the current draft of the WebCryptoAPI recommends supporting RSASSA-PKCS1-v1_5 (but not RSA-PSS).

D.W.
  • 36,982
  • 13
  • 107
  • 196

3 Answers3

14

PSS is harder to implement because it uses randomness -- randomness is hard on many embedded systems like smart cards.

The most proclaimed advantage of PSS is that it has a "security proof" with, apparently, a rather tight reduction (see this page for some references). Security proofs are not an easy subject; the proof for OAEP (the encryption padding which is like the "sister protocol" to PSS) was found out to be wrong by Shoup and then repaired again by Fujisaki, Okamoto, Pointcheval and Stern, albeit with some casualties on the tightness front. I do not know how much all of this extends to PSS, but it shows that security proofs, however cool they may be, also need the "peer scrutiny" on which cryptographic security is traditionally built.

On the other hand, v1.5 signatures have been exposed "in the wild" for twice as long as PSS, and remain unbroken. In my opinion, this is very good and I quite trust that kind of security.

On a practical point of view, using a signature algorithm implies using a key storage device which knows that algorithm (smart card, HSM, software implementation...). The choice is not necessarily up to the application which requests the signature.

Thomas Pornin
  • 88,324
  • 16
  • 246
  • 315
6

The answer is either "no" or "it depends".

Generally speaking, RSA-PSS is more robust, in the sense that you don't have to take as many extra precautions in order to use it securely. RSA-PKCS#1-v1.5 is OTOH more widely supported by pre-exisiting software, but you sometimes have to patch the way it is used in order to prevent exploits. For instance, if you use RSA-PKCS#1-v1.5 with the MD5 or SHA1 hash algorithms, and sign data originally sent to you from 3rd parties, you have to add a chunk of random data to the data-to-be-signed in order to prevent collision attacks. This is not necessary if you use RSA-PSS.

In the original 1998 submission of EMSA-PSS by Bellare and Rogaway to IEEE P1363 (which is based on the 1996 paper by the same authors), the encoding takes a mask generation function G as a parameter. In this specification, the message M is taken as input, and a fresh random 20 octet string seed is generated. A 20 octet digest w = G(seed||M) is generated, and that w is in turn used for generating the mask.

In the final IEEE P1363 specification of EMSA4, as well as the PKCS#1 v2.1 specification of RSASSA-PSS, the input is a digest of the message instead of the message itself, which makes the algorithm vulnerable to collisions in the underlying hash function, but OTOH allows for the seed length to be parametrizable.

Henrick Hellström
  • 10,556
  • 1
  • 32
  • 59
3

I'm not going to add any analysis, but just some RFC quotes and timelines about RSA signing ('signature scheme with appendix'), PKCS #1 v1.5 and PSS ('probabilistic signature scheme')

February 2003 Users encouraged to move away from RSASSA PKCS #1 v1.5 in RFC 3447 PKCS #1: RSA v2.1, §8: Signature schemes with appendix, p. 36

Two signature schemes with appendix are specified in this document: RSASSA-PSS and RSASSA-PKCS1-v1_5. Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest of increased robustness, RSASSA-PSS is recommended for eventual adoption in new applications. RSASSA-PKCS1-v1_5 is included for compatibility with existing applications, and while still appropriate for new applications, a gradual transition to RSASSA-PSS is encouraged. [emph. added]

November 2016 RSASSA PKCS #1 v1.5 is deprecated by RFC 8017 PKCS #1: RSA v2.2, §8: Signature Scheme with Appendix, p. 32, and PSS is declared "required".

Two signature schemes with appendix are specified in this document: RSASSA-PSS and RSASSA-PKCS1-v1_5. Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest of increased robustness, RSASSA-PSS is REQUIRED in new applications. RSASSA-PKCS1-v1_5 is included only for compatibility with existing applications.


Not signing, but encryption*

*I've mixed up RSASSA-PKCS1-v1.5 and RSAES-PKCS1-v1.5 a few times, maybe others have. This is included for their benefit...

PKCS #1 v1.5 for encryption has been deprecated for 20 years.

October 1998 RSAES PKCS #1 v1.5 is deprecated in RFC 2437 PKCS #1 RSA v2.0, §7 Encryption Schemes, p. 11 in lieu of RSAES-OAEP. (same wording repeated in RFC 3447)

RSAES-OAEP is recommended for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications, and is not recommended for new applications.

November 2016 RFC 8017, §8: Encryption Schemes, p. 17 brings some slightly stronger wording.

RSAES-OAEP is REQUIRED to be supported for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications.

Nick T
  • 261
  • 2
  • 8