From 7f8a51b1ff786207531c63ab83d835592da80c49 Mon Sep 17 00:00:00 2001 From: nktrejo2020 <69374108+nktrejo2020@users.noreply.github.com> Date: Mon, 5 Oct 2020 17:25:11 -0700 Subject: [PATCH] Update stream-ciphers.rst ROWS 707-749 --- src/stream-ciphers.rst | 50 +++++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/src/stream-ciphers.rst b/src/stream-ciphers.rst index 3762bc71..390030d3 100644 --- a/src/stream-ciphers.rst +++ b/src/stream-ciphers.rst @@ -704,44 +704,44 @@ causes the plaintext to have a ``02`` in that second-to-last position. ciphertext block, XORed with the second-to-last byte of :math:`R`, is ``02``.) -In order to successfully decrypt the message, we still need to figure -out which one of those options is the actual value of the padding. To do -that, we try to discover the length of the padding by modifying bytes -starting at the left-hand side of :math:`P_i` until the padding becomes -invalid again. As with everything else in this attack, we modify those +We still need to find the option that is the actual padding value +for successful message decryption. +The padding length is discovered by modifying bytes +on the left-hand side of :math:`P_i` until the padding becomes +invalid. As with everything else in this attack, we change the bytes in :math:`P_i` by modifying the equivalent bytes in our chosen -block :math:`R`. As soon as padding breaks, you know that the last byte -you modified was part of the valid padding, which tells you how many -padding bytes there are. Since we're using PKCS#5 padding, that also -tells you what their value is. - -Let's illustrate this with an example. Suppose we've successfully found -some block :math:`R` so that the plaintext of :math:`R \| C_i` has valid -padding. Let's say that padding is ``03 03 03``. Normally, the attacker -wouldn't know this; the point of this procedure is to discover what that -padding is. Suppose the block size is 8 bytes. So, we (but not the +block :math:`R`. As soon as the padding breaks, you know that the last byte +modified was part of valid padding and the number of +padding bytes. Since we use PKCS#5 padding this also +tells you the value. + +Lets illustrate with an example. Suppose we successfully find +a block :math:`R` so that the plaintext of :math:`R \| C_i` has valid +padding. Lets say that padding is ``03 03 03``. Normally, the attacker +would not know this; the point of the procedure is discovery of the +padding. Suppose the block size is 8 bytes. So, we (not the attacker) know that :math:`P_i` is currently: .. math:: p_0 p_1 p_2 p_3 p_4 \mathtt{03} \mathtt{03} \mathtt{03} -In that equation, :math:`p_0 \ldots` are some bytes of the plaintext. -Their actual value doesn't matter: the only thing that matters is that -they're not part of the padding. When we modify the first byte of -:math:`R`, we'll cause a change in the first byte of :math:`P_i`, so -that :math:`p_0` becomes some other byte :math:`p^{\prime}_0`: +In the equation, :math:`p_0 \ldots` are some bytes of the plaintext. +Their actual value does not matter. What matters is that +they are not part of the padding. When we modify the first byte of +:math:`R`, we cause a change in the first byte of :math:`P_i`, so +that :math:`p_0` becomes another byte :math:`p^{\prime}_0`: .. math:: p^{\prime}_0 p_1 p_2 p_3 p_4 \mathtt{03} \mathtt{03} \mathtt{03} -As you can see, this doesn't affect the validity of the padding. It also -does not affect :math:`p_1`, :math:`p_2`, :math:`p_3` or :math:`p_4`. -However, when we continue modifying subsequent bytes, we will eventually -hit a byte that *is* part of the padding. For example, let's say we turn +As you can see, padding validity is not affected. +:math:`p_1`, :math:`p_2`, :math:`p_3` or :math:`p_4` are also unaffected. +However, when we continue modifying subsequent bytes, we eventually +hit a byte that *is* part of the padding. For example, lets turn that first ``03`` into ``02`` by modifying :math:`R`. :math:`P_i` now -looks like this: +appears as follows: .. math::