# Plaintext block chaining, bad idea why?

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)

• Hint: what happens if you encrypt extremely redundant plaintext, say, 3 blocks of all the same character? – poncho Apr 19 '15 at 11:27
• 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. – Nova Apr 19 '15 at 12:08

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.
• @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. – SEJPM Apr 20 '15 at 12:49