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

If you work with security systems, APIs, or cryptographic libraries, you have probably come across RSA encryption. RSA is one of the most widely used public key cryptographic algorithms in the world. It powers TLS connections, digital signatures, certificate-based authentication, and secure key exchange across virtually every industry. But here is something that does not always get explained well: RSA on its own is not safe to use directly. It needs padding.

Padding is what makes RSA encryption and digital signatures secure in practice. Without it, attackers can exploit predictable patterns in the encrypted data. Raw RSA is deterministic, meaning the same input always produces the same output. That predictability creates exploitable patterns that attackers have known how to abuse for decades. Padding schemes break that predictability by introducing randomness and structure before the data is encrypted or signed.

There are three main RSA padding schemes in use today: PKCS#1 v1.5, OAEP, and PSS. Each was designed for a specific purpose, and each carries a very different security profile. Using the wrong one, or using an outdated one in a new system, is not a minor configuration issue. It is a vulnerability. This blog explains how each scheme works, where it belongs, and what your organization should be doing right now.

What Is RSA Padding and Why Is It Necessary?

When you encrypt data using raw RSA, the same message always produces the same ciphertext. That predictability is a serious problem. An attacker watching encrypted traffic can spot patterns and use them to learn things they should not know.

Padding fixes this by adding structure, randomness, and integrity checks to the message before encryption. This makes every encryption result different, even when the input is the same. Think of padding as a protective layer that RSA needs before it is safe to deploy.

Padding is not optional. Using RSA without padding in a production system is a critical security vulnerability. There are three main RSA padding schemes used in practice: PKCS#1 v1.5, OAEP, and PSS. Each was built for a specific purpose, and each has its own security profile.

Understanding PKCS#1 v1.5: How It Works and Its Limitations

PKCS#1 v1.5 was introduced in 1993 and became the default RSA padding scheme for many years. It is still found in a large number of legacy systems, TLS implementations, and older enterprise software. If you are auditing or maintaining older infrastructure, you will likely run into it.

For encryption, PKCS#1 v1.5 formats the message before it is encrypted. It starts with a fixed byte sequence, followed by non-zero random bytes, then a zero byte, and finally the message itself. The random bytes help make each ciphertext different, and the structure lets the recipient find and remove the padding after decryption. For digital signatures, the format uses a different byte pattern and includes a hash identifier.

The problem is that in 1998, researcher Daniel Bleichenbacher discovered what is now called the Bleichenbacher Attack. This attack works by sending a large number of crafted ciphertexts to a server and watching for a specific response: whether the padding was valid or not. By using that response as a signal, an attacker can eventually decrypt a message without ever having the private key.

What makes this especially concerning is that the attack still works today. A 2017 research effort called ROBOT (Return of Bleichenbacher’s Oracle Threat) found that major vendors including F5, Citrix, and Palo Alto Networks had products that were still vulnerable, nearly two decades after the original discovery.

Limitations of PKCS#1 v1.5:

• Vulnerable to Bleichenbacher padding oracle attacks
• Its structure creates error signals that attackers can exploit
• No formal security proof against modern attack models
• Should not be used in any new encryption implementation

OAEP Explained: The Modern Standard for RSA Encryption

OAEP, which stands for Optimal Asymmetric Encryption Padding, was introduced in 1994 and is now part of PKCS#1 v2.0. It is the recommended approach for RSA encryption today. Unlike PKCS#1 v1.5, OAEP has a formal security proof, meaning its security is mathematically tied to the difficulty of breaking RSA itself.

OAEP works by using a mask generation function (MGF) based on a cryptographic hash, usually SHA-256, to mix a random seed into the message before encryption. This process is more thorough than just adding random bytes at the front. The randomness is built deeply into the structure of the padded block. With OAEP, changing a single bit in the ciphertext produces a completely unpredictable result when decrypted. This removes the structured error signals that the Bleichenbacher Attack relies on.

In practice, when you configure an HSM, set a TLS policy, or review a cryptographic library, you should confirm that RSA encryption operations are using OAEP with a secure hash algorithm. If PKCS#1 v1.5 is still specified for encryption in a new system, that is worth flagging immediately.

Why OAEP is the right choice for encryption:

• Proven secure under the random oracle model
• Eliminates the error channels used in Bleichenbacher attacks
• Produces different ciphertext each time, even for the same input
• Supported in all modern cryptographic libraries
• Required by NIST guidelines for RSA encryption

PSS Explained: Secure Padding for RSA Digital Signatures

PSS stands for Probabilistic Signature Scheme, and it was designed specifically for RSA digital signatures. It works alongside OAEP but serves a different purpose. While OAEP handles encryption, PSS handles signing. Both share a similar design approach, which is that security should be formally provable, not just assumed.

One point that often causes confusion: PKCS#1 v1.5 was used for both encryption and signatures. PSS is a dedicated signature scheme. You would not use PSS for encryption, just as you would not use OAEP for signatures. Each scheme has its role.

When signing with PSS, the scheme generates a random salt and hashes it together with the message digest. This result is then encoded using a masking function. The verifier recovers the salt, recomputes the hash, and checks that everything matches. Two signatures over the same message will look different, but both will verify correctly.

Breaking PSS is mathematically equivalent to breaking RSA itself. PKCS#1 v1.5 signatures cannot make that claim. For organizations working toward FIPS 186-5 or operating under SOC 2 or ISO 27001 frameworks, PSS is the recommended or required scheme.

When to use PSS:

• Any new implementation requiring RSA digital signatures
• Code signing, certificate issuance, and document integrity workflows
• Compliance with FIPS 186-5 or NIST SP 800-131A
• Replacing legacy PKCS#1 v1.5 signature schemes in existing systems

PKCS#1 v1.5 vs. OAEP vs. PSS: Key Differences and Best Use Cases

Here is a straightforward comparison of all three schemes.

PKCS#1 v1.5 was built for both encryption and signatures, but it carries significant security risks today. Its security level is weak by modern standards, it uses minimal randomness, and it is highly vulnerable to the Bleichenbacher Attack. It should only be kept in systems where replacing it is not yet possible, and even then, migration should be planned.

OAEP is built exclusively for encryption. It is the modern, secure standard, backed by formal proofs and supported everywhere. It introduces proper randomness through a seed, which eliminates the attack surface that PKCS#1 v1.5 left open. All new RSA encryption should use OAEP.

PSS is built exclusively for digital signatures. Like OAEP, it uses randomness through a salt value and has a tight security proof tied directly to RSA. It is the correct choice for any new RSA signature implementation and is required under several major compliance frameworks.

The conclusion is simple: PKCS#1 v1.5 should not appear in any new cryptographic design. Use OAEP for RSA encryption. Use PSS for RSA digital signatures. This is not a matter of preference; it reflects current cryptographic research and regulatory guidance.

For many organizations running mixed environments, the bigger challenge is finding where these schemes are being used, not fixing them. You cannot address a problem you have not found. Cryptographic agility assessments and PKI health checks are the most reliable way to surface these issues before they become incidents.

How Encryption Consulting Can Help

Knowing that PKCS#1 v1.5 should be replaced is straightforward. Finding every place, it is being used across your environment is a different challenge entirely. Most organizations running mixed infrastructure have RSA padding schemes spread across cryptographic libraries, APIs, HSMs, TLS configurations, and legacy applications; and no clear picture of where each one is. That is the problem CBOM Secure is built to solve.

CBOM Secure is Encryption Consulting’s cryptographic discovery and inventory solution. It continuously scans across your code, cloud environments, and HSMs to surface every cryptographic asset in use, including the algorithms, padding schemes, and key configurations behind them. If PKCS#1 v1.5 is being used somewhere in your environment, it will find it.

Here is what it covers in the context of what this blog addresses:

Cryptographic Discovery Across Code and Infrastructure: CBOM Secure identifies RSA usage across your environment and maps the padding schemes tied to each implementation, so you know exactly where OAEP and PSS need to replace legacy configurations.

Quantum Risk Scoring: Beyond padding schemes, it scores your cryptographic posture against quantum risk, helping you prioritize what to address first based on actual exposure rather than guesswork.

Compliance Alignment: CBOM Secure maps your cryptographic inventory against frameworks including FIPS, CMMC, and PCI DSS, surfacing configurations that fall outside compliance requirements, including deprecated padding schemes flagged under NIST SP 800-131A.

Cryptographic Agility Support: Once you know what is in your environment, CBOM Secure gives you the inventory foundation needed to plan migrations methodically, which is exactly what building cryptographic agility requires.

For organizations that have identified the need to audit and modernize their RSA implementations, CBOM Secure is the starting point that makes the rest of the work possible.

Conclusion

RSA padding schemes might seem like a narrow topic, but they sit at the center of how public key cryptography actually works in real systems. Getting them right is not optional. Choosing PKCS#1 v1.5 for a new encryption implementation is not a small mistake; it opens the door to a class of attacks that have been known and actively exploited for over two decades.

The path is straightforward: use OAEP for RSA encryption and PSS for RSA digital signatures. Audit your existing systems for PKCS#1 v1.5. Build in cryptographic agility so that future migrations do not require starting from scratch.