RSA Padding Explained: PKCS#1 v1.5 vs. OAEP vs. PSS

RSA padding is a mandatory structural layer applied to data before RSA encryption or signing. Without it, RSA is deterministic and vulnerable to known-plaintext, chosen-ciphertext, and pattern-based attacks. Three schemes cover virtually all RSA deployments: PKCS#1 v1.5 (legacy, vulnerable for encryption, disallowed by NIST after December 31, 2023), OAEP (current standard for RSA encryption, formally proven secure), and PSS (current standard for RSA digital signatures, tight security proof). Use OAEP for encryption and PSS for signatures. Any system still using PKCS#1 v1.5 for RSA encryption needs remediation now.

Quick Answer: Which RSA Padding Scheme Should You Use?

Use OAEP with SHA-256 for RSA encryption and PSS with SHA-256 for RSA digital signatures in all new implementations. PKCS#1 v1.5 encryption was disallowed by NIST (SP 800-131A Rev. 2) after December 31, 2023, and remains exploitable via Bleichenbacher-style oracle attacks in systems that still use it. PKCS#1 v1.5 signatures are not practically broken but carry no formal security proof and should be replaced at the next key rotation. If you do not know which padding schemes are in use across your environment, a cryptographic discovery assessment is the starting point.

RSA is one of the most widely deployed public-key algorithms in the world. It underpins TLS connections, certificate-based authentication, digital signatures, and key exchange across nearly every industry. But RSA on its own is unsafe to use directly. The mathematics work, but the bare operation is deterministic: encrypt the same 16-byte session key twice and you get the same ciphertext both times. Any attacker recording traffic can spot that pattern. Padding is what stops this.

There are three RSA padding schemes that matter in practice. Each was designed for a specific purpose, each carries a different security profile, and using the wrong one in a new system is not a minor misconfiguration; it is a documented vulnerability with working exploits. This post explains exactly how each scheme works, what its security assumptions are, where it is required or prohibited, and what your organization should do right now.

What Is RSA Padding and Why Is It Required?

Raw RSA operates on a modular exponentiation: ciphertext = plaintext^e mod n. That operation is entirely deterministic. Given the same plaintext and the same public key, the ciphertext is always identical. This creates three concrete problems.

First, pattern recognition: an attacker watching encrypted traffic can correlate repeated ciphertexts to repeated plaintexts without breaking the encryption. Second, malleability: raw RSA ciphertexts can be mathematically manipulated in predictable ways, allowing an attacker to produce a valid ciphertext for a related plaintext without knowing the original. Third, small plaintext vulnerability: if the plaintext is small relative to the modulus (for example, a short symmetric key), the modular exponentiation wraps around less than once and the ciphertext can be broken with a cube root or similar shortcut.

Padding solves all three by adding structured randomness and integrity checks to the input before the RSA operation is applied. Every correctly padded encryption of the same message looks different. Tampered ciphertexts produce invalid padding on decryption. Short plaintexts are expanded to fill the modulus space. Padding is not optional and not cosmetic. It is the difference between a theoretical and a practical security guarantee.

PKCS#1 v1.5: How It Works, Its Security Assumptions, and Why It Failed

PKCS#1 v1.5 (defined in RSA Laboratories PKCS#1 version 1.5, 1993, and standardized in RFC 2313) was the first widely deployed RSA padding scheme. It covers two operations: encryption (RSAES-PKCS1-v1_5) and digital signatures (RSASSA-PKCS1-v1_5).

Encryption Structure

For a 2048-bit RSA key (256 bytes), the PKCS#1 v1.5 encryption padding block is structured as follows:

0x00 | 0x02 | PS (non-zero random bytes, min 8 bytes) | 0x00 | Message

The leading 0x00 0x02 signals the block type. The padding string (PS) must contain at least 8 non-zero random bytes. The 0x00 separator tells the recipient where padding ends and the message begins. The maximum message length is 245 bytes for a 2048-bit key (256 bytes minus 11 bytes of overhead).

Signature Structure

For signatures, the block type is 0x00 0x01, the padding string uses 0xFF bytes (deterministic, not random), and the message field contains a DER-encoded DigestInfo structure identifying the hash algorithm followed by the hash value. Crucially, signature padding is deterministic: the same message always produces the same padded block before the RSA signing operation.

The Bleichenbacher Attack and Why PKCS#1 v1.5 Encryption Failed

In 1998, Daniel Bleichenbacher published an adaptive chosen-ciphertext attack against PKCS#1 v1.5 encryption in TLS. The attack works as follows: the attacker sends a large number of crafted ciphertexts to a TLS server that uses RSA PKCS#1 v1.5 encryption for the session key exchange. The server attempts decryption on each one. If padding is valid (starts with 0x00 0x02), the server proceeds; if not, it returns a specific error. That binary response is an oracle. By iterating over carefully constructed ciphertexts and observing the oracle responses, the attacker narrows the range of possible plaintexts until the session key is fully recovered. No knowledge of the RSA private key is required.

The 2017 ROBOT (Return Of Bleichenbacher’s Oracle Threat) research demonstrated that this attack remained practical across products from at least seven major vendors, including F5 (CVE-2017-6168), Citrix (CVE-2017-17382), and Cisco, nearly two decades after the original discovery. The ROBOT team found approximately one-third of the Alexa Top 100 domains were vulnerable at the time of disclosure.

The root cause is structural. PKCS#1 v1.5 was designed before formal security models for public-key encryption existed. Its padding structure leaks just enough information (roughly a 1-in-65,536 chance that a random blob passes as valid padding) to make an oracle-based attack feasible. No countermeasure that preserves PKCS#1 v1.5 padding semantics can fully close this channel.

Regulatory status: NIST SP 800-131A Revision 2 explicitly disallowed RSAES-PKCS1-v1_5 (encryption) after December 31, 2023. RFC 8017 (PKCS#1 v2.2, the current standard) retains PKCS#1 v1.5 for backward compatibility only and requires OAEP for new applications. OpenSSL’s documentation explicitly discourages PKCS#1 v1.5 encryption and recommends RSA_PKCS1_OAEP_PADDING for all new code.

OAEP Explained: The Current Standard for RSA Encryption

OAEP stands for Optimal Asymmetric Encryption Padding. It was designed by Mihir Bellare and Phillip Rogaway in 1994 and is specified in PKCS#1 v2.0 (1998), v2.1 (RFC 3447, 2003), and v2.2 (RFC 8017, 2016). RSAES-OAEP is the required RSA encryption scheme for new applications under all three documents.

How OAEP Works: Step by Step

OAEP uses a two-pass masking construction before applying the RSA operation. Here is the sequence for RSAES-OAEP with SHA-256 and MGF1:

1. Generate a random seed of length equal to the hash output (32 bytes for SHA-256).
2. Construct a Data Block (DB): concatenate the optional label hash, a zero-padding string, the byte 0x01, and the message. The total length of DB is k – hLen – 1 bytes, where k is the key length in bytes.
3. Apply MGF1 to the seed to produce a mask the same length as DB. XOR this mask with DB to produce maskedDB.
4. Apply MGF1 to maskedDB to produce a mask the same length as the seed. XOR this mask with the seed to produce maskedSeed.
5. Concatenate: 0x00 | maskedSeed | maskedDB. Apply RSA encryption to this block.

The critical security property is plaintext awareness: under the random oracle model, it is computationally infeasible to produce a valid OAEP ciphertext without knowing the plaintext. Any modification to the ciphertext produces an unpredictable result on decryption, not a structured error that can serve as an oracle. This directly eliminates the Bleichenbacher attack channel.

Security Assumptions and Formal Proof

OAEP’s security is proven under two assumptions: the RSA problem is hard, and the hash function and MGF behave as random oracles. In this model, OAEP achieves IND-CCA2 security (indistinguishability under adaptive chosen-ciphertext attack), the strongest standard security notion for public-key encryption. PKCS#1 v1.5 has no such proof.

Practical parameters: Use SHA-256 as the hash algorithm for OAEP in new deployments. SHA-1 in OAEP configurations should be avoided; NIST SP 800-131A Rev. 3 (initial public draft) deprecates SHA-1 through December 31, 2030. MGF1 is the standard mask generation function used in all current implementations.

Library identifiers: OpenSSL: RSA_PKCS1_OAEP_PADDING. Java JCE: RSA/ECB/OAEPWithSHA-256AndMGF1Padding. Python cryptography: OAEP(mgf=MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None). Web Crypto API: RSA-OAEP.

PSS Explained: The Current Standard for RSA Digital Signatures

PSS stands for Probabilistic Signature Scheme. It was designed by Bellare and Rogaway in 1996, is specified in PKCS#1 v2.1 and v2.2 (RFC 8017), and is the recommended RSA signature scheme under NIST FIPS 186-5 (2023). PSS applies only to signing, not to encryption.

How PSS Works: Step by Step

1. Hash the message to produce mHash (32 bytes with SHA-256).
2. Generate a random salt of length sLen (commonly 32 bytes for SHA-256).
3. Construct M’: concatenate 8 zero bytes, mHash, and the salt. Hash M’ to produce H.
4. Construct DB: concatenate a zero-padding string, the byte 0x01, and the salt.
5. Apply MGF1(H) to produce a mask the same length as DB. XOR with DB to produce maskedDB.
6. Set the top bit of maskedDB to 0 to ensure the encoded message is smaller than the modulus.
7. Concatenate: maskedDB | H | 0xBC. Apply the RSA private key operation to produce the signature.

The random salt means two signatures over the same message look completely different but both verify correctly. This is why PSS is called probabilistic.

Security Assumptions and Formal Proof

PSS has a tight security reduction: forging a PSS signature is computationally equivalent to solving the RSA problem under the random oracle model. PKCS#1 v1.5 signatures have no such reduction. NIST FIPS 186-5, published February 2023, lists RSASSA-PSS as an approved signature scheme; RSASSA-PKCS1-v1_5 is retained only for verifying existing signatures.

Library identifiers: OpenSSL: RSA_PKCS1_PSS_PADDING. Java JCE: RSASSA-PSS. Python cryptography: PSS(mgf=MGF1(hashes.SHA256()), salt_length=PSS.MAX_LENGTH). Web Crypto API: RSA-PSS with a salt length parameter.

Worked Example: What Happens When You Encrypt with Each Scheme

Consider encrypting a 16-byte AES session key with a 2048-bit RSA public key. Here is what each scheme does to the 256-byte block before the modular exponentiation:

Step	PKCS#1 v1.5 (RSAES)	OAEP (SHA-256, MGF1)
Block layout	00 02 + 238 random non-zero bytes + 00 + 16-byte key	00 + 32-byte maskedSeed + 191-byte maskedDB containing the key
Randomness	238 independent non-zero bytes prepended	32-byte seed mixed through entire block via two MGF1 passes
Integrity	None; modifications may still decode to structured padding	Any bit flip produces completely invalid decryption
Oracle resistance	Decryption errors leak padding validity (Bleichenbacher exploitable)	Decryption errors are indistinguishable; no oracle available
Max message size (2048-bit key)	245 bytes	190 bytes (hash and seed overhead)

Enterprise Decision Table: Which RSA Padding Scheme to Use

Use case	Correct scheme	Why	What to avoid
New RSA encryption implementation	RSAES-OAEP (SHA-256)	IND-CCA2 proven; required by RFC 8017 and NIST SP 800-131A Rev. 2	PKCS#1 v1.5 encryption (disallowed by NIST after December 31, 2023)
New RSA digital signature implementation	RSASSA-PSS (SHA-256)	Tight security reduction to RSA; required by FIPS 186-5 for new implementations	PKCS#1 v1.5 signatures for new systems (no formal proof)
TLS 1.3 server certificate	RSASSA-PSS	Required by RFC 8446 for RSA server key usage	PKCS#1 v1.5 (explicitly prohibited for TLS 1.3 server certificates)
TLS 1.3 client auth (legacy key only)	RSASSA-PKCS1-v1_5 (legacy path only)	RFC 9963 (April 2026) permits for legacy client keys; disabled by default	Use PSS if the client key supports it; migrate at next key rotation
Code signing (firmware, software)	RSASSA-PSS (SHA-256)	NIST SP 800-89 guidance; formal proof matters in long-lived signing contexts	PKCS#1 v1.5 signatures for new signing infrastructure
FIPS 140-3 HSM configuration	RSAES-OAEP and RSASSA-PSS	FIPS 186-5 approves PSS; NIST SP 800-131A Rev. 2 disallows PKCS#1 v1.5 encryption	PKCS#1 v1.5 for any encryption key usage on validated modules
Legacy system (backward compat only)	PKCS#1 v1.5 signatures only, if unavoidable	PKCS#1 v1.5 signatures not practically broken; plan migration regardless	PKCS#1 v1.5 encryption in any system, legacy or not
CA signing operations	RSASSA-PSS	NIST FIPS 186-5 and CA/Browser Forum Baseline Requirements support PSS	PKCS#1 v1.5 for new CA signing key configurations

Limitations of RSA Padding Schemes

• RSA is not quantum-resistant: Shor’s algorithm breaks RSA regardless of padding scheme. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Organizations with long-lived data or certificates sensitive into the 2030s should be planning migration now.
• OAEP reduces maximum plaintext size: For a 2048-bit key: PKCS#1 v1.5 allows up to 245 bytes; OAEP with SHA-256 allows only 190 bytes. For symmetric keys (16 to 32 bytes) this is not a constraint. For larger payloads, use hybrid encryption: AES-256-GCM for the data, RSA-OAEP for the AES key.
• Side-channel attacks require careful implementation: OAEP and PSS are secure in the symbolic model, but non-constant-time decryption routines can reintroduce oracle channels. Always use vetted library implementations rather than custom RSA code.
• Key size matters independently of padding: NIST disallowed 1024-bit RSA after December 31, 2013. Use at minimum 2048-bit keys; 3072 bits is recommended for security requirements extending past 2030.
• PKCS#1 v1.5 signature forgeries exist in specific implementation contexts: Implementation errors in padding verification have enabled forgeries in real-world code. RFC 9963 notes this risk explicitly. Always validate against the full specification.

Finding PKCS#1 v1.5 Across Your Environment

Knowing that PKCS#1 v1.5 encryption must be replaced is step one. Finding every place it is used is the harder problem. RSA padding schemes are typically buried inside cryptographic library calls, TLS configurations, HSM key usage policies, and application code. Most organizations have no single inventory of where RSA is in use, let alone which padding scheme each call specifies. A TLS-only audit will miss RSA usage in S/MIME, API authentication, code signing pipelines, and internal services.

CBOM Secure is Encryption Consulting’s cryptographic discovery and inventory platform. It scans across source code repositories, cloud environments, and HSMs to surface every cryptographic asset, including the specific RSA padding scheme tied to each usage. If PKCS#1 v1.5 encryption is present anywhere in your estate, CBOM Secure finds it, maps it to the system and code path using it, and surfaces it as a finding against NIST SP 800-131A compliance.

For organizations managing certificate lifecycle, RSA key usage in certificate profiles is a related surface area. CertSecure Manager tracks certificate profiles across your PKI estate and flags non-compliant algorithm OIDs alongside expiry monitoring.

How Encryption Consulting Can Help

• CBOM Secure: Cryptographic discovery and inventory across code, cloud, and HSMs. Surfaces RSA padding scheme usage, maps to NIST SP 800-131A and FIPS compliance, and provides the inventory baseline needed to plan remediation. Learn more about CBOM Secure.
• CertSecure Manager: Certificate lifecycle management tracking certificate profiles, key usage policies, and algorithm compliance across your PKI estate. Learn more about CertSecure Manager.
• PKI Services: Advisory and implementation support for updating CA configurations, HSM key policies, and TLS settings to current NIST and FIPS requirements, including migration from PKCS#1 v1.5 to OAEP and PSS. Explore PKI Services.
• PQC Advisory Services: RSA padding modernization is a natural part of a broader post-quantum readiness program. Our nine-phase PQC roadmap covers cryptographic inventory, algorithm migration planning, and implementation support aligned to NIST FIPS 203, 204, and 205. Explore PQC Advisory Services.

Conclusion

RSA padding is not a detail. It is the mechanism that makes RSA encryption and signing secure in deployed systems. PKCS#1 v1.5 encryption has been formally disallowed by NIST since December 31, 2023 because its structural design enables oracle attacks demonstrated against real vendor products as recently as 2017. OAEP provides a formally proven, oracle-resistant replacement for RSA encryption. PSS provides a formally proven replacement for RSA signatures.

The path forward: OAEP with SHA-256 for RSA encryption, PSS with SHA-256 for RSA signatures, 2048-bit minimum key sizes (3072 recommended for security past 2030), and a cryptographic inventory program to find remaining PKCS#1 v1.5 encryption usage before it becomes an incident. Organizations planning post-quantum migrations should treat RSA padding modernization as part of the same program.

If you are uncertain where PKCS#1 v1.5 is in use across your environment, reach out to Encryption Consulting to discuss a cryptographic discovery assessment.

Frequently Asked Questions

What is RSA padding and why is it required?

RSA padding is a structured layer added to plaintext before RSA encryption or signing. Raw RSA is deterministic: identical inputs always produce identical outputs, enabling pattern-based attacks. Padding introduces randomness and integrity checks that break this predictability. Omitting it in production is a critical vulnerability.

What is the difference between PKCS#1 v1.5, OAEP, and PSS?

PKCS#1 v1.5 is a legacy scheme for both encryption and signatures (1993), vulnerable to Bleichenbacher attacks, disallowed for encryption by NIST after December 31, 2023. OAEP is the current standard for RSA encryption, formally proven IND-CCA2 secure. PSS is the current standard for RSA signatures, with a tight security reduction to the RSA problem. Use OAEP for encryption, PSS for signatures.

Is PKCS#1 v1.5 still allowed for digital signatures?

For encryption, no: NIST SP 800-131A Rev. 2 disallowed it after December 31, 2023. For signatures, RSASSA-PKCS1-v1_5 is retained for backward compatibility in some protocols (RFC 9963 allows it for legacy TLS 1.3 client keys only, disabled by default). NIST FIPS 186-5 recommends RSASSA-PSS for all new signature implementations.

What is the Bleichenbacher attack and which padding scheme is vulnerable?

Bleichenbacher (1998) exploits structured error responses from PKCS#1 v1.5 padding validation to iteratively decrypt a ciphertext without the private key. The 2017 ROBOT research showed products from seven vendors including F5 (CVE-2017-6168) and Citrix (CVE-2017-17382) were still vulnerable 19 years later. OAEP eliminates this channel entirely.

Which RSA padding scheme should I use for encryption in 2026?

RSAES-OAEP with SHA-256. NIST SP 800-131A Rev. 2 disallowed PKCS#1 v1.5 encryption after December 31, 2023. RFC 8017 requires OAEP for new applications. All major libraries (OpenSSL, Java JCE, Python cryptography) default to or recommend OAEP.

Does the 47-day certificate validity schedule affect RSA padding schemes?

No. The CA/B Forum’s 47-day certificate validity schedule governs certificate lifetime, not cryptographic algorithms. A modernization program addressing certificate automation is however a natural opportunity to audit and remediate RSA padding configurations at the same time.