RSASSA-PSS support added to iText 8

Background

The RSA cryptosystem has been around for a long time, and is still very widely used. It arguably owes its ubiquity in large part to the fact that it was the first public-key cryptosystem to be formalized as a widely adopted internet standard, back in the 1990s. Indeed, the standard defining “interoperable RSA” for use on the web is called "PKCS #1", or "Public-Key Cryptography Standard #1".

As a cryptosystem, RSA is quite versatile: it can be used both for signatures and encryption/key transport, and both are mathematically very similar. In fact, with the way things are set up in PKCS #1, you can use the same key for both decryption and signing—this is a bad idea for various reasons, but that hasn’t stopped it from becoming a very widespread practice, especially in e-mail security.

Indeed, while RSA’s “first mover” advantage cemented its place in the PKI ecosystem and the RSA cryptosystem still fundamentally holds up to this day, three decades of advances in our understanding have revealed several issues with the way it was standardized and applied. The example cited above is one such issue, but it’s not the one this article is about.

What’s this "PSS" thing?

Let’s talk about padding schemes—I hear you cry. From a mathematical perspective, RSA operates on messages of a fixed length, which is determined by the size of the key. However, in practice, the data we want to feed into the algorithm (whether it’s a hash to be signed or a symmetric key to be encrypted) is typically a lot shorter. This means that it needs to be padded for RSA to be applied.

The way this padding was defined in the first IETF RFC for PKCS #1 (PKCS #1 v1.5) was actually quite simple:

• Encryption: 0x00 0x02 <random filler bytes> 0x00 <message>
• Signing: 0x00 0x01 <0xff filler bytes> 0x00 <digest info>

This padding scheme is very easy to implement and works quite similarly for both RSA encryption and signing. It’s also still very widely used today.

Let’s start with the good news: there are no known vulnerabilities that fundamentally break this scheme as far as RSA signatures are concerned. Not so with RSA encryption, however: Bleichenbacher’s attack is a famous example.

That said, we should be able to do better than "no known issues". While the "RSA problem" is widely believed to be computationally intractable as a mathematical problem, there was no proof that the signing and encryption operations defined in PKCS #1 v1.5 still enjoyed the same properties.

Allowing such systematic analysis was not a design goal of the "first-generation" PKCS #1 publication, and it turns out that its padding scheme makes that very difficult. Fortunately, in the mid-to-late 90s, Bellare and Rogaway devised improved encoding methods that are more amenable to security analysis.

• OAEP (Optimal Asymmetric Encryption Padding): a better padding scheme for RSA encryption/key transport
• PSS (Probabilistic Signature Scheme): an improved pre-signing encoding scheme for RSA signatures (this is strictly speaking not a padding scheme anymore)

Discussing the exact security models used and comparing the results with other cryptosystems would lead us too far, but suffice to say that they’re much more robust than “legacy” PKCS #1. As far as signing is concerned, the gist of it is that Bellare and Rogaway could prove that a PSS-based RSA signature is at least as secure as the underlying RSA problem. In other words, a successful attack on RSA with PSS implies being able to break the RSA problem efficiently.¹ There’s no comparable result for RSA with PKCS #1 v1.5 padding.

In conclusion:

• RSA signing with PSS (RSASSA-PSS) can be proven to be secure if the RSA problem is as hard as we think it is.
• There are no known exploits against RSA signing with "legacy" PKCS #1 v1.5 padding, but also no security proofs.

Standards and regulations

RSAES-OAEP and RSASSA-PSS have been integrated into PKCS #1 for about two decades. The technology isn’t exactly new, but adoption has been lackluster. In particular, the lack of known exploitable vulnerabilities in "traditional" RSA signatures makes the old PKCS #1 v1.5 padding scheme still by far the most widely used.

That said, things appear to be changing: other cryptosystems have been eating away at RSA’s market share, which seems to have lowered the industry’s resistance to change. RSASSA-PSS has been slowly gaining ground, and the German government’s latest guidelines will soon mandate the use of PSS for RSA signatures for many applications. RSASSA-PSS can also be used to produce PAdES signatures (although using PKCS #1 v1.5 padding is not currently forbidden).

Since the cryptographic primitive that underpins RSASSA-PSS is still just an RSA signature, it’s possible to use a "regular" RSA key pair for RSASSA-PSS just as well. As such, if you wanted to, you could simply start using RSASSA-PSS with your current RSA keys without requesting new certs. That said, it’s considered good key hygiene to avoid using one key pair in multiple ways, so if you generate a key to use with RSASSA-PSS, avoid using it to produce "traditional" RSA signatures. In fact, certificates can be issued in such a way that the public key information field flags a key as "PSS-only", which would allow this limitation to be enforced by a validator, but this convention is unfortunately not universally supported at the time of writing.

What took you so long?

Throughout the past few years, questions about using RSASSA-PSS with iText were fairly common on iText’s internal support tracker and on StackOverflow. The reason why it took until iText 8 to ship is actually fairly benign: API compatibility concerns.

RSASSA-PSS is a parameterized signature scheme, so producing (resp. validating) signed PDFs using RSASSA-PSS requires being able to properly serialize (resp. process) these parameters. iText has included digital signature support for a very long time at this point, but the API wasn’t initially designed to handle parameterized signature schemes. Fixing this required a decent amount of refactoring involving some public API breakage. Since iText 8 already included several API-breaking changes in the signature API, the time was right to include first-class support for RSASSA-PSS as well.

In closing

With the addition of RSASSA-PSS to its arsenal, iText 8 allows a large group of users to adopt more modern signature standards. If you’re one of many people still using RSA with PKCS #1 v1.5 padding, but using ECC-based signatures (ECDSA, EdDSA) is off the table, consider whether adopting RSASSA-PSS makes sense for your use case.

¹ If you’re interested in the exact formulation, have a look at Theorem 4.1 in https://www.cs.ucdavis.edu/~rogaway/papers/exact.pdf.