# I read ECB is bad because the same plaintext outputs the same ciphertext. Isn't that a requirement of a cipher?

In the Wikipedia article on Block Ciphers, it says about the Electronic Code Block mode:

The disadvantage of this method is that identical plaintext blocks are encrypted into identical ciphertext blocks; thus, it does not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all.

How is that a disadvantage? Isn't it a requirement of a cipher that identical input produce the same output? Otherwise, how could you decipher the ciphertext if it could have been created by many different inputs?

• There's probably a duplicate, but one plaintext can map to multiple ciphertexts without two plaintexts being able to map to the same ciphertext. In math terms, an injective function is not necessarily bijective. – otus Oct 25 '15 at 17:20
• (Actually, that's a poor way to state it, since a function by definition has a singe value per input. You should get the idea, though.) – otus Oct 25 '15 at 17:26
• good point I should have realized that – CodyBugstein Oct 25 '15 at 18:05

Indeed, ECB is such that encrypting twice the same plaintext leads to the same ciphertext. Even worse, encrypting a plaintext containing twice the same plaintext block leads to a ciphertext containing twice the same ciphertext block. Either is a disadvantage because it goes against the ideal of a cipher: depriving the adversary from any knowledge about the plaintexts, with the sole exception of length.

An example of why that's a drawback is if we encipher plaintexts consisting of votes cast in an election, with plaintext N for a no vote, Y for a yes vote. With any cipher such that encrypting twice the same plaintext leads to the same ciphertext, someone intercepting the ciphertexts will see two values, and can determine each vote (assuming a single vote is known, or it is known that Y outnumbers N).

If a cipher has the property that plaintext and ciphertext have the same size for any unconstrained plaintext, then indeed (in order for plaintext to be exactly decipherable, and by a counting argument) the cipher is bound to have said drawback. Hence modern ciphers have a ciphertext larger than the plaintext (typically for symmetric ciphers: by the Initialization Vector's size at least).

Addition per comment: an example of a cipher not bound to generate the same ciphertext when enciphering twice the same plaintext would be $\operatorname{AES}$ in counter mode with key $K$

• encryption:
• generate a 128-bit Initialization Vector $C$ at random, using the computer equivalent of tossing a coin 128 times, and outputs $C$ as the first 128 bits of the ciphertext
• while remaining plaintext length $l>0$
• output the eXclusive-OR of the next $\max(l,128)$ bits of plaintext and as many of the leftmost bits of $\operatorname{AES-ENC}_K(C)$
• $C\gets C+1\bmod2^{128}$ (increment the counter)
• decryption:
• set $C$ as the first 128 bits of the ciphertext
• while remaining ciphertext length $l>0$
• output the eXclusive-OR of the next $\max(l,128)$ bits of ciphertext and as many of the leftmost bits of $\operatorname{AES-ENC}_K(C)$
• $C\gets C+1\bmod2^{128}$ (increment the counter)
• I think a good addition to this answer would be to add a paragraph about how it's possible for a cipher to encrypt non-deterministically. The word "initialization vector" is referred to once and never explained. – Thomas Oct 25 '15 at 23:40
• Good explanation, but I'd like to add that the example image on Wikipedia says more than a thousand words. Also, ECB can be reasonably secure if the block size is large enough (which is necessary anyway), an IV is used to initialize the cipher, and the input data is known to have high entropy (e.g. is compressed), but since an XOR is very cheap, it should nonetheless be avoided as much as possible. – Arne Vogel May 27 '19 at 7:17