1
$\begingroup$

Forgive my ignorance, but I've run into some confusion in an AES implementation I'm testing.

To the best of my understanding, ECB provides no diffusion, the same plaintext with the same key will yield the same ciphertext every time. That's what makes it so bad for real-world cryptography.

But as a programmer, my current understanding of it is it's a little like debug vs. release. Don't do anything in the real world with ECB, don't release it. However, it's great for making sure the AES algorithm is actually working the way it should without bugs.

However, I've run into an implementation I'm not familiar with where the same plaintext with the same key will yield different ciphertext. Is there any chance I'm wrong in my understanding and in this ECB implementation (or ECB period despite some random blog stating otherwise and I've been thinking about it all wrong this whole time) while it still has poor diffusion (too much for it to be used practically), there's still diffusion?

Essentially, I want to verify my understanding is correct before I start thinking there is something wrong with someone else's programming. I can always be wrong. I'm still learning. Please clarify my current understanding. Many thanks in advance!

$\endgroup$
1
  • $\begingroup$ "However, I've run into an implementation I'm not familiar with where the same plaintext with the same key will yield different ciphertext." Kindly link to the implementation so we can have a look. $\endgroup$
    – Maarten Bodewes
    Mar 9 at 1:38

1 Answer 1

2
$\begingroup$

ECB provides no diffusion

ECB provides no large-scale plaintext-to-ciphertext diffusion, but does provide some plaintext-to-ciphertext diffusion: with AES-ECB, changing 1 bit of plaintext changes typically about 64 bits (always 1 to 128 bits) of ciphertext. AES-ECB also provides excellent key-to-ciphertext diffusion.

(ECB vs. other secure modes is ) a little like debug vs. release

That analogy fails the way I read it: ECB can't be used as a mock-up for secure encryption during an initial development phase.

  • ECB uses no Initialisation Vector, as real encryption does. IV needs a special treatment (to generate and transmit it), and increases the size of the transmission.
  • Decryption never ends in error for ECB without padding, but can for some secure decryption and any authenticated encryption.
  • pure ECB (with neither padding nor ciphertext stealing) can only encrypt data a multiple of the block size, a limitation waived in modern encryption.

(ECB is) great for making sure the AES algorithm is actually working the way it should without bugs

Yes, if "AES algorithm" is the piece of code that implements the block cipher, that is enciphers or deciphers a 16-byte block per a 16, 24 or 32-byte key, yielding a 16-byte block. That functionality precisely matches that of AES-ECB encryption or decryption without padding of a 16-byte plaintext.

I've run into an implementation I'm not familiar with where the same plaintext with the same key will yield different ciphertext.

If that happens with a plaintext of size multiple of 16 bytes (or if the plaintext and ciphertext size differ), then this is not AES-ECB without padding. It could still be AES-ECB with random padding. In that case, for a fixed plaintext at least 16 bytes, the first 16 bytes of ciphertext won't change.

$\endgroup$
1
  • 1
    $\begingroup$ ECB can use CTS. For random padding only the last block changes rather than that the first block does not change. $\endgroup$
    – Maarten Bodewes
    Mar 9 at 1:37

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.