2
$\begingroup$

I am reading the cryptography book by Stamp and there is a cut-and-paste attack on $ECB$ and this is easy to follow because $ECB$ is relatively simple, the problem is that I would like to see an example of this in $CBC$ mode. Is there an easy example to show this?

$\endgroup$
  • 2
    $\begingroup$ The chaining prevents that, however, there is a bit-flipping attack on CBC mode apart from the padding oracle attacks. That shows that integrity is very important and in modern cryptography we use authenticated ciphers like AES-GCM or ChaCha20-Poly1305. $\endgroup$ – kelalaka Feb 5 at 15:34
  • 1
    $\begingroup$ It would be nice to know if these answers answered your question. If they do, it might be a good idea to choose one of them as accepted. I think the other answers are great as well, so I'm not arguing for mine in any way whatsover. If you've still got doubts on specific answers, then please comment. And don't forget, you can always change an accept... If you need a coin let me know, I'll paint my answer on the side :P $\endgroup$ – Maarten Bodewes Feb 7 at 2:17
2
$\begingroup$

Here is a nice explanation from the efail presentation, credits to Jens and Chris! This is for CBC but it looks pretty much the same for CFB.

So here is CBC decryption: CBC decryption Now if you flip a bit in $C_1$ you can flip that same bit in $P_1$: flip a bit but it will also cause $P_0$ to look like random trash after decryption. other block gets destroyed

But if you know what $P_1$ was in the beginning you can basically XOR it with whatever you want and thus insert blocks into the decrypted plaintext at the cost of randomizing every other block. So the ciphertext is clearly malleable.

This can be exploited if the randomized blocks can be escaped somehow on the application level or similar. Again a picture from one of the efail presentations: full exploit Here the randomized blocks are ignored because they are put inside quotes and the HTML parser ignores quoted strings without an attribute name.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ Nice example. The randomization inside the quotes may fail of course if the bytes do not translate to characters, or if they translate to quotation marks / escape sequences and whatnot. The example is solid, but reproducing it may be tricky due to random errors (just in case somebody tries to create a demo). $\endgroup$ – Maarten Bodewes Feb 5 at 16:48
2
$\begingroup$

In cut-and-paste one part of ciphertext is replaced by another ciphertext with known (or at least, known legible) plaintext, so the resulting message has a different meaning to the receiver of the encrypted message. It should be avoided by using authenticated encryption.

There is probably not a direct copy-and-paste attack on CBC in a similar way as there is for ECB. The plaintext of CBC is retrieved after XOR with the previous ciphertext block. So you would not have to just cut-and-paste the previous block for the target block to make sense. However, since that block is also decrypted, using the block before that, the block before the plaintext block is now randomized. Similarly, the block after the changed block is altered as well (although at least in a way known to the adversary).

Now if the IV is prefixed then you can replace any amount of blocks at the start of the cipher, and they will be converted in known plaintext - if that plaintext is known for another ciphertext encrypted with the same key. The only problem is that the block thereafter is changed as well. Obviously the same kind of reasoning works for the last block.


Does that mean that CBC is invulnerable against such cut-and-paste attacks? Well, no. There are many instances where random data is perfectly acceptable. Say we have a message that consists of a large number with any possible value followed by a boolean that indicates some kind of access condition. Now we can replace the bytes of the modulus with random data, and replace the boolean with a known value, say true instead of false. I guess that this is an example you can live with, as it even works with a randomized IV.

Plaintext 1:                    [ number         ][ number | true  ]
Ciphertext 1: [ IV1            ][ CT1 / 1        ][ CT1 / 2        ]
Plaintext 2:                    [ number         ][ number | false ]
Ciphertext 2: [ IV2            ][ CT2 / 1        ][ CT2 / 2        ]

Attacked:     [ IV2            ][ CT1 / 1        ][ CT1 / 2        ]
Decrypted:                      [ random         ][ number | true  ]

However, if we study this problem further we'll see that this problem is actually larger. Say that false is represented by a byte valued 00 and true is represented by any value other than 00 (hi there, C programmers). In that case you can just randomize the last block and have the value be changed with likelihood of 255 out of 256. So we really don't need cut-and-paste at all.

Attacked:     [ IV2            ][ CT2 / 1        ][ random         ]
Decrypted:                      [ number         ][ random | bool? ]

where bool? = false with chance 1 in 256 and bool? = true with chance 255 in 256.

Even worse, with plaintext and padding oracle attacks, we may even be able to decrypt the entire message by using attacks such as these.


So the answer is: no, the exact cut-and-paste technique may not work for textual messages read by humans. However, modern cryptography doesn't generally target such messages, and CBC is really vulnerable against attacks that are very much like the cut-and-paste technique.

With the bit flipping attack used on the IV, the attacker may still be able to change a letter into a different one in the initial block without disturbing any other part of the plaintext.

This is why we use to create an authentication tag to protect the integrity and authenticity of messages nowadays. There are almost an infinite number of ways that undetected alteration of the message can wreak havoc on a system.


Even with integrity and authentication, you can always cut-and-paste an entire message, including IV and authentication tag. This is a replay attack, and you need separate measures such as a unique session counter to avoid those.

|improve this answer|||||
$\endgroup$
  • $\begingroup$ +1 for mentioning full message replay in this context. $\endgroup$ – Elias Feb 5 at 16:42
2
$\begingroup$

Attacking CBC is much harder than ECB. In many cases there is no viable attack. Properly implemented CBC with a secure underlying block cipher is secure. There have been successful attacks against padding in CBC, though non were anywhere as simple as attacking ECB. Look at: https://en.wikipedia.org/wiki/Padding_oracle_attack https://en.wikipedia.org/wiki/POODLE

There are also attacks on implementations of CBC with predicatble IVs e.g: https://www.netsparker.com/blog/web-security/how-the-beast-attack-works/

CBC has lost favor not because it is insecure in itself but because it is easy to implement poorly and there have been many attacks. If you expect anything remotely as simple as attacks on ECB I am happy to inform you these do not exist nor are expected.

Edit: I seem to have missed the point of the question, it was about manipulating cipher text. CBC is probably the least malleable of the common block cipher modes(harder than ECB or CTR) and yet without a authentication of some sort a MAC, or GCM or such CBC can still be manipulated, specifically if you have wiggle room and are willing to create a junk plain text block at your cut and paste boundary. If you know the plain text of a given block, you can replace it with a plain text of your choice by manipulating the previous cipher text blcok. calculate the xor diff between current plain text and desired plain text and apply it to previous cipher text block. This will cause the previous block to decipher into gibberish and the target blcok to be deciphered into whatever you want.

|improve this answer|||||
$\endgroup$
  • 1
    $\begingroup$ See my answer below. Changing the ciphertext is pretty easy for CBC if you have some plaintext. I agree that it is much harder than ECB but not hard enough. :) $\endgroup$ – Elias Feb 5 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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