In cryptography, a padding oracle attack is an attack which is performed using the padding of a cryptographic message. In cryptography, variable-length plaintext messages often have to be padded (expanded) to be compatible with the underlying cryptographic primitive. The attack relies on having a "padding oracle" who freely responds to queries about whether a message is correctly padded or not. Padding oracle attacks are mostly associated with CBC mode decryption used within block ciphers. Padding modes for asymmetric algorithms such as OAEP may also be vulnerable to padding oracle attacks.[1]

## Symmetric cryptography

In symmetric cryptography, the padding oracle attack can be applied to the CBC mode of operation, where the "oracle" (usually a server) leaks data about whether the padding of an encrypted message is correct or not. Such data can allow attackers to decrypt (and sometimes encrypt) messages through the oracle using the oracle's key, without knowing the encryption key.

### Example of the attack on CBC encryption

Suppose the attacker has three ciphertext blocks ${\displaystyle C_{1},C_{2},C_{3}}$ and he wants to decrypt the second block (get plaintext ${\displaystyle P_{2}}$). He only knows that the very last block ${\displaystyle C_{3}}$ is padded correctly and the padding method is PKCS7, which means that the last block is padded with ${\displaystyle n}$ bytes, each equal to n (for example: six bytes, each byte = 0x06).

CBC decryption works as follows: ${\displaystyle P_{i}=D_{K}(C_{i})\oplus C_{i-1},C_{0}=IV.}$ If the attacker changes the last byte of ${\displaystyle C_{1}}$ and sends ${\displaystyle (IV,C_{1},C_{2})}$ to the server, it will affect the whole block ${\displaystyle P_{1}}$ (because of decryption avalanche effect) and the last byte of ${\displaystyle P_{2}}$ (because of XORing operation). Then the server checks the padding of the last decrypted block (which is ${\displaystyle P_{2}}$), and returns whether or not the padding is correct (this check is performed before the actual processing of the plaintext message).

Let ${\displaystyle b_{-1}}$ be the last byte of ${\displaystyle C_{1}}$. The attacker changes it as follows: ${\displaystyle b_{-1}=b_{-1}\oplus z_{-1}\oplus {\text{0x01}}}$, where ${\displaystyle z_{-1}}$ is the guessed value of the last byte of ${\displaystyle P_{2}}$. If ${\displaystyle z_{-1}}$ were a shrewd guess (the exact value of ${\displaystyle P_{2}}$'s last byte) the server will not raise a padding error (because the last byte of ${\displaystyle P_{2}}$ becomes equal to 0x01, which is correct padding). In the other case, the server will report a padding error and the attacker will try the next value of ${\displaystyle z_{-1}}$. In the worst case, he needs to make 255 attempts to find the right value of ${\displaystyle z_{-1}}$, (one guess for every possible byte).

After he knows the last byte of ${\displaystyle P_{2}}$, the attacker can obtain the second-to-last byte of ${\displaystyle P_{2}}$. He changes the last two bytes of ${\displaystyle C_{1}}$: ${\displaystyle b_{-1}=b_{-1}\oplus z_{-1}\oplus {\text{0x02}}}$ and ${\displaystyle b_{-2}=b_{-2}\oplus z_{-2}\oplus {\text{0x02}}}$. Now he tries to find the value ${\displaystyle z_{-2}}$, which results in the correct padding (0x02,0x02). After no more than 255 guesses he will get it and proceed to ${\displaystyle z_{-3}}$ and so on.

If any block consists of 128 bits (AES, for example), which is 16 bytes, the attacker will obtain plaintext ${\displaystyle P_{2}}$ in no more than 255⋅16 = 4080 attempts. This attack costs practically nothing and can be performed in a few seconds (depending on the server's speed).

The original attack was published in 2002 by Serge Vaudenay.[2] The attack was applied to several web frameworks, including JavaServer Faces, Ruby on Rails[3] and ASP.NET[4][5][6] as well as other software, such as Steam gaming client.[7] In 2012 it was shown to be effective against some hardened security devices.[8]

While these earlier attacks were fixed by most TLS implementors following its public announcement, a new variant, the Lucky Thirteen attack, published in 2013, used a timing side-channel to re-open the vulnerability even in implementations that had previously been fixed. As of early 2014, the attack is no longer considered a threat in real-life operation, though it is still workable in theory (see signal-to-noise ratio) against a certain class of machines. As of 2015, the most active area of development for attacks upon cryptographic protocols used to secure Internet traffic are downgrade attack, such as Logjam[9] and Export RSA/FREAK[10] attacks, which trick clients in to using less-secure cryptographic operations provided for compatibility with legacy clients when more secure ones are available. An interesting attack called POODLE[11] (late 2014) combines both a downgrade attack (to SSL 3.0) with a padding oracle attack on the older, insecure protocol to enable compromise of the transmitted data. In May 2016 it has been revealed in CVE-2016-2107 that the fix against Lucky Thirteen in OpenSSL introduced another padding oracle.[12][13]

## References

1. ^ Manger, James. "A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0" (PDF). Telstra Research Laboratories.
2. ^ Serge Vaudenay (2002). Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS... (PDF). EUROCRYPT 2002.
3. ^ Juliano Rizzo; Thai Duong (2010-05-25). Practical Padding Oracle Attacks (PDF). USENIX WOOT 2010.
4. ^ Thai Duong; Juliano Rizzo (2011). Cryptography in the Web: The Case of Cryptographic Design Flaws in ASP.NET (PDF). IEEE Symposium on Security and Privacy 2011.
5. ^ Dennis Fisher (2010-09-13). "'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps". Threat Post.
7. ^ "Breaking Steam Client Cryptography". Steam Database. Retrieved 2016-05-01.
8. ^ Romain Bardou; Riccardo Focardi; Yusuke Kawamoto; Lorenzo Simionato; Graham Steel; Joe-Kai Tsay (2012), Efficient Padding Oracle Attacks on Cryptographic Hardware (PDF)
9. ^ Matthew Green; Nadia Heninger; Paul Zimmerman; et al. (2015), Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice (PDF). For further information see https://www.weakdh.org.
10. ^ Matthew Green (2015-03-03). "Attack of the week: FREAK (or 'factoring the NSA for fun and profit')".; see https://www.freakattack.com for more information.
11. ^ Matthew Green (2014-10-14). "Attack of the week: POODLE".; for further information, see https://www.poodle.io
12. ^ OpenSSL Security Advisory [3rd May 2016], 2016-05-03
13. ^ Yet Another Padding Oracle in OpenSSL CBC Ciphersuites, Cloudflare, 2016-05-04