Everything You Need to Know About RSASSA-PSS

RSA (Rivest-Shamir-Adleman) supports two digital signature schemes defined in PKCS#1. RSASSA-PSS (RSA Signature Scheme with Appendix, Probabilistic Signature Scheme) is the modern scheme, recommended by NIST FIPS 186-5 for all new signature generation. It uses randomized padding that provides a tight security proof and is not vulnerable to the attack classes that affect RSASSA-PKCS1-v1_5. The recommended action: use RSASSA-PSS with SHA-256, MGF1 using SHA-256, a salt length equal to hLen (32 bytes for SHA-256), RSA-3072 or larger keys, and keys stored in a FIPS-validated HSM. Do not use SHA-1 as the hash function even though it appears as the default in some older library implementations.

Quick Answer: What Is RSASSA-PSS and Why Should You Use It?

RSASSA-PSS is the probabilistic RSA signature scheme defined in PKCS#1 v2.1 (RFC 3447) and mandated by NIST FIPS 186-5 for new RSA signature applications. It differs from the older RSASSA-PKCS1-v1_5 in two critical ways: it incorporates a random salt during signing, so the same message produces a different signature each time, and its security is provably reducible to the hardness of the RSA problem under the random oracle model. PKCS#1 v1.5 lacks this security proof and is vulnerable to the Bleichenbacher attack family. NIST FIPS 186-5 permits PKCS#1 v1.5 only for legacy verification (checking existing signatures), not for generating new signatures in new applications.

RSA Signatures: Background

RSA is an asymmetric algorithm that can be used for both encryption and digital signatures. For signatures, the process works as follows: the signer computes a hash of the message, applies a padding scheme to the hash, and encrypts the padded result with their RSA private key, producing the signature. The verifier decrypts the signature with the signer’s public key, applies the inverse padding operation, and compares the result to the hash of the received message. If they match, the signature is valid.

The padding scheme is the critical security component. Two padding schemes are defined in PKCS#1:

• RSASSA-PKCS1-v1_5: the original scheme, first standardized in PKCS#1 version 1.5. It is deterministic: the same message always produces the same signature. It is still widely deployed for backward compatibility but should not be used for new signature applications.
• RSASSA-PSS: the modern scheme, standardized in PKCS#1 v2.1 (RFC 3447). It incorporates a random salt, making it probabilistic: the same message produces a different signature on each signing operation. It has a provable security reduction. NIST FIPS 186-5 recommends it for all new RSA signature generation.

RSASSA-PKCS1-v1_5 vs. RSASSA-PSS: Key Differences

Attribute	RSASSA-PKCS1-v1_5	RSASSA-PSS
Padding type	Deterministic; same message always produces same signature	Probabilistic; random salt makes each signature unique
Message digest extractability	The message digest value can be extracted from the signature structure	The digest cannot be extracted; can only be verified against a known message
Security proof	No tight security proof relating signature security to RSA hardness	Provable security reduction to the RSA problem under the random oracle model
Vulnerability to attacks	Vulnerable to Bleichenbacher attack variants and fault-based attacks	Not vulnerable to Bleichenbacher padding oracle; not vulnerable to fault-based attacks per research
NIST FIPS 186-5 status	Permitted for legacy verification only; not for generating new signatures in new applications	Recommended for all new RSA signature generation
Deployment recommendation	Use only where backward compatibility with existing systems requires it	Use for all new signature applications that must use RSA

Why PKCS#1 v1.5 Signatures Are Vulnerable

The Bleichenbacher Attack (1998): Daniel Bleichenbacher demonstrated that the error messages returned by SSL servers for malformed PKCS#1 v1.5 padding created an adaptive chosen-ciphertext oracle. An attacker who could send arbitrary ciphertexts to the server and observe whether the padding validation succeeded could, through a series of queries, perform RSA decryption and signature operations without knowing the private key. This attack completely broke the confidentiality of TLS when RSA key exchange with PKCS#1 v1.5 was used. Variants of this attack, including ROBOT (Return of Bleichenbacher’s Oracle Threat), demonstrated in 2017 that many modern TLS implementations remained vulnerable. PKCS standards were updated to mandate PSS for new applications specifically in response to this class of attack.

Fault-Based Attacks (1996): Dan Boneh and colleagues demonstrated that by inducing computation errors during RSA signing with the Chinese Remainder Theorem (CRT) optimization, an attacker could recover the private key from a single faulty signature. CRT optimization is widely used in RSA implementations because it significantly speeds up signing. Embedded devices like smartcards, which may be physically accessible to attackers who can manipulate voltage or clock signals, are particularly vulnerable to this class of attack. Research has established that PSS’s randomized structure provides resistance to this attack class that PKCS#1 v1.5 does not.

How RSASSA-PSS Works

RSASSA-PSS uses a private RSA key to sign data in combination with random input (the salt). Two signatures of the same message with the same key will produce different signature values, and both are valid for verifying against the original message. The signing and verification process uses an encoding operation called PSS-EMSA:

1. Hash the message: compute mHash = Hash(message) using the configured hash algorithm (SHA-256 recommended).
2. Generate a random salt: generate a random salt value of length sLen bytes (recommended: sLen = hLen, the hash output length).
3. Compute M’: M’ = (0x0000000000000000 || mHash || salt). Hash M’ to produce H = Hash(M’).
4. Apply MGF: compute dbMask = MGF(H, emLen – hLen – 1) using the Mask Generation Function (MGF1).
5. Encode: DB = (PS || 0x01 || salt) XOR dbMask, where PS is a zero-padding string. Assemble the encoded message EM = (maskedDB || H || 0xbc).
6. Sign: apply the RSA private key operation to EM to produce the signature S.

Verification reverses the process: the RSA public key is used to recover EM from S, the PSS encoding is validated, and the recovered mHash is compared to Hash(message). Verification succeeds if the hash comparison passes and all structural checks hold.

RSASSA-PSS Parameters: What to Configure

1. Hash algorithm: the hash function applied to the message and used internally in the PSS encoding. SHA-256 is the current minimum recommendation; SHA-384 or SHA-512 provide higher security margins. SHA-1 is the default in some older library implementations but must not be used for new signature generation (deprecated by NIST).
2. Mask Generation Function (MGF): MGF1 is the standard mask generation function used with PSS. It takes a seed and a desired output length and produces a pseudorandom output. MGF1 should be configured with the same hash function as the scheme hash algorithm (MGF1 with SHA-256 when the scheme uses SHA-256).
3. Salt length (sLen): the length in bytes of the random salt value generated during signing. Setting sLen = hLen (the hash output length) provides the tightest security proof per RFC 3447 and is the strongly recommended convention. For SHA-256, hLen = 32. Some APIs offer sLen = 0 (deterministic, loses the security advantage of PSS) or sLen = maximum (may fail verification in some implementations); use sLen = hLen.
4. Trailer field: always 0xBC (integer value 1). This is not configurable; any implementation that exposes this parameter should have it set to 1.

Recommended Parameter Configuration

Parameter	Recommended value	Minimum acceptable	Avoid	Reference
Hash algorithm	SHA-256 (or SHA-384 for higher security margin)	SHA-256	SHA-1, MD5	NIST FIPS 186-5; NIST SP 800-131A Rev. 2
MGF algorithm	MGF1 with SHA-256 (match hash algorithm)	MGF1 with SHA-256	MGF1 with SHA-1 in new deployments	RFC 3447 Section 10.1
Salt length (sLen)	hLen (32 bytes for SHA-256; 48 for SHA-384)	hLen	sLen = 0 (deterministic, defeats PSS security purpose); sLen > hLen	RFC 3447; PKCS#1 v2.2
RSA key size	RSA-3072 for new deployments	RSA-2048 (approved through 2030)	RSA-1024, RSA-512	NIST SP 800-57; NIST IR 8547
Trailer field	0xBC (trailerFieldBC)	0xBC	N/A (not configurable in conforming implementations)	RFC 3447

Algorithm Selection: PSS vs. ECDSA vs. Ed25519

Use case	Recommended algorithm	Why	Avoid
New RSA-based applications (code signing, document signing)	RSASSA-PSS with SHA-256, RSA-3072	NIST FIPS 186-5 requirement; provable security; HSM support	RSASSA-PKCS1-v1_5 for new signature generation
Legacy compatibility (verifying existing PKCS#1 v1.5 signatures)	RSASSA-PKCS1-v1_5 for verification only	Backward compatibility requirement; FIPS 186-5 permits for legacy verification	Using PKCS#1 v1.5 to generate new signatures
TLS certificates and TLS 1.3	ECDSA P-256 or RSASSA-PSS with RSA-2048+	TLS 1.3 requires RSASSA-PSS for RSA; ECDSA P-256 preferred for performance and key size	RSASSA-PKCS1-v1_5 in TLS 1.3 (not permitted)
Performance-sensitive signing (high-throughput APIs, IoT)	ECDSA P-256 or Ed25519	Much smaller signatures (64 bytes vs. 384 bytes for RSA-3072); faster signing	RSA-3072+ where throughput or bandwidth is constrained
Post-quantum planning horizon (data with 10+ year confidentiality)	ML-DSA (FIPS 204) alongside current algorithm	RSA is vulnerable to Shor’s algorithm on quantum computers; NIST proposes deprecation after 2030	RSA alone for new long-lived key infrastructure

Deployment Examples

TLS certificate signing in a private PKI: a CA issuing internal TLS certificates for a private PKI uses RSASSA-PSS with SHA-256, MGF1(SHA-256), sLen=32, RSA-3072 key pairs stored in an HSM. The CA’s signing private key never leaves the HSM. PKCS#1 v2.1 AlgorithmIdentifier structures in the issued certificates specify the PSS parameters explicitly, enabling verifiers to confirm the exact parameter set used. The CA’s certificate is self-signed (root) or signed by a higher-level CA using the same PSS parameters.

Code signing for software releases: a software publisher signs release binaries using CodeSign Secure with an RSASSA-PSS signature (SHA-256, MGF1(SHA-256), sLen=32, RSA-3072 private key in HSM). The signing pipeline computes the hash of each binary, sends it to CodeSign Secure, and receives the signature. CodeSign Secure stores the private key in a FIPS 140-2 Level 2 HSM so the key never enters the build environment. Downstream consumers verify the signature using the publisher’s public key obtained from the code signing certificate.

JWT signing in an API authentication system: an API authentication system issues JSON Web Tokens signed with RSASSA-PSS (RS256 in JWT terminology uses PKCS#1 v1.5; PS256 uses PSS). The API server signs JWTs using PS256 (RSASSA-PSS with SHA-256) with a 3072-bit RSA key pair stored in the key management system. Receiving services verify JWTs against the published public key, using the AlgorithmIdentifier in the JWT header to confirm PSS parameters. API clients that present PS256-signed tokens receive higher trust level than those with RS256-signed tokens.

Key Management Dependencies for RSASSA-PSS

The security of RSASSA-PSS depends entirely on the integrity of the RSA private key. A compromised private key allows an attacker to forge signatures for any message, destroying the trust that the signature scheme is designed to provide. Key management requirements for RSA signing keys:

• HSM storage: RSA signing private keys must be stored in a FIPS 140-2 Level 2 or higher HSM that prevents export of the private key in usable form. The signing operation (applying the RSA private key to the hash) must be performed inside the HSM, not by exporting the key to a software process. See HSM as a Service for hardware-backed key storage.
• Cryptoperiod and rotation: NIST SP 800-57 recommends cryptoperiods of one to three years for RSA private signature keys, depending on key size and usage volume. Rotation requires generating a new key pair, issuing a new certificate, transitioning signing operations to the new key, and destroying the old key after its cryptoperiod ends.
• Certificate revocation: if the private key is suspected to be compromised before its scheduled rotation, the corresponding certificate must be revoked immediately through the issuing CA. CertSecure Manager manages certificate lifecycle including revocation workflows.
• Least-privilege access to signing operations: access to invoke the HSM signing operation should be restricted to authorized systems and processes through identity-based access controls, with full audit logging of every signing event.
• PQC migration planning: RSA-based signatures including RSASSA-PSS are vulnerable to quantum computing. The CBOM Secure cryptographic inventory identifies all RSA signing keys in the environment, enabling planning for migration to ML-DSA (FIPS 204) as part of a PQC transition program.

Limitations of RSASSA-PSS

• RSA performance overhead: RSA-3072 signing requires significantly more computation than ECDSA P-256 or Ed25519. For high-throughput signing environments (millions of signatures per hour), RSA-3072 may require more HSM hardware capacity than ECDSA P-256 for the same throughput. Signature verification with RSA (a public key operation) is fast; signing (private key) is the bottleneck.
• Larger signatures and keys than elliptic curve alternatives: an RSA-3072 signature is 384 bytes; an ECDSA P-256 signature is 64 bytes; an Ed25519 signature is 64 bytes. In bandwidth-constrained environments or protocols where signature size matters (such as DNS responses with DNSSEC), the size difference is significant.
• Non-determinism complicates testing: the random salt in PSS means that test vectors for RSASSA-PSS signatures cannot simply be compared by value. Test frameworks must verify signatures rather than compare signature bytes. This is the correct behavior but requires test infrastructure that understands PSS verification rather than simple byte comparison.
• Quantum vulnerability: RSASSA-PSS is based on the RSA problem (integer factorization), which is efficiently solvable by Shor’s algorithm on a sufficiently powerful quantum computer. Organizations should plan migration to NIST-standardized post-quantum signature algorithms (ML-DSA, FIPS 204) for infrastructure with long-term key lifetimes or data protection requirements extending beyond 2030.

Conclusion

RSASSA-PSS is the RSA signature scheme that all new applications should use. Its security advantage over RSASSA-PKCS1-v1_5 is not marginal: PSS has a provable security reduction to the RSA problem; PKCS#1 v1.5 does not, and is vulnerable to attack classes that PSS is not. NIST FIPS 186-5 reflects this distinction by permitting PKCS#1 v1.5 only for legacy verification, not for generating new signatures. For practical deployments: use SHA-256 as the hash algorithm, MGF1(SHA-256) as the mask function, sLen=32 (hLen) as the salt length, RSA-3072 keys stored in a FIPS-validated HSM, and begin planning PQC migration if your key infrastructure has a lifetime extending into the 2030s.

Frequently Asked Questions

What is RSASSA-PSS and how does it differ from RSASSA-PKCS1-v1_5?

RSASSA-PSS is the probabilistic RSA signature scheme with a provable security reduction to the RSA problem. RSASSA-PKCS1-v1_5 is its deterministic predecessor with no such proof and known vulnerabilities to the Bleichenbacher attack family. NIST FIPS 186-5 recommends PSS for new signature generation and permits PKCS#1 v1.5 only for legacy verification.

What are the required parameters for RSASSA-PSS?

Hash algorithm (SHA-256 recommended; not SHA-1), MGF algorithm (MGF1 with the same hash as the scheme), salt length (sLen = hLen, the hash output length in bytes; 32 for SHA-256), and trailer field (0xBC, not configurable). Matching the MGF hash to the scheme hash and using sLen = hLen provides the tightest security proof per RFC 3447.

What key size should be used with RSASSA-PSS?

RSA-3072 for new deployments (128-bit security strength). RSA-2048 is the minimum and is approved through 2030 per NIST IR 8547 preliminary guidance, but proposed for deprecation after that date. RSA-1024 is prohibited. For performance-constrained environments, consider ECDSA P-256, which provides equivalent 128-bit security with 64-byte signatures.

What is the Bleichenbacher attack and why does PSS prevent it?

The Bleichenbacher attack (1998) exploited PKCS#1 v1.5 padding errors as a decryption oracle, enabling RSA private key operations without the key. PSS’s randomized structure has no deterministic relationship between message and signature value and no padding oracle, with security provably reduced to the RSA problem under the random oracle model.

When should RSASSA-PSS be used vs. ECDSA?

Use RSASSA-PSS when RSA-based PKI compatibility is required, existing infrastructure manages RSA keys, or regulatory requirements mandate RSA. Prefer ECDSA P-256 for new infrastructure where signature size, performance, and bandwidth efficiency matter, as it provides 128-bit security with 64-byte signatures vs. RSA-3072’s 384-byte signatures.

Is RSASSA-PSS quantum-safe?

No. RSASSA-PSS is based on integer factorization, which Shor’s algorithm solves efficiently on a quantum computer. NIST FIPS 204 (ML-DSA) is the primary post-quantum signature standard. NIST IR 8547 proposes deprecating RSA signatures after 2030 and disallowing them after 2035. Organizations with long-lived key infrastructure should begin PQC migration planning.