When you encrypt data with RSA, you do not just apply the RSA mathematical operation to the raw data. You first apply padding, which adds structure and randomness to the message before encryption. The choice of padding is not a minor detail, it is the difference between secure and catastrophically insecure RSA.
Let's look at why RSA needs padding, the two main padding schemes (PKCS1 v1.5 and OAEP), and why your choice matters.
Why RSA Needs Padding at All
Raw RSA (also called textbook RSA) is the mathematical operation without any padding: ciphertext = message^e mod n. This is simple but catastrophically insecure for several reasons:
**It is deterministic.** The same plaintext always produces the same ciphertext. If two people encrypt the same message, the ciphertexts are identical. An attacker can recognize repeated messages and perform dictionary attacks.
**It is malleable.** An attacker can modify the ciphertext in ways that produce predictable changes to the plaintext. For example, multiplying the ciphertext by 2^e mod n doubles the plaintext. This allows an attacker to modify encrypted messages without knowing the content.
**It is vulnerable to chosen-ciphertext attacks.** An attacker can submit modified ciphertexts to the decryption system and use the responses to gradually recover the plaintext.
**Small messages are trivially broken.** If the message is a small number (like a symmetric key), an attacker can compute all possible ciphertexts and compare. For a 128-bit AES key encrypted with a 2048-bit RSA key without padding, the attacker just computes key^e mod n for all possible keys.
Padding solves all of these problems by adding randomness and structure to the message before encryption.
PKCS1 v1.5 Padding
PKCS1 v1.5 is the original RSA padding standard, defined in RFC 2313. It was the standard for many years and is still widely used in existing systems.
**How it works (for encryption):** 1. The message is padded to the full size of the modulus. 2. The padding starts with bytes 00 02 (for encryption). 3. Random non-zero padding bytes follow. 4. A 00 byte separates the padding from the message. 5. The message comes last.
The format is: 00 02 [random padding] 00 [message]
**Pros:** - Simple and widely supported. - Fast to compute. - Used in many existing systems and standards (including older TLS versions).
**Cons:** - Vulnerable to Bleichenbacher attacks (padding oracle attacks). - The padding structure is predictable enough that an attacker can exploit it.
The Bleichenbacher Attack
The Bleichenbacher attack is the reason PKCS1 v1.5 is no longer recommended for encryption. Here is how it works:
The attack exploits the fact that the PKCS1 v1.5 padding has a specific structure (starts with 00 02). When the server decrypts a ciphertext, it checks whether the padding is valid. If the padding is invalid, it returns an error. If the padding is valid, it processes the message.
This creates a padding oracle: the server tells the attacker whether the padding is valid or not. By sending many modified ciphertexts and observing which ones produce valid padding, the attacker can gradually narrow down the possible plaintext values.
The original attack required millions of queries, but modern variants (like the ROBOT attack, which stands for "Return Of Bleichenbacher's Oracle Threat") can recover plaintext in a few thousand queries. This attack has been demonstrated against real systems, including Facebook, PayPal, and Amazon.
Modern TLS implementations include countermeasures against Bleichenbacher attacks, but these are patches on an inherently vulnerable scheme. The proper fix is to use OAEP.
OAEP (Optimal Asymmetric Encryption Padding)
OAEP was designed to address the weaknesses of PKCS1 v1.5. It is defined in RFC 8017 and is the recommended padding scheme for RSA encryption.
**How it works:** 1. The message is hashed and combined with a random seed using a mask generation function (MGF). 2. The seed is masked using the hash of the masked message. 3. The result is padded to the modulus size.
The details involve a Feistel network and a hash function (typically SHA-1 or SHA-256). The result is a padded message that is indistinguishable from random.
**Pros:** - Provably secure under the random oracle model. There is a mathematical proof that OAEP is secure if the underlying RSA problem is hard. - Not vulnerable to Bleichenbacher attacks. The padding structure does not leak information through padding validity. - Non-deterministic: the same plaintext produces different ciphertexts each time due to the random seed.
**Cons:** - Slightly more complex to implement. - Reduces the maximum message size by about 42 bytes (for SHA-1) or more (for SHA-256). - Not as universally supported as PKCS1 v1.5 (though all modern libraries support it).
No Padding: The Worst Option
Using RSA without any padding (textbook RSA) is never appropriate for security purposes. It is deterministic, malleable, and vulnerable to a wide range of attacks. Any system using raw RSA should be considered broken.
Unfortunately, some libraries allow raw RSA operations for compatibility or testing purposes. If you are using a library, make sure you are specifying OAEP or PKCS1 padding. If you see an option for "no padding" or "raw" RSA, do not use it for anything security-related.
For Signing: PSS vs PKCS1 v1.5
The padding discussion for signing is similar but slightly different:
**PKCS1 v1.5 for signing** is still considered secure in practice. The Bleichenbacher attack applies to encryption, not signing. Many existing systems use PKCS1 v1.5 for signatures, and it is not considered vulnerable in the same way.
**PSS (Probabilistic Signature Scheme)** is the modern recommended standard for signing. Like OAEP, it uses a random salt and a mask generation function, making it provably secure. PSS is preferred for new systems.
For new applications, use PSS for signing and OAEP for encryption. For existing applications using PKCS1 v1.5 for signing, there is no urgent need to migrate, but PKCS1 v1.5 for encryption should be replaced with OAEP.
Practical Recommendations
1. **For new RSA encryption**: Always use OAEP. Do not use PKCS1 v1.5 for new encryption code. 2. **For new RSA signing**: Use PSS. It is the modern standard. 3. **For existing PKCS1 v1.5 encryption**: Plan a migration to OAEP. The Bleichenbacher vulnerability is real. 4. **For existing PKCS1 v1.5 signing**: No urgent need to migrate, but PSS is preferred for new code. 5. **Never use raw RSA** (no padding) for any security purpose. 6. **Use a well-tested library** that implements padding correctly. Do not implement padding yourself.
The Bottom Line
Padding is not an optional add-on for RSA. It is an essential security measure that prevents a wide range of attacks. The choice of padding scheme directly affects the security of your RSA implementation.
Use OAEP for encryption and PSS for signing. These are the modern standards, provably secure, and not vulnerable to the attacks that affect PKCS1 v1.5. Never use raw RSA without padding.
For more on RSA, read our RSA encryption explained guide and our RSA signing vs encryption guide. You can also try RSA with different padding schemes using our RSA Encrypt/Decrypt tool.
