Plaintext block chaining, bad idea why?

Question

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, 2015 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, 2015 at 12:08

Community · Accepted Answer · 2017-04-13 12:48:23Z

2

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.
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.

CommunityBot

1

answered Apr 19, 2015 at 11:39

SEJPM

45.7k7 gold badges95 silver badges203 bronze badges

$\begingroup$ A parallelizable decryption is good; I think you have a typo. $\endgroup$
– cpast
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
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
Apr 19, 2015 at 20:42
$\begingroup$ Sorry, I did mean the plaintext BEFORE another plaintext. $\endgroup$
– Nova
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
Apr 20, 2015 at 12:49

| Show 1 more comment

1 Answer 1