# 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
Authenticated modes of operation add a lot of security for many use cases (as specified by the answer of DW). If padding oracle attacks are possible, CBC mode of operations does not offer security regardless of the cipher used. –  Maarten Bodewes Sep 18 '13 at 16:13

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

-
This is an accepted answer, but it does not answer the second part of the question. We should either remove this part of the question, or we should at least point to authenticated modes of operation within the answer. –  Maarten Bodewes Sep 18 '13 at 16:14
@owlstead I'll expand on it, give me a bit. –  Rhino Sep 19 '13 at 7:19
Could you please expand on what 'resident properties' of the plaintext are? –  mikemaccana Mar 30 at 9:37
@mikemaccana no problem; I've expanded my answer. I hope it's useful. –  Rhino Apr 8 at 13:22

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.

For more information about Block cipher modes of operation see the Wikipedia article.

-
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 at 18:26

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 plaintext before it is encrypted. This ensures that each block is encrypted differently even if the block contains the same information. For CBC the vector is the result of the previous block encrypt, and this result is XOR'ed with the plaintext block before encryption.

Of course there is no ciphertext result before the first block, hence CBC requires an initialization vector. This initialization vector or IV makes sure that the (initial) ciphertext blocks of CBC of messages are different even if the plaintext is identical. To accomplish this CBC must use a unique IV for each separate key.

In addition to uniqueness the IV also needs to be unpredictable for the attacker to disallow some particular attacks on CBC. Usually this 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 protected against disclosure.

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.

-