I understand that the MAC-then-encrypt approach is susceptible to several attacks including the so called padding oracle attack. I understand that in this attack the attacker modifies the padding and listens for the errors caused which he can then use to infer the plain text. Can someone please explain the attack in layman's terms?

I would like to have the following addressed in the answers:

  1. How does the attacker listen for these errors? Does it mean the attacker is assumed to have some malware installed on the host machine doing the decryption?
  2. Is the attack based on a cipher text captured by the attacker, or a chosen cipher text selected by the attacker?

Quoting the answer here:

Padding Oracle attacks are mainly a problem in cases, where e.g. an encrypted message is modified and send to a target. These attacks try to measure the difference when decrypting and validating the message.

The steps are:

  1. decrypting the message
  2. checking the padding > error if wrong
  3. checking or processing the data > error if wrong or format corruption detected

The padding oracle attacks try to measure timing differences between step (2) and (3) or utilizes different error messages.

So the information leakage that enables the attack comes in the form of either timing differences or is present in the error messages that the server returns as a response to the malicious query.

  • $\begingroup$ How does one measure those timing differences in a practical attack scenario? Does it assume some malware on the server listening out for the encryption processes? If so, this seems like a very strong assumption.The other option would be that the attacker is intercepting or listening to back and forth traffic on the network, however, I dont see how these timings would be accurately measurable. Any ideas on how this attack would work in a realistic setting? $\endgroup$
    – Minaj
    Jul 4 '16 at 3:32
  • $\begingroup$ @Minaj It's actually with the latter, using the timing of traffic on the network. Network timing is noisy but, with large numbers of requests the noise can be filtered out. You are correct that granting the adversary malware on the machine would be a pointlessly strong assumption (if they had that, there are significantly easier ways to find the key.). As for "how", you would just use your programming languages time measuring faculties when sending/receiving requests at the socket layer. $\endgroup$
    – Ella Rose
    Jul 4 '16 at 5:38
  • 1
    $\begingroup$ @Minaj, also note that network timing is not the only way to verify a hit on the padding. Anything that the other device does differently suffices (for example an automated, attacker controlled file retrieval also would do, such as here). $\endgroup$
    – SEJPM
    Jul 4 '16 at 21:48

Basically the padding oracle attack works by changing specific bytes so that the padding matches the expected padding and therefore padding length. Once a byte is found that correctly generates a (not specifically the) padding then then plaintext can be found by XOR'ing this byte with the known information about the byte at that position.

The receiver just needs to indicate if the unpadding succeeded or not. It can do so by returning different error messages or by responding earlier if the padding fails. Timing differences can even be found on relatively slow or randomized connections by utilizing statistics (although that requires significantly more testing per byte).

Malware could be used to find out specific CPU timings, but that's generally not required because of the above. The attacker does need to be able to submit chosen ciphertext to the receiver or the attack fails.

The attack can easily be thwarted by verifying an authentication tag / MAC (securely) over the IV and ciphertext.

A more complete description of padding oracle attacks (youtube video) can be found here.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.