# Can someone explain the ECB Penguin?

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.

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

-
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. –  Russell Borogove Feb 14 at 19:59

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.

-
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. –  Josh Bond Feb 13 at 19:07
The first time I encountered the "ECB Penguin" was on Wikipedia. The article itself might be illuminating. –  Stephen Touset Feb 13 at 19:14
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. –  Josh Bond Feb 13 at 20:03
@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). –  Ilmari Karonen Feb 13 at 20:13

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}$

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.

-