0

I have gone through this question but still unable to grasp the concept of Padding Oracle Padding Oracle: Why should padding be 0x01?

My question is if we say $P_i=D_k(C_i) \oplus \mathit{IV}$

Shouldn't this equation becomes invalidated when we try to change the last bits of $\mathit{IV}$, it becomes $\mathit{IV}'$?

I have read numbers of articles but unable to grasp the exact working of this attack, like how we are brute-forcing or taking random values of IV and expecting the $D_k(C_i)$ would remain same?

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
Johnny
  • 57
  • 1
  • 6

1 Answers1

2

TL;DR: the known change of the plaintext to an also known value - a valid padding - gives away the original plaintext.


... $P_i=D_k(C_i) \oplus \mathit{IV}$: Shouldn't this equation becomes invalidated when we try to change the last bits of $\mathit{IV}$, it becomes $\mathit{IV}'$?

This formula only goes for the first block of ciphertext: $P_0 = \mathit{IV} \oplus D_k(C_0)$ (I've put the IV in front as that's more logical, and XOR is associative, so mathematically speaking the order doesn't matter). For all the other blocks the operation is $P_i = C_{i-1} \oplus D_k(C_i)$.

Of course, the value of $P_i$ will be different if any of the values gets changed within the formula. However, a padding oracle attack relies on this fact.

Let's assume a very simple plaintext smaller than a single block for now. We can then first try and increase the final byte of the IV until the unpadding succeeds. This is very likely value $\mathtt{01}$, as that would enable the unpadding to succeed. The only time that this isn't the case is if the final plaintext consisted of a valid different padding, and the padding size was already $\mathtt{01}$ - it will however be easy to find this out as the attack would stop working later on.

So what does this tell us? Well, it means that if the final plaintext byte was changed from whichever value it had to $\mathtt{01}$. How much was it changed? Well it was changed as much as the final byte of the IV was changed. In other words, say that it was part of the padding $\mathtt{03 03 03}$ then the change $IV_{B15} \oplus IV_{B15}' = \mathtt{02}$ would succeed when it was unpadded (as $\mathtt{03} \oplus \mathtt{02} = \mathtt{01}$). Of course, that would mean that the original plaintext byte was indeed $\mathtt{03}$, i.e. $P_{B15} = P'_{B15} \oplus IV_{B15} \oplus IV'_{B15}$ and we know all those three values.

Say that the $IV_{B15}$ was $\mathtt{D2}$, then the tested value $IV'_{B15}$ was $\mathtt{D0}$ to get $P'_{B15}$ to $\mathtt{01}$, so $P_{B15} = \mathtt{01} \oplus \mathtt{D2} \oplus \mathtt{D0} = \mathtt{03}$.

Once we know that we can increase $IV_{B15}'$ by one, and then try to find $IV_{B14}$. Of course we're now going to try and find padding $\mathtt{0202}$, which means that the change would only be $\mathtt{01}$ as $\mathtt{03} \oplus \mathtt{01} = \mathtt{02}$.

We can continue doing this. As you may notice, this trick will work regardless if we're working within the original padding bytes. And it will also work if we use it on a truncated ciphertext as we're just relying on creating valid padding, even for those bytes that are not at the end of the message. Once the padding is accepted it is possible to get the original plaintext byte at the particular location we're aiming for.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323