# Should I use ECB or CBC encryption mode for my block cipher?

Can someone tell me which mode out of ECB and CBC is better, and how to decide which mode to use? Are there any other modes which are better?

• About every mode of operation is better than ECB for most use-cases. – Paŭlo Ebermann Jul 21 '11 at 14:25
• @PaŭloEbermann and what use cases is ECB better for? – CodyBugstein Oct 25 '15 at 17:08
• @Imray I guess when your data is smaller than one block, and will not repeat anyways (i.e. already includes a nonce), and you are really space/bandwidth-limited, ECB has some uses. Might have other ones I'm not aware of. – Paŭlo Ebermann Oct 25 '15 at 18:11
• Note that this question is currently used as the example question on our site tour page. As such, it should be kept as tidy and neat as possible, but it (and at least two of the answers below) also needs to stay short and simple to remain eligible for the tour page. – Ilmari Karonen Nov 30 '16 at 12:56
• ECB might be the right tool when encrypting randomly generated data. As example, Bruce Schneier's Password Safe uses ECB for this purpose. – Erwan Legrand Mar 30 '18 at 16:56

The really simple explanation for the difference between the two is this:

• ECB (electronic code book) is basically raw cipher. For each block of input, you encrypt the block and get some output. The problem with this transform is that any resident properties of the plaintext might well show up in the ciphertext – possibly not as clearly – that's what blocks and key schedules are supposed to protect againt, but analyzing the patterns you may be able to deduce properties that you otherwise thought were hidden.
• CBC mode is short for cipher block chaining. You have an initialization vector which you XOR the first block of plaintext against. You then encrypt that block of plaintext. The next block of plaintext is xor'd against the last encrypted block before you encrypt this block. (Public domain image from Wikimedia Commons.)

The advantages of CBC over ECB are many – with ECB, assuming many things, you could manage a partial decryption and easily fill in the blanks, for example if extracting data from an encrypted hard disk. With CBC, if you are missing a few blocks in the sequence encryption becomes impossible. However, there is one downside to CBC – ECB naturally supports operation in parallel since each block can be encrypted independently of the next. However, with CBC this is harder, since you have to wait on each block. (You can still parallelize decryption, though.)

CBC itself can also be considered vulnerable in certain situations, specifically the use of predictable IVs and unauthenticated decryption can allow you to guess plaintexts as explained in this answer and in more detail here.

The IV problem is resolved by using unpredictable (cryptographically random) IVs. The authentication problem is traditionally resolved using message authentication codes - however, implementation of these is not perfect. Dedicated modes have been invented which tackle the issue of authentication too, for example EAX and Galois Counter Mode.

Other modes exist to deal with specific scenarios, e.g.:

• Counter Mode uses the fact that a block cipher's output in ECB mode should be indistinguishable from random, and XOR's the result of encrypting a counter+iv combination as a stream cipher.
• XTS is a mode of operation used in disk encryption.

The key point to take away is that each mode has a number of merits and implementation concerns and these must be weighed up carefully (and correctly implemented). And, where possible, avoid ECB.

Expanded explanation for how resident properties propagate into ciphertext with ECB

When writing this answer, I tried to not post a picture of the typical ECB-encrypted linux penguin, but I've been asked to expand on "resident properties in the plaintext" so what follows will be the same idea, just in text form. If you don't need it, feel free to skip.

Firstly, let's use a format I know something about - the mp3 frame. Like most plaintext this is far from "indistinguishable from random" - indeed for example, the MP3 frame header begins with 11 bits set to 1.

There are two important properties of block ciphers:

• On a block level, operations are deterministic. If I encrypt "Cryptography Stack Exchange" and this fits in a single block, I expect to get the same output for given parameters every time. This sounds like a crazy critera (of course we need this) but it's worth highlighting.
• On a block level, the output is indistinguishable from random - more formally there's no advantage for an attacker over using a random permutation, at least in a way that is realistically computable. My terminology might be a bit off because I am self taught, but I believe if the advantage is non-zero you've got a bias and this makes the cipher a candidate for linear cryptanalysis.

These statements apply considering only a single block; however obviously in the real world we want more than that - we want to encrypt multiple blocks.

Suppose we live in an imaginary world where people think block ciphers with a block size of one byte are a good idea. Now let's imagine this is otherwise a totally fine block cipher. Now imagine you have some MP3s of Justin Bieber music and you'd very much like the NSA not to find out about this. So you take your block cipher and you encrypt your MP3.

Now, one of those blocks, making some assumptions about file alignment, is going to be 0xFF - that's 8 of your 11 ones from the frame header in the MP3. These are always there at the beginning of each frame. Now our cipher is indistinguishable from random so we get perfectly random ciphertext, say 0x1c. But it is also deterministic and we're using ECB, so every frame header that was 0xFF becomes 0x1c.

All of a sudden we're giving away information to our attacker - specifically they can deduce where the frame headers are if they suspect this to be an MP3. Cryptanalysis is sometimes about guessing correctly and a correct guess in this case will give them an idea of exactly how long the audio samples are and allow them to identify the format.

Moreover, every other ciphertext block 0x1c is now decodable too. That's not information we intended to give away, but we did.

This problem is common particularly when you consider much of what we encrypt has a rigid data format. You have to make some assumptions about alignment on the blocks, but the larger the data the more this problem becomes apparent.

This is what I mean by residual plaintext properties becoming evident in the ciphertext. These are the structure inherent to and wanted in the plaintext that inadvertedly become exposed to the attacker.

The original purpose of CBC mode was as a form of identifying corrupt messages and the security of CBC for this purpose is treated in this paper. I can't find the original realization of this idea in terms of papers, but you might be able to find it. Certainly most books on block ciphers that I have read mention it and other issues.

• >> Now imagine you have some MP3s of Justin Bieber music and you'd very much like the NSA not to find out about this. Forget the NSA, noone should find out about my secret Justin Bieber music collection! – Nils Pipenbrinck Jun 15 '15 at 15:32

ECB and CBC are only about encryption. Most situations which call for encryption also need, at some point, integrity checks (ignoring the threat of active attackers is a common mistake). There are combined modes which do encryption and integrity simultaneously; see EAX and GCM (see also OCB, but this one has a few lingering patent issues; assuming that software patents apply at all to your situation -- a non-trivial question --, then there are some explicit licenses).

Never use ECB! It is insecure.

I recommend an authenticated encryption mode, like EAX or GCM. If you can't use authenticated encryption, use CBC or CTR mode encryption, and then apply a MAC (e.g., AES-CMAC or SHA1-HMAC) to the resulting ciphertext.

ECB is not secure, it leaks information. CBC is better. But if you need random access to your file Use CTR mode.

• Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. "ECB is not secure, it leaks information" is a conclusion, but not including what's going on that makes that the right conclusion puts us in a "give a man a fish" vs. "teach a man to fish" scenario -- it's always better to teach him to fish. :) – HedgeMage Jul 25 '11 at 17:51
• Let's not expand this answer too much, though -- the fact that it's so short is what lets it be shown in our site tour. – Ilmari Karonen Apr 9 '15 at 18:26
• CTR is not much better at random access than CBC. Both of them allow random access during decryption. Neither of them support random access writes. If you attempt random access writes with CBC you will corrupt data. If you attempt random access writes with CTR you will leak data. – kasperd Jun 15 '15 at 16:47

Better is a subjective term. However for the choice between ECB and CBC, the choice should be CBC for almost all situations.

Although ECB and CBC are modes of operation of a block cipher, you could also turn this way of thinking around and see the block cipher as a configuration option for the mode of operation. The mode of operation has a big influence on the security of the resulting cipher.

The problem with ECB is that it is not really a mode of operation. It is basically the same as splitting up the plaintext into blocks and encrypting them completely independent on each other. When the block cipher is considered secure then the resulting ciphertext of a single block is of course also secure - when analyzed independently. However when multiple messages or or messages are encrypted then ECB is not secure; identical plaintext blocks will result in identical ciphertext. This means that an attacker can easily detect repetition.

CBC solves this by introducing a vector, which alters the first plaintext block before it is encrypted. The effect is that the entire ciphertext is randomized, as the ciphertext created by that block is used as vector for the next block (and so forth). In other words: it ensures that each block is encrypted differently even if the block contains the same information.

In addition to uniqueness the IV also needs to be unpredictable for the attacker. This is to disallow an attacker to alter the plaintext & IV combination: finding a duplicate ciphertext would indicate that the input of the block cipher was seen before, hence leaking information about the plaintext. Usually creation of an unpredictable IV is accomplished by creating it using a secure random number generator (RNG or RBG). As both the encryption and decryption needs to be performed using this same, unique IV the IV is usually prefixed to the ciphertext. A random IV does not need to be kept confidential.

Is ECB still useful? Essentially it should not be used for message confidentiality. It can however still be used for encrypting fully random data (such as symmetric keys) or as building block for better algorithms and protocols. For that reason alone it is still present in almost all cryptographic API's.

Note that there are many other modes of operation beside ECB and CBC. Neither ECB or CBC provide integrity or authentication. That means that even CBC is not useful for transport protocols without additional protection. Anybody can alter messages and it is likely that confidentiality is also lost if padding oracle attacks are possible.

Nowadays you should default to an authenticated mode of operation such as GCM or EAX. Otherwise you could perform a HMAC over both IV and ciphertext.

CBC is better than ECB..

Let x and y are a same plaintext in different block and will be encrypted with same key.

If we use ECB, ciphertext of x is same with ciphertext of y. So the attacker can do cryptanalysis easily.

But If we use CBC, ciphertext of x will be difference with ciphertext of y. So the attacker can do cryptanalysis difficulty.

long story short , if there is a lot of repeated data don't use ECB cause there will be an obvious pattern CBC is much safer but its heavier to run cause each block is a cipher for the other block

• CBC mode is not in any reasonable way "harder to run" than ECB. – Maeher Nov 15 '18 at 7:35
• Especially, if you are using a single core – kelalaka Nov 15 '18 at 8:58
• @Maeher actually if you pipeline your AES implementation, eg each AES round is one pipeline stage (something like that was done with AES-NI), CBC is arguably significantly worse than ECB. However both are inferior to CTR mode anyways (which does play nicely with pipelining)... – SEJPM Nov 15 '18 at 12:50

For example ECB mode is most recommended in case if you have only one block to encrypt. i.e for example if you have two blocks of data and if you are using a ECB mode chances of sensing the plain text is more. But CBC mode can be used when you have a chain for plain blocks to be encrypted. Where the first blocks encrypted output can be used as a key to encrypt second plain block.

• ECB is not normally recommended even with single blocks, because it is deterministic and so reveals whether two messages are equal. CBC does not use the previous ciphertext as key, but XORs it with input. I.e. basically uses it as IV, when compared to single block CBC. – otus Oct 8 '15 at 12:32

The problem with this question is that the question is incomplete. It's like asking the question "should I use a hammer or a screw driver". Without knowing the underlying application and requirements it is impossible to properly answer this question (in fact, the answer may be "tape measure").

Still, ECB and CBC each have their strengths and weaknesses. If you have lite encryption requirements (for example, something fast and simple) then ECB is useful. If you are looking for stronger strength, then you need to consider CBC. However, if you must deal with data loss, than CBC becomes very difficult (you will not be able to recover the chunk of data after the loss point). If you need to handle data loss, strong encryption, and relatively fast processing, a different technique may be required (and there are lots).

Another strength/weakness comparison is random access/parallel processing. ECB blocks can be encrypted and decrypted in parallel. Each ECB block can be accessed completely randomly, and any amount of loss or corruption in previous blocks has no effect on the current block. In CBC, encryption is completely serial (you can't encrypt block N until you encrypt block N-1, and so on back to block 1). Decryption requires 2 blocks (you need block N-1 to decrypt block N). So, random access in CBC requires twice the data as ECB.

Still, ECB is a very poor choice for message encryption unless the message is either very short (not longer than the block size), or undergoes a whitening process first (using another system to make the underlying bits look random - white noise).

In summary, ECB by itself, does not provide much in the way of security. CBC by itself does not provide great error recovery (some, but not great). ECB is a good building block as part of a larger system (heck, it's used in CBC). CBC is great for systems that have low error rates and no random access encryption needs (for example, when writing a file). Understanding these limitations helps in deciding which to use and when (or if you need something completely different).

• If you have to ask the question, you don't know enough to use ECB – poncho Jun 14 '15 at 1:13
• 1) The additional complexity of CBC or CTR is small compared to the complexity of the blockcipher itself. The performance hit is negligible using CTR mode. 2) CBC can be decrypted if you lose data in the middle since each plaintext blocks only depends on two consecutive ciphertext blocks. But it's rarely a good idea to decrypt modified data. – CodesInChaos Jun 14 '15 at 18:54
• This answer is completely wrong. ECB has no strengths. Its only usefulness in a crypto library is as a building block for other modes that the library doesn't support. – Gilles 'SO- stop being evil' Jun 15 '15 at 7:36
• Sorry, but your comment is mostly wrong. ECB is useful in a lot of situations, you just have to be careful when using it and understand its weaknesses. For example, if your message goes through a whitening process first then ECB is fine. If your message is short (on the order of the block size), ECB is fine. If you are using the system as a form of random number generator, ECB is fine. But you are right, ECB as a full message encryption system is not fine. – sid1138 Jun 15 '15 at 13:25
• Block J of CBC depends on the XOR of all previous blocks. It is possible to resynchronize after two blocks of an error. That requires error detection, saving previous blocks, and so on. Lost data causes additional problems (first is - how much was lost, so how much is affected). If data is changed, instead of lost, than at least two blocks are also changed (ECB, only the changed block is effected). Without some kind of authentication, the effect may not be detected and therefore it is almost easier to tamper with CBC than ECB (only 1 bit per 3 blocks need invalidates all data). – sid1138 Jun 15 '15 at 13:38