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?


4 Answers 4


ECB benefits:

  • It's a tiny bit easier to implement.
  • It allows for parallel encryption and decryption (CBC only decryption).
  • A single corrupted cipher block corrupts only one block of plain text(in CBC it is 2)
  • It doesn't need an IV

ECB downsides:

  • In almost all cases it is insecure.

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.

  • 2
    $\begingroup$ A drawback of CTR is that reuse of a counter value will severely hurt security, much more so than reusing an IV in CBC mode. $\endgroup$
    – kasperd
    Commented Apr 11, 2018 at 20:25
  • $\begingroup$ a. Don't reuse counter, b. Not trying to give complete comparison, was focusing on ECB vs CBC. c. There is good reason CTR/GCM are becoming far more common. $\endgroup$
    – Meir Maor
    Commented Apr 11, 2018 at 20:39
  • 5
    $\begingroup$ @MeirMaor: To avoid reusing a counter, one must have a record of what values have been used which is absolutely reliable, and won't get reset when e.g. a storage device gets damaged and needs to be reloaded from a backup. Limiting the damage if a counter value does get reused seems wiser than assuming it will never happen. $\endgroup$
    – supercat
    Commented Apr 11, 2018 at 21:11
  • 1
    $\begingroup$ @supercat A reliable non reuse technique is a longish random IV powered somewhere upstream by an entropy source, like /dev/urandom. No records need be kept this way. $\endgroup$
    – Paul Uszak
    Commented Apr 11, 2018 at 22:09
  • 2
    $\begingroup$ @forest: That's just semantics. The nonce is just the initial value of the counter. You still need to (absolutely) make sure you never reuse a nonce. $\endgroup$ Commented Apr 12, 2018 at 6:00

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.

  • 1
    $\begingroup$ I think the most important part of your answer is the first sentence, though it might be improved by noting that ECB doesn't require an IV that will make the whole cipher fall apart if it is accidentally used twice. To my mind, the biggest objection to an IV as used in other schemes isn't the difficulty of communicating it (though that is an annoyance) but the fact that it must absolutely positively never get duplicated. $\endgroup$
    – supercat
    Commented Apr 11, 2018 at 21:31
  • 1
    $\begingroup$ @supercat For block ciphers with 128 bits block size (or more) this isn't a huge issue you can just generate 128 bits of randomness and prefix it to the ciphertext. Even if you consider the birthday paradox you'd still have $2^{64}$ bits of security for about $2^{64}$ ciphertexts. It's a bit trickier for CTR (or GCM etc.) or for 64 bit block ciphers of course. But as ECB directly leaks information on repeated message blocks and CBC would simply degenerate to something that looks like ECB if the IV is reused I would not call that a benefit of ECB. $\endgroup$
    – Maarten Bodewes
    Commented Apr 11, 2018 at 21:43
  • $\begingroup$ CBC is fine for many purposes, and duplication of the IV CBC isn't a huge leak, but CTR seems popular and CTR devolves to an xor between plaintexts if any counter value used in one transmission matches any counter value used in another. ECB by itself is unsuitable for some purposes, but for most purposes it would seem unlikely to devolve into something as horrid as repeated-counter CTR. $\endgroup$
    – supercat
    Commented Apr 11, 2018 at 21:58
  • 1
    $\begingroup$ The cryptographic community in general disagrees with you. This can be seen by the fact that any of the current authenticated ciphers (GCM, CCM, EAX) uses CTR underneath. I'll stop this discussion here. But feel free to add an answer to why ECB is better than other modes of encryption, particularly CTR. $\endgroup$
    – Maarten Bodewes
    Commented Apr 11, 2018 at 22:24

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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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