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?

  • Comments are not for extended discussion; this conversation has been moved to chat. – e-sushi Sep 12 '17 at 14:29
up vote 61 down vote accepted

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

      ECB penguin

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.

  • 1
    What would you suggest in cases where one wishes to be able to read/write blocks of a data store in arbitrary sequence, preferably while making an all-ones block map to an all-ones block? My inclination would be to encrypt by xoring the block data with a very simple hash of the block number, undoing/repeating the xor operation if it yields an all-ones block, using ECB on the result, and xoring with the complement of the result of encrypting an all-ones block [that complement need only be computed once for each key]. Would that seem like a good approach? – supercat Dec 22 '14 at 16:42
  • 1
    @supercat: That's basically disk encryption, so you could use modes designed for that. I believe XTS is considered a good choice, although, like all disk encryption modes, it has its limitations (which you should understand before using it). If possible, it should be combined with a MAC of some sort to defend against active attacks. – Ilmari Karonen Dec 22 '14 at 17:12
  • @IlmariKaronen: i think saying "don't use ECB" is a bit overkill. I understand the risks, but many times (unless your doc-what you are encrypting- isn't very secret, and adversary doesn't have too many capabilities, etc.), you should be ok. – user19992 Dec 28 '14 at 16:06
  • 1
    @giorgim: There's really no good reason to use ECB (except as a building block for other modes). Pretty much any crypto library provides at least CBC or CTR mode, and if not, they're trivial to implement yourself. Slap an HMAC (or CMAC) on top of that, and you're good to go. – Ilmari Karonen Dec 28 '14 at 16:17
  • 1
    @giorgim: Even if you don't have any MAC or AE mode available, using CBC is still strictly better than ECB. If you do have a MAC function, CBC-then-MAC is a perfectly good AE mode. – Ilmari Karonen Dec 28 '14 at 16:38

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.

  • Comments are not for extended discussion; this conversation has been moved to chat. – e-sushi Sep 12 '17 at 14:34

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.

  • 1
    IV stands for initialization vector, not initial value. – ntoskrnl Dec 22 '14 at 18:49
  • 2
    1. This is not good advice. Using encryption without authentication disregards about a decade of advice from cryptographers. Better would be to use authenticated encryption, as Ilmari Karonen recommends. 2. This answer seems to be superceded by Ilmari Karonen's answer. – D.W. Dec 22 '14 at 22:29

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.