0
$\begingroup$

this is my first post so I apologise if the formatting of my post isn't perfect.

I should start off by saying that this post is not for any malicious intent, rather for curiosity and understanding AES encryption/decryption.

I have been doing research about AES encryption and everywhere says that ECB mode should never been used and often refers to the famous Linux Tux penguin example. I understand that the vulnerability lies in the fact that a block of plaintext will always produce the same block of cipher text with some key.

However, I am new to this topic and I am struggling to understand the vulnerability in the following situation:

Consider a plaintext (P1) that is encrypted using AES-ECB to produce an encrypted ciphertext C1 with a key unknown to me. If I had another cipher text (C2) that was encrypted using AES-ECB (using the same unknown key), how could I obtain the corresponding plaintext (P2) even if I have P1 and C1 accessible to me?

My confusion lies in the fact that despite having access to P1, C1, and C2 — I do not know the key.

$\endgroup$
2
  • $\begingroup$ This very much depends on the definition of unsafe: "Obtain the plaintext" is not the only interesting goal for some adversaries. Think of the situation where the time of the shift is either 02:00 or 03:00, and sent enciphered every day at 01:00, in some unknown but fixed format. $\endgroup$
    – fgrieu
    Oct 30, 2022 at 7:38
  • $\begingroup$ The problem with EBC is the repeating pattern, assume that your file contains a similar pattern then it will leak information therefore one needs probabilistic encryption. It is also possible to execute a frequency attack on databases that deploy ECB mode for column encryption. If you can guarantee that the data is not repeating there is no problem with ECB. However, forget about it. $\endgroup$
    – kelalaka
    Oct 30, 2022 at 13:43

1 Answer 1

1
$\begingroup$

The issue with ECB is precisely what you've described in your question. Abstractly, the "encrypted" penguin doesn't tell you what the original penguin was but tells you quite a lot about the original message. This is very undesirable for an encryption scheme since revealing "some" information on the underlying plaintext can be enough to recover the whole plaintext.

Why not define security as obtaining the plaintext? Defining security this way is tempting but can lead to stating "obviously" insecure designs as secure. For instance, take a secure encryption scheme called AES-SEC, and modify it slightly (obtaining AES-SEC*) such that encryption works the same but also outputs a few bits of the original message. In this definition, AES-SEC* is secure, but it's not hard to see that AES-SEC* is insecure in many cases.

The ECB mode is "secure" if the plaintext contains blocks that are all distinct, which greatly restricts the practicality of ECB.

The basic security notion for an encryption scheme is usually that of "indistinguishability under chosen plaintext attacks" or IND-CPA. See this answer for an introduction to these notions. See also the Joy of Cryptography for an extensive discussion.

$\endgroup$

Your Answer

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

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