# Is ECB mode secure if plaintexts are guaranteed to be unique?

I've got a scenario where I need to encrypt many small (16-byte) plaintexts. I want to use AES-128 in ECB mode. Notably, each plaintext is guaranteed to be unique, though each may differ by only a few bits.

In this scenario, is ECB secure?

Yes, this is one case where ECB mode is secure.

It can be shown to be secure trivially from the indistinguishability assumptions of AES; that AES with an unknown key cannot be distinguished from a random permutation. If the plaintexts are all 16 bytes long, then in ECB mode, this directly means that the ECB mode encryption of those plaintexts are indistinguishable from random.

I'm sure MrNerdHair already knows this, but for those people who may be reading this later, lets make this a bit more explicit. The assumptions that I am making are:

• Every plaintext message is 16 bytes (either they're all 16 bytes, or they are all less than 16 bytes and become 16 bytes after padding). If the message is longer (and so ECB mode does two separate encryptions), the attacker may be able to take advantage of the lack of interaction between those two blocks

• Every plaintext message is distinct. This matters because ECB mode encryption is determanistic, and so if we encrypt the same message twice, the ciphertexts will be exactly the same; this may be exploitable.

• Thanks. That's what I thought, but in crypto it's always best to assume you're incapable of determining whether or not you're stupid. Jun 18, 2012 at 16:56

Yes, simply encrypting each 16-byte block with AES-128 will insure their confidentiality if they are all different, w.r.t. to an adversary that can't break AES (nitpick: given that AES is an even permutation, we should also assume that more than two plaintext/ciphertexts pairs remain unknown, but that's a practical certainty). That use of AES can be named ECB if the various blocks are grouped together in some defined order.

However beware that it does next to nothing for integrity. In particular, ciphertexts can be replayed; shuffling the ciphertexts will shuffle the plaintexts the same way; and a random ciphertext will decipher to an apparently random plaintext.

Update: integrity of each block can be verified to some level by checking known bits in the deciphered plaintext, such as constant bits, or bits that are any known function of other bits (e.g. CRC, any kind of checksum..). Each checked bit demonstrably halves the odds that a ciphertext has been forged other than by duplicating another known good ciphertext. Beware that if an adversary can use a device to test if a ciphertext corresponds to valid plaintext, this compromise the integrity check mechanism w.r.t. that device, and any other device that use the same key.

• You're right about integrity. However, I've made the last 2 bytes of my plaintext a simple checksum over the other 14, and they contain a counter that allows me to tell if they're new or not (sort of like an OTP scheme). Jun 18, 2012 at 17:00
• I just want to emphasize that people often underestimate the severity of attacks against unauthenticated modes. A 16 bit checksum is nice to protect against random errors, but not enough to protect against malicious modifications. Jun 18, 2012 at 18:24
• So what you're saying, if I hear you right, is that I should use a larger checksum? If so, I suppose I'd have to use a checksum as large as the key to provide authentication as strong as the cipher itself, wouldn't I? (Just wondering.) Jun 18, 2012 at 19:32
• There is one other field in the plaintext that stays the same for each record. It's 6 bytes long. If I were to check that field as well as the checksum as part of the authentication procedure, I'd increase my security to 64 bits, wouldn't I? (I realize that's a lot less than 128. Just wondering if I'm thinking clearly here.) Jun 18, 2012 at 19:43
• @MrNerdHair: Yes, this looks like a good idea. Jun 18, 2012 at 20:03