# 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 Answer

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.

• A parallelizable decryption is good; I think you have a typo. – cpast Apr 19 '15 at 18:21
• @cpast, sorry, thought it would be the exact inverse of CBC (decryption as encryption and vice versa). decryption can be parallelized. – SEJPM Apr 19 '15 at 18:45
• 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. – Nova Apr 19 '15 at 20:42
• Sorry, I did mean the plaintext BEFORE another plaintext. – Nova Apr 19 '15 at 20:54
• @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