# Always set the IV to 0 randomized CBC

Please explain what goes wrong if we always set the IV to 0 in randomized CBC, and use the system to encrypt two different messages m0 /= m1 with the same key k.

I tried to find answer and read CBC mode IV .

I can't understand what goes wrong if we always set IV = 0

• Hint: find an attack against CBC encryption under the IND-CPA experiment, or whatever similar characterization of security the course considers. If there's no formal characterization, consider the situation where it's sent every morning either "NO FOOD SUPPLY DELIVERY WILL OCCUR ON (date)" and "A FOOD SUPPLY DELIVERY WILL OCCUR ON: (date)".
– fgrieu
Commented Jan 9, 2023 at 8:47
• What is randomized CBC? The only inputs to CBC are the message, the key, and the IV, of which only the IV is what I'd call "randomized". Fixing it to 0 makes it not random. Commented Jan 9, 2023 at 18:15
• I agree with @BoppreH that this question needs clarification regarding the meaning of "randomized CBC". The existing answers seem to assume that you mean normal CBC mode, and that the word "randomized" in your question means nothing. But the fact that you put it in boldface suggest that you might be talking about some custom variant of CBC mode instead, in which case all bets are off. Commented Jan 10, 2023 at 4:14
• Using a random IV serves the same function as salting a hash. Commented Jan 10, 2023 at 11:07

## 2 Answers

This will be dangerous if there is a high probability of repeated initial blocks across plaintext. Cryptographers like to make as few assumptions as possible about the structure of plaintext and so are very conservative in their designs and recommended usage.

Two examples of families of plaintexts where CBC with fixed IV might be bad are as follows:-

Consider a classified organisation where messages are prefixed with header either "TOP SECRET - FOR YOUR EYES ONLY" or "CONFIDENTIAL - CIRCULATE". If these are encoded into ASCII and encrypted with a 128-bit block-size cipher in CBC mode with fixed IV, adversaries will be able to group together the messages with the same classification.

Consider an automated update of a stock portfolio that doesn't trade much. Perhaps a message might read:

BEGINS
PENDING TRANSACTIONS:
ALPHABET  0000000
AMAZON    0000000
APPLE     0000000
FACEBOOK  0000000
MICROSOFT 0000000
TWITTER   0000000
ENDS


With CBC with fixed IV an adversary could see multiple identical messages encrypted with the same key, but when pending transaction does occur, they would be able to detect it and also make a strong guess as to the stock likely to be traded.

There are also more active approaches that a cryptographer seeks to avoid. They will consider a scenario where the adversary is able to control part of the ciphertext (e.g. if a message begins "You wrote: '<CONTENT OF LAST RECEIVED MESSAGE>'". If an adversary submits a message where the fixed prefix is one byte short of a block size, and then submits 256 messages with the same prefix appended with all possible follow on bytes, they recover the first byte of user plaintext from the first message. This is similar to the real-world ChopChop attack on WEP.

It is certainly possible to specify that plaintext does not have these sort of structures in order to avoid these attacks, but security professionals feel that the defensive burden should fall to the cryptographer rather than the user.

• Good example, more modern than mine!
– fgrieu
Commented Jan 9, 2023 at 8:51

When you use same key and same IV, same plaintext will be encrypted into same ciphertext. Moreover, if you have two plaintext, that share first X blocks and the differ, those X blocks will same after encryption.

example:

Plaintext 1: This is plaintext message number one.

Ciphertext 1: 67bd60f95492b347fcf614fb569f8cdb174466eb8a1bb696a16a5bf1fbe598201f6e375f91bdf5b7

Plaintext 2: This is plaintext message number two.

Ciphertext 2: 67bd60f95492b347fcf614fb569f8cdb174466eb8a1bb696a16a5bf1fbe5982055748115eb1a2a0a

• Thank you for clear example Commented Jan 12, 2023 at 20:17