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?
Edit: This question was asked long back when I was working on a Flex application to enrypt/decrypt files.
The really simple explanation for the difference between the two is this:
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.:
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:
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
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
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.
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.
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.
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.
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).