About every mode of operation is better than ECB for most use-cases.
–
Paŭlo EbermannJul 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 BodewesSep 18 '13 at 16:13

6 Answers
6

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.

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 BodewesSep 18 '13 at 16:14

>> 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 PipenbrinckJun 15 at 15: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
–
ponchoJun 14 at 1:13

2

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

1

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.
–
GillesJun 15 at 7:36

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.

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

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.

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. :)
–
HedgeMageJul 25 '11 at 17:51

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.
–
kasperdJun 15 at 16:47