I've seen the ECB Penguin used to demonstrate why ECB is not a recommended method of encryption, but I do not understand how this translates to text or passwords.

ECB Penguin image

Aren't the people who create these images comparing apples and oranges?

  • 5
    $\begingroup$ imgs.xkcd.com/comics/code_talkers.png $\endgroup$
    – Turion
    Commented Feb 14, 2014 at 16:10
  • 1
    $\begingroup$ An ideal encryption system would leave no recognizable structure (or "signal") in its ciphertext. In general, if any structure is visible, there's some method of leveraging that to completely crack the code. The ECB Penguin isn't itself a crack, but it's an indication that patterns in the input map to patterns in the output. $\endgroup$ Commented Feb 14, 2014 at 19:59
  • $\begingroup$ If one were to xor the pixel data with just about any bit pattern that didn't have any correlation to the underlying picture before encryption, would it be practical to infer anything about the original picture in that case? What disadvantages would such an approach have over CTR? $\endgroup$
    – supercat
    Commented Apr 11, 2018 at 21:29

2 Answers 2


It illustrates the point that the same plaintext going in to the cipher will result in the same ciphertext. It just happens to be a lot better example than showing someone

abc387af de7231ab abc387af abc387af a129867e

Now, what does this mean in the real world? If I gave you an email encrypted with AES-128 ECB, could you look at it and figure out the plaintext? Most likely not. If, however, I gave you a ciphertext from a long book and told you it is the encryption of one of 100 books, could you figure out which book it is? Probably.

So, comparing apples and oranges? In some ways yes, in others no. I think though that the point people who show this are driving home is that there are stronger modes which are much more likely to lead to a secure system. Sure ECB could be used to develop a system which is secure, but it would take a lot of analysis to convince an expert of that.

  • 1
    $\begingroup$ Thank you. I did not realize that it was just a graphical representation of ECB spitting out the same ciphertext given the same input. I was under the impression that the security researchers were attempting to demonstrate how easy it was to discover the plaintext given nothing but the ciphertext. $\endgroup$
    – Josh Bond
    Commented Feb 13, 2014 at 19:07
  • 5
    $\begingroup$ The first time I encountered the "ECB Penguin" was on Wikipedia. The article itself might be illuminating. $\endgroup$ Commented Feb 13, 2014 at 19:14
  • $\begingroup$ What stumped me was that I would expect a white pixel (or yellow or black, etc) to come out as the same color every time after encryption. Instead, a pixel "pattern" emerges. This leads me to believe that there is more information being encrypted than just "color", but also possibly "position". If that is true, and you can detect a pattern, then it makes sense that you could eventually detect the same type of pattern with encrypted text. $\endgroup$
    – Josh Bond
    Commented Feb 13, 2014 at 20:03
  • 8
    $\begingroup$ @JoshBond: The "pattern" arises because pixels and cipher blocks don't line up exactly: an uncompressed true-color pixel takes up three bytes, while most common block ciphers encrypt blocks of either 8 or 16 bytes (64 or 128 bits). $\endgroup$ Commented Feb 13, 2014 at 20:13
  • 3
    $\begingroup$ @JoshBond You still can't - you can't get the original colours back from this encrypted penguin without knowing the key. You can however still tell that it's a penguin, even if you can't tell whether it was originally red or purple or black. There's also lots of lost detail e.g. around the feet. $\endgroup$ Commented Nov 4, 2016 at 5:25

For a real-world example of precisely the same ECB weakness leading to a massive password compromise, see the Adobe password database leak, as memorably illustrated in the xkcd web comic:

$\hspace{83px}$XKCD: Encryptic
(source: xkcd.com)

While there were several issues contributing to the scale of the compromise, one of them was that Adobe, instead of properly hashing the passwords, encrypted them using ECB mode instead. Even though the attackers apparently did not get the encryption key (or, if they did, they chose not to disclose it), this still exposed several weaknesses that made the passwords much easier to guess:

  • The length of the encrypted data revealed the length of the password, rounded up to the next 8 bytes. (This weakness is actually not specific to ECB mode, but I'm including it for completeness.)

  • Identical passwords produced identical ciphertexts, making it easy to locate frequently reused (and thus presumbaly weak) passwords, and also allowing multiple hints for the same passwords to be correlated as shown in the cartoon above. (This is a weakness of ECB mode; it would not have happened if the encryption had been done using a semantically secure mode with a proper IV.)

  • Passwords with the same 8-character prefix yielded ciphertexts with the same first block, making it easier to guess the prefix by comparing hints. Similarly, any multi-block passwords differing only in some of the blocks would yield partly matching ciphertexts, and any password that happened to contain repeating 8-character blocks (say, "passwordpassword" or "aaaaaaaaaaaaaaaa") would produce a repetitive ciphertext, just like in the Tux image example.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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