Why shouldn't I use ECB encryption?

Question

I'm using Java to generate encrypted strings, and I get this warning at build time:

ECB encryption mode should not be used

So I'm wondering why I shouldn't use ECB and what I can use instead?

Answer 1

Why shouldn't I use ECB encryption?

The main reason not to use ECB mode encryption is that it's not semantically secure — that is, merely observing ECB-encrypted ciphertext can leak information about the plaintext (even beyond its length, which all encryption schemes accepting arbitrarily long plaintexts will leak to some extent).

Specifically, the problem with ECB mode is that encrypting the same block (of 8 or 16 bytes, or however large the block size of the underlying cipher is) of plaintext using ECB mode always yields the same block of ciphertext. This can allow an attacker to:

• detect whether two ECB-encrypted messages are identical;
• detect whether two ECB-encrypted messages share a common prefix;
• detect whether two ECB-encrypted messages share other common substrings, as long as those substrings are aligned at block boundaries; or
• detect whether (and where) a single ECB-encrypted message contains repetitive data (such as long runs of spaces or null bytes, repeated header fields or coincidentally repeated phrases in text).

There's a nice graphical demonstration of this weakness on Wikipedia, where the same (raw, uncompressed) image is encrypted using both ECB mode and a semantically secure cipher mode (such as CBC, CTR, CFB or OFB):

     

While this scenario is somewhat artificial (one would not usually encrypt raw images like this), it nicely demonstrates the problem with ECB mode: repetitive areas in the input image result in repetitive patterns in the encrypted output, so that many large-scale features of the image remain recognizable despite the encryption. In the real world, a cryptanalyst attacking an ECB-based encryption scheme would be more likely to look for such patterns in a hex dump of the ciphertext, but the principle is the same.

An actual case of this weakness of ECB encryption contributing to a real-world data compromise is given by the 2013 Adobe password database leak, as described in this answer. Here, one element contributing to the severity of the leak was that, instead of hashing them properly, Adobe had encrypted the passwords using ECB mode. This allowed the attackers to quickly locate passwords shared by multiple accounts, or sharing a common prefix with other passwords (like password1 and password2), and also revealed the approximate length of each password.

---

The ECB encryption mode also has other weaknesses, such as the fact that it's highly malleable: as each block of plaintext is separately encrypted, an attacker can easily generate new valid ciphertexts by piecing together blocks from previously observed ciphertexts.

However, the malleability is only an issue if ECB encryption is used without a message authentication code, and, in this situation, is shared (to some extent) by all other non-authenticated encryption modes, like the aforementioned CBC, CTR, CFB and OFB. Thus, it cannot really be considered a specific weakness of ECB mode, even though it does tend to be an additional issue whenever ECB mode is used.

---

What should I use instead?

You should use any authenticated encryption mode, such as GCM, EAX or OCB.

Personally, for short messages, I'm rather fond of SIV mode (RFC 5279), which provides an extra layer of misuse-resistance. (Many other encryption modes will break rather badly if the same IV / nonce is accidentally used to encrypt multiple messages. SIV mode retains all its security properties in this situation, except for leaking whether the encrypted messages are identical.)

You can also use any traditional semantically secure encryption mode (such as CBC or CTR), combined with a message authentication code (such as HMAC) using the Encrypt-then-MAC construction. (That is, you should first encrypt the message, then compute a MAC of the ciphertext, and append it to the ciphertext.) As long as you make sure to verify the MAC before attempting to decrypt the message, this construction will protect you from the various vulnerabilities of these modes to active (chosen-ciphertext) attacks.

For disk encryption or similar applications that require the ability modify parts of the ciphertext without re-encrypting all the data, you should use a cipher mode designed for that purpose, such as XTS. Note that such modes generally lack resistance to active attacks, and may have other weaknesses that should be understood before using them. If possible, they should be combined with some form of integrity protection, such as a MAC on a hash tree.

Answer 2

You should not use ECB mode because it will encrypt identical message blocks (i.e., the amount of data encrypted in each invocation of the block-cipher) to identical ciphertext blocks. This is a problem because it will reveal if the same messages blocks are encrypted multiple times. Wikipedia has a very nice illustration of this problem.

Answer 3

As @Guut Boy mentioned it, ECB isn't semantically secure, in the sense that if a message with identical blocks is encrypted, then an attacker get a certain advantage to have information on plaintext, by only observing CipherText.

Use preferably CBC mode to encrypt long message. This mode introduce an additional parameter called the IV (Initial Value), you initialise with the session number to prevent attacks in the case of encrypting the same message twice.