Many advice against using AES in ECB mode as it always produces same cipher text for a given plain text.

That shortcoming can be addressed by using salt appended to original message so that the resulting cipher text is different each time , the receiver can then decyrpt the cipher text and discard the salt keeping the original message

However this is susceptible to replay attacks, but that can be mitigated further by using a frame counter in the plain text message so that the receiver knows if the message is being replayed by a unauthorized sender.

So the result would be

Encrypt[Counter + Message + Salt] ===> CipherText ==> Decrypt[CipherText] ===> Counter + Message + Salt.

That strategy seems sound to me , are there any known flaws that advise against using it ?

  • $\begingroup$ How many blocks do you plan to encrypt with this scheme? Is it one block per salt? $\endgroup$ – kelalaka Jun 23 '20 at 10:53

The point of producing different ciphertexts for the same plaintext is so that an attacker, given two identical ciphertexts, could not conclude that the plaintexts must be the same. This is indeed a weakness, but is not the main problem of ECB, which is that each block is encrypted completely independently, leaking huge amounts of information about the plaintext to even a passive observer.

Your strategy does not help with that, as the attacker could simply ignore all the ECB blocks belonging to the counter and salt and simply pick out blocks belonging to the messages, and we're back to standard ECB.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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