← Back to Blog Threats

Padding Oracle Attacks: From PKCS#7 to TLS

12 min read

In 2002, Serge Vaudenay published a paper that quietly demolished the assumption that you could use a block cipher in cipher block chaining mode, add PKCS#7 padding, and have a secure encryption scheme. The paper, "Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...", showed that any system that distinguished between "valid padding" and "invalid padding" gave an attacker a tool to decrypt arbitrary ciphertexts byte by byte. The attack only required the ability to submit modified ciphertexts and observe a single bit of feedback per query.

Padding oracle attacks have a long shadow. POODLE in 2014 broke SSL 3.0 worldwide. Lucky Thirteen in 2013 broke CBC ciphersuites in TLS. Numerous CVEs in commercial products from 2003 onward traced back to the same fundamental issue. The technique is so reliable that "padding oracle" became a standard tool in cryptanalysis textbooks and practical attack manuals. Understanding it is essential to understanding why the modern cryptographic stack moved decisively to authenticated encryption modes like AES-GCM and ChaCha20-Poly1305.

This post walks through the mechanics of padding oracle attacks, the specific real-world breaks they enabled, and the design choices that have eliminated the threat from properly built modern protocols.

How CBC Mode and PKCS#7 Padding Work

To understand the attack, you first need to understand the target. Cipher block chaining mode encrypts data in blocks of fixed size, typically 16 bytes for AES. Each plaintext block is XOR'd with the previous ciphertext block before being encrypted. The first block is XOR'd with an initialization vector. Decryption reverses the process: each ciphertext block is decrypted, then XOR'd with the previous ciphertext block to recover the plaintext block.

CBC requires plaintext to be a multiple of the block size. PKCS#7 padding solves the alignment problem. If the last block is short by N bytes, you append N copies of the byte N. If the plaintext is already a multiple of the block size, you append a full block of 16 bytes, each containing the value 16. On decryption, you read the value of the last byte, verify that it represents a valid padding length, check that the last N bytes are all equal to N, and strip them.

The two checks for validity, that the last byte is between 1 and 16, and that the trailing bytes match, are the source of the vulnerability. They give the attacker exactly the information they need.

The Attack: One Bit at a Time

Vaudenay's insight was that an attacker who can submit ciphertexts and observe whether decryption succeeds or fails on padding validation can decrypt arbitrary blocks. The attack works against any system that exposes this distinction, whether through error messages, response timing, or downstream behavior.

Consider a target ciphertext consisting of two blocks, IV and C1, that decrypts to plaintext P1. The attacker wants to learn the last byte of P1. They construct a forged ciphertext using a chosen IV', call it IV', and the original C1. They submit (IV', C1) for decryption. The decryption produces a plaintext block P1' that equals D(C1) XOR IV'. The last byte of P1' is the last byte of D(C1) XOR the last byte of IV'.

The attacker tries each possible value for the last byte of IV', from 0 to 255. For one of these 256 values, the last byte of P1' will be 0x01, which is valid PKCS#7 padding for a single byte. The decryption succeeds. For the other 255 values, the padding check fails. The attacker knows they have hit the right value when they observe a successful decryption.

Once the attacker knows the value of the last byte of IV' that produces 0x01, they compute the last byte of D(C1) by XORing. They then XOR with the original IV's last byte to recover the last byte of P1. The attack moves on to the second-to-last byte, this time forcing both the last and second-to-last bytes of P1' to be 0x02 0x02. Continuing this way, the attacker recovers the entire block in roughly 128 queries on average per byte, or about 2048 queries per block.

The attack generalizes to any block in the ciphertext. By manipulating the previous ciphertext block, the attacker can target any plaintext block.

What Makes a Padding Oracle

The attack needs a yes-or-no signal that distinguishes valid padding from invalid padding. The signal can come from anywhere.

Explicit error messages were the original signal. A protocol that returned "padding error" for invalid padding and a different error for other failures gave the attacker exactly the bit they needed. Many older HTTPS server implementations had this pattern.

Timing differences served as a signal in Lucky Thirteen and other refined attacks. Even when the explicit error response was uniform, the time taken to decrypt and process the message depended on whether padding validation completed before or after MAC validation. The TLS specification at the time mandated MAC-then-encrypt ordering, which created exactly this vulnerability.

Downstream observations were exploited in attacks on web applications. A server that called a database query only when padding was valid would take measurably longer or generate measurably different network traffic when handling valid versus invalid padding.

Connection behavior gave attackers a signal in older TLS versions where invalid padding caused the connection to be torn down differently than other errors.

POODLE: October 2014

POODLE, formally CVE-2014-3566, was published by Bodo Möller, Thai Duong, and Krzysztof Kotowicz at Google. The acronym stood for Padding Oracle On Downgraded Legacy Encryption. The attack exploited the fact that SSL 3.0 had no specification for the bytes used as padding beyond the last byte. Implementations did not check that the padding bytes were any specific value, so the attacker did not need to find a specific byte pattern, just a byte that happened to land in a valid position.

The downgrade aspect was equally important. Modern browsers in 2014 supported TLS 1.0, 1.1, and 1.2, but they could fall back to SSL 3.0 if the handshake suggested the server only supported the older protocol. An attacker on the network could force this fallback by interfering with handshake messages, then exploit the SSL 3.0 padding oracle to decrypt cookies and session tokens in the encrypted traffic.

The fix was to disable SSL 3.0. Browser vendors removed support over the following months. The TLS_FALLBACK_SCSV mechanism, defined in RFC 7507, prevented downgrade attacks against more capable clients and servers. By 2015, SSL 3.0 was effectively dead on the public Internet.

Lucky Thirteen: February 2013

Nadhem AlFardan and Kenneth Paterson published "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols" at IEEE S&P 2013. The attack targeted CBC ciphersuites in TLS 1.0 through 1.2. Unlike POODLE, Lucky Thirteen worked against fully patched TLS implementations that did the right kind of error handling. The vulnerability was timing rather than explicit error response.

The TLS record format had the layout MAC followed by padding. On decryption, the server first stripped the padding, then checked the MAC over the remaining plaintext. The MAC check time depended on how much data was hashed. The padding length affected the data length. The attacker could distinguish, through nanosecond-scale timing, between cases where padding was valid and cases where padding was invalid but the bytes happened to look like a particular pattern.

The fix was complex. OpenSSL added a constant-time MAC verification path that performed the full computation regardless of padding validity. The fix was significant enough that some commercial cryptographic libraries did not deploy a complete patch for several years. The long-term fix was to deprecate CBC ciphersuites and move TLS to AEAD modes. TLS 1.3, finalized as RFC 8446 in 2018, removed CBC mode entirely.

Other Notable Padding Oracles

The full history is dense. Notable cases include:

CVE-2003-0078 in OpenSSL exposed a padding oracle in the TLS implementation through error messages. The fix, released in 2003, was an early example of moving to constant-time error handling.

CVE-2009-3555 was the TLS renegotiation vulnerability, which while not a padding oracle directly, used similar implementation-level distinctions to enable an attack.

CVE-2013-0169 was the formal CVE assigned to Lucky Thirteen.

CVE-2014-3566 was POODLE.

CVE-2016-2107 was a padding oracle in OpenSSL's AES-NI assembly, where a check that should have been constant-time leaked timing information about CBC padding.

CVE-2018-12404 covered a class of vulnerabilities in TLS implementations that retained CBC support and had subtle padding handling issues.

The pattern is clear. Any time a protocol has an error path that distinguishes padding errors from other errors, even if the distinction is purely in timing, attackers find ways to exploit it. The only durable fix is to remove the conditions that create the oracle.

The Modern Answer: AEAD

Authenticated encryption with associated data, AEAD, eliminates the entire class of padding oracle attacks. AEAD ciphers like AES-256-GCM and ChaCha20-Poly1305 do not use PKCS#7 padding because they do not require plaintext to be a multiple of any block size. They produce a ciphertext exactly the same length as the plaintext, plus a fixed-size authentication tag, typically 16 bytes.

Decryption of an AEAD ciphertext is atomic. The cipher computes the authentication tag from the ciphertext and any associated data, compares it in constant time to the expected tag, and either returns the plaintext or fails. There is no padding to validate, no separate MAC check, no opportunity for timing differences between validation steps.

When TLS 1.3 was designed, the working group explicitly removed all CBC modes from the supported ciphersuites. The only allowed ciphers in TLS 1.3 are AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, AES-128-CCM, and AES-128-CCM-8, all AEAD modes. The decision was driven by the long history of padding oracle attacks against CBC mode.

In QNSQY, the ML-KEM and X25519 shared secrets are combined with BLAKE3, and HKDF-SHA3-256 derives the file's AES-256-GCM key (or XChaCha20-Poly1305 key) and per-chunk nonces from the result and a fresh random salt. Both are AEAD modes without padding, so there is no padding to probe and no MAC-ordering question: changing a chunk's ciphertext, nonce, tag or associated data makes that chunk fail authentication. A header MAC and key commitment also let QNSQY detect a wrong key or a tampered header before it decrypts anything.

To understand AEAD modes in depth, see AES-256-GCM Explained. For the broader question of why oracle behavior must be eliminated from cryptographic implementations, see Decryption Oracles.

What About Padding Oracle Attacks Today

The Lucky Thirteen and POODLE attacks specifically targeted protocols that no longer dominate. SSL 3.0 is gone. CBC ciphersuites are deprecated in TLS and removed in TLS 1.3. The attack surface for traditional padding oracles has shrunk dramatically.

That does not mean the underlying lesson is obsolete. Implementations of newer protocols can still introduce oracle behavior in unexpected places. Database libraries that handle encrypted column data, file formats with custom padding, and custom protocols built on top of CBC for compatibility reasons remain potential targets.

The 2017 ROBOT attack, which revisited Bleichenbacher's 1998 RSA-PKCS#1 v1.5 padding oracle, found that 27 of 30 sampled high-traffic websites were still vulnerable. The fix had been known for two decades, but legacy code paths remained in production. The lesson is that oracle vulnerabilities can persist long after the cryptographic community considers them solved.

In the post-quantum era, the question is whether ML-KEM and similar schemes can have analogous implementation-level oracles. The Fujisaki-Okamoto transform that ML-KEM uses provides implicit rejection, which means malformed ciphertexts produce a deterministic pseudo-random output rather than an explicit error. This eliminates the most direct form of oracle. Implementation-level timing leaks are still possible if the FO transform is implemented carelessly, which is why the NIST reference implementations and the Wycheproof test vectors include constant-time and timing-resistance test cases.

How to Avoid Building New Oracles

The general guidance is to use AEAD for all encryption and to avoid any custom protocol design that requires distinguishing different kinds of decryption failure. Specific implementation guidance includes:

Use one error path for all decryption failures. The error message, response code, log entry, and timing should all be uniform regardless of which check failed.

Use constant-time comparison for all integrity checks. The CRYPTO_memcmp function, the subtle::ConstantTimeEq trait in Rust, or equivalent should be used for any byte-string comparison involving secret data.

Verify integrity before processing plaintext. Decrypt-then-verify is wrong. AEAD natively provides verify-then-decrypt semantics.

Avoid PKCS#1 v1.5 padding for new RSA deployments. Use OAEP for encryption and PSS for signing.

Avoid CBC mode entirely for new designs. If legacy compatibility forces CBC, use the encrypt-then-MAC construction with HMAC and constant-time MAC verification.

For protocol design, the lesson is that any optional or fallback mode for older crypto is a potential downgrade path. SSL 3.0 lived long after it was deprecated because clients and servers retained fallback support. Modern protocols like TLS 1.3 explicitly removed the fallback paths.

FAQ

Are padding oracle attacks still relevant in 2025? Direct attacks against TLS are largely solved. Custom protocols, file formats, and library code can still have padding oracles. Whenever you see a CBC mode implementation, ask whether the validation is constant-time and whether all error paths are uniform.

Does AES-GCM have any analog of padding oracle attacks? GCM authenticates the ciphertext directly without padding. There is no padding validation step that could leak information. GCM does have its own gotchas, particularly around nonce reuse, but padding oracles are not among them.

What is the difference between a padding oracle and a decryption oracle? A padding oracle is a specific kind of decryption oracle that leaks information about whether the decrypted plaintext has valid padding. Both are forms of IND-CCA insecurity, but padding oracles are the most common implementation-level instance.

Can post-quantum schemes have padding oracles? Not in the same form. ML-KEM does not use byte-level padding because it operates on polynomial coefficients. The implicit rejection in the FO transform eliminates the analog of the padding-error response. Implementation-level timing leaks are still possible and require constant-time implementation.

Why did it take so long to fix CBC mode in TLS? Backward compatibility. Removing CBC ciphersuites would break older clients and older servers. The deprecation took roughly a decade, from the first published timing attacks in the mid-2000s through TLS 1.3 in 2018.

Sources

Vaudenay, S. "Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS..." EUROCRYPT 2002. https://www.iacr.org/cryptodb/data/paper.php?pubkey=2117
AlFardan, N. and Paterson, K. "Lucky Thirteen: Breaking the TLS and DTLS Record Protocols." IEEE S&P 2013. http://www.isg.rhul.ac.uk/tls/Lucky13.html
Möller, B., Duong, T., and Kotowicz, K. "This POODLE Bites: Exploiting the SSL 3.0 Fallback." 2014. https://www.openssl.org/~bodo/ssl-poodle.pdf
CVE-2014-3566, CVE-2013-0169, CVE-2016-2107, CVE-2003-0078. https://cve.mitre.org/
Rescorla, E. "The Transport Layer Security (TLS) Protocol Version 1.3." RFC 8446. https://www.rfc-editor.org/rfc/rfc8446
Moeller, B. and Langley, A. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks." RFC 7507. https://www.rfc-editor.org/rfc/rfc7507

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY