Does a padding oracle have the encryption key? Where in real life do I see such an oracle?

Question

So after some searching, I kinda know the attack procedure of altering bit by bit. But I'm still confused how this is possible. If I understand it correctly, the attacker never has the key, or tries to iterate keys. So since the oracle can check the padding, I guess itself has the encryption key?

What is a real life oracle example I can see? I know this should be well patched nowadays, but what were affected before patching? I read that some kinds of web servers were impacted most, but what part of the server has this kind of oracle?

Answer 1

There are many examples of real padding-oracle attacks in practice. SSL/TLS is arguably the most famous example. However, they appear everywhere. In a paper by Practical Padding Oracle Attacks by Rizzo and Duong they find a number of interesting examples. But, they are really all over the place.

Answer 2

In cryptography Oracle models a party in a given protocol that can answer to some precise questions. It is called Oracle because as the mythological Oracles, we don't know how they get the answer. This bit is very important in proven security as it allows to model a generic attacker and prove a protocol correctness against many possibles attackers.

In real life, an Oracle is usually given by a server that knows the secret key (or any other secret data) and can compute some function on the challenge ciphertext. The way the Oracle conveys the answer could vary: an direct message, an error message, a crash, ...

The typical school case is a TLS server, it knows the secret key and gives different errors message depending on padding, integrity, ... An other example could be a license checking routine: different error messages if the file is bad formatted or badly signed or ... An (unlikely) example could be your friend telling you "Yo, the PGP encrypted mail you sent me, gave me an error padding, could you send it one more time?"

Answer 3

You could look up the POODLE attack on SSL3 (pdf). It affected several implementations, but apparently e.g. OpenSSL 1.0.1i and earlier were affected.

The idea is that an attacker can send modifier ciphertext for decryption (by a server which does know the key) and observe whether that results in correct padding. The pdf linked above outlines how it can be used in a browser context:

In the web setting, this SSL 3.0 weakness can be exploited by a man­-in-the-middle attacker to decrypt “secure” HTTP cookies, using techniques from the BEAST attack [BEAST]. To launch the POODLE attack (Padding Oracle On Downgraded Legacy Encryption), run a JavaScript agent on evil.com (or on example.com) to get the victim’s browser to send cookie­-bearing HTTPS requests to example.com, and intercept and modify the SSL records sent by the browser in such a way that there’s a non­-negligible chance that example.com will accept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookies.