Ahead of the question, little warning. Question is not about what are the better options. Question is why it is bad idea?

Ok, suppose we have plaintext $p$, which divided into blocks: $p_1,p_2,p_3,...,p_n$

CBC (cipher block chaining) can be then defined as $c_1=E_k(p_1 \oplus IV)$,$c_2=E_k(p_2 \oplus c_1)$,$c_{i+1}=E_k(p_{i+1}\oplus c_i)$

Ok. What would be bad about this version $c_{i+1}=E_k(p_{i+1}\oplus p_i)$?

($E_k$ is some encryption function)

  • $\begingroup$ Hint: what happens if you encrypt extremely redundant plaintext, say, 3 blocks of all the same character? $\endgroup$
    – poncho
    Commented Apr 19, 2015 at 11:27
  • $\begingroup$ Why do we XOR the ciphertext of the previous block to the next block? To make it more random. Would this also happen if we use the predictable plaintext instead of the random-looking ciphertext? No. $\endgroup$
    – Nova
    Commented Apr 19, 2015 at 12:08

1 Answer 1

  1. Patterns aren't hidden. Assume you've got a pair of plaintext blocks $p_1, p_2$ then the encryption of $p_2$ will always be the same: $c_2=E_k(p_1 \oplus p_2)$ as it only depends on the plaintext. So you haven't basically solved the basic problem of ECB (patterns remain) but rather moved it (to the more rare case) that two blocks repeat.
  2. Plaintext isn't random. In most cases an attacker can predict plaintext. As you basically use plaintext as IV for each block you make the scheme vulnerable to attacks like BEAST, where attackers use predictable IVs to gain information about target connections. See this related question.

Corrected my speed concerns. Encryption and decryption can be parallelized, speed should be comparable with CTR.

  • $\begingroup$ A parallelizable decryption is good; I think you have a typo. $\endgroup$
    – cpast
    Commented Apr 19, 2015 at 18:21
  • $\begingroup$ @cpast, sorry, thought it would be the exact inverse of CBC (decryption as encryption and vice versa). decryption can be parallelized. $\endgroup$
    – SEJPM
    Commented Apr 19, 2015 at 18:45
  • $\begingroup$ How do you parallelize the decryption? You need the plaintext of the next block, and to get that you need the plaintext of the plaintext after that, and to get that... Looks pretty non-parallelizable to me. $\endgroup$
    – Nova
    Commented Apr 19, 2015 at 20:42
  • $\begingroup$ Sorry, I did mean the plaintext BEFORE another plaintext. $\endgroup$
    – Nova
    Commented Apr 19, 2015 at 20:54
  • $\begingroup$ @Nova Observe: $p_1 \oplus IV = D_k(c_1)$ and $p_1 \oplus p_2 = D_k(c_2)$ Now you'd only need a bulk of data (TLS record?), decrypt each block by itself (which is the most time-consuming operation) and as there are no dependencies (as you see above) you can parallelize large parts of the decryption, only the XOR afterwards can't be parallelized, but it's very fast. $\endgroup$
    – SEJPM
    Commented Apr 20, 2015 at 12:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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