Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
From what I have understood about ECB and CBC, CBC is far better as it doesn't reveal any pattern. There have been several questions here about how ECB is bad:
But are there any cases where ECB is better than CBC, or at least is still usable? My guess is that for high entropy messages, without any pattern, the major flaw of ECB is irrelevant, but are there any benefits to using ECB over CBC?
ECB benefits:
ECB downsides:
For comparison, CTR mode allows parallel encryption and decryption and a single corrupted bit corrupts only 1 bit (not even a whole block as in ECB). Also CTR doesn't need padding or have padding related weaknesses.
If you have high entropy messages where message blocks never repeat ever then ECB could be acceptable, but it's just asking for trouble.
From a theoretical point as a mode of operation ECB mode has only one advantage over all of the other modes: it doesn't require an IV. That means that the ciphertext doesn't expand if the message is a multiple of the block size or if ciphertext stealing is applied. This can be a benefit e.g. when wrapping another symmetric key (a high entropy message), for which ECB mode is fine - even though it doesn't offer integrity / authenticity. Another example could be a challenge-response protocol.
ECB mode is a common mode in API's. This is usually not because ECB mode is that useful on its own but because it can be used as a primitive. If ECB mode is used for one block then it just acts as a natural representative to the block cipher (whereas for CBC or CTR you'd need a zero IV). So it can be used as a pass-through to the block cipher from a higher level API. Likewise it can act as a sub-part of accelerated CTR mode encryption where large parts of the key stream can be calculated in a single call to ECB: you just line up the counter values in memory and perform ECB mode encryption on it.
Finally, many libraries simply include it for backward compatibility. The fact that it takes almost no effort at all to implement it and the fact that you need something to test a block cipher against probably plays a factor as well. Ciphertext stealing is a lot trickier to implement (if only because there are multiple variants) and I haven't seen too many implementations of CTS for ECB mode. The fact that it is insecure for most messages makes CTS for ECB mode rather unnecessary.
ECB provides confidentiality, but not integrity or authentication, when the message length is always exactly one block and messages will never be repeated with the same key. These circumstances are rare but not unheard of. For instance, in a protocol intended to be used under steganography, you want every bit of the ciphertext to be indistinguishable from randomness; one way to achieve this is to use a normal authenticated mode for the message proper, but then encrypt the IV with a second key, in ECB mode. You can fix the length of the IV to be the underlying cipher's block size, IVs shouldn't ever be repeated anyway, and integrity and authentication are not needed because the message proper will fail to decrypt if the IV has been tampered with. Doing this without giving the adversary any sort of oracle to work with adds a few complications, but that's the basic idea.
However, because you are always encrypting one-block messages with the second key in this scenario, it's equally accurate to say that you are not using any operation mode; you're just using the block cipher. And to avoid people seeing "ECB mode" and jumping to the conclusion that your protocol is garbage, that is how I would recommend writing it up.
(The second paragraph of this answer is paraphrased from something Dan Boneh told me about six years ago.)
Both are malleable. In ECB you can erase/insert/replace but only known blocks. This is of course already terrible. However, CBC is even worse in the sense that you can perform bit-level manipulations: flipping bits in IV results in flipping bits in first plaintext block. Same is possible for further blocks though only with corruption of other blocks.
CBC is vulnerable to padding oracle attack, which allows to decrypt arbitrary blocks given the oracle. In ECB you can't do that with padding oracle (depending on padding used you may be able to get some information about the plaintext, e.g. the last byte).
