AES/ECB vs AES/CBC for <16 bytes

I could've sworn this was a duplicate question, but I can't find a good match for it here right now, so let me answer it instead.

What if size of encrypted input is always less or equal 16 bytes? I suspect AES/ECB will be as good as AES/CBC in this case...

For plaintexts shorter than the cipher block size (i.e. 16 bytes for AES), CBC mode encryption is equivalent to:

1. padding the plaintext up to 16 bytes,
2. XORing the padded plaintext with a random 16-byte IV,
3. encrypting the resulting 16-byte block with raw AES (i.e. in "ECB mode"), and
4. concatenating the random IV and the AES output to form the encrypted message.

XORing the plaintext with a random IV does, in fact, provide a concrete security benefit: it ensures that even two identical plaintexts will (with overwhelming probability) encrypt to different ciphertexts, preventing an attacker from learning whether two encrypted messages conceal the same plaintext or not. With ECB mode, which is purely deterministic, an attacker could simply compare the two ciphertexts to find out if the plaintexts are equal or not.

However, in this particular short-plaintext scenario, that's the only benefit of the IV. In particular, it's of no help against any attacks that would involve breaking AES (or compromising the encryption key), since if an attacker can invert the AES encryption (step 3), they can then trivially undo the IV XOR (step 2).

On the other hand, the use of a random IV actually makes CBC mode vulnerable to some tampering attacks that EBC mode happens to be invulnerable to. In particular, for short messages like in this scenario, an attacker capable of intercepting and tampering with the encrypted message can flip any bit(s) in the plaintext just by flipping the corresponding bit(s) in the IV!

Now, technically this does not compromise the claimed security of CBC mode, since CBC mode doesn't claim to protect message integrity against tampering attacks in the first place. But a lot of people aren't aware of that, and in any case message integrity protection is still important and should be ensured somehow, either by using an encryption mode that provides it directly (such as GCM) or by using a message authentication code on top of the encryption layer.

The other question is: will AES/GCM be any better (secure) for <16 bytes input compared to AES/ECB &| AES/CBC?

Yes, GCM is better than either ECB or CBC for messages of any length, since it provides both message authentication (tampering resistance) and full semantic security (leaks no information about the plaintext other than its length).

(In some cases, specifically for messages sufficiently shorter than one cipher block, using ECB mode and verifying the padding after decryption can actually provide a form of message authentication. But this doesn't work for longer messages. CBC mode doesn't provide any authentication for messages of any length.)

The same holds for any other secure authenticated encryption mode as well, not just GCM. There's not that much difference between them (in terms of security; speed, code complexity and library support can of course vary), and they're all secure against nearly all passive and active attacks if used correctly. In practice, the main ways in which the security of such an encryption mode can be compromised are:

• key compromise (obviously, no encryption scheme is secure if the key is leaked),
• user / implementation error (bugs in the code, not using the mode according to its specifications),
• information leakage via message length (e.g. if the plaintext is compressed before encryption; see e.g. the CRIME and BREACH attacks on SSL), and
• bad IV generation (the security of many encryption modes, including GCM, can fail catastrophically if the same IV is used for two different messages).

Thus, whenever possible, my recommendation would be to use an authenticated encryption mode that provides IV misuse resistance (such as AES-SIV or AES-GCM-SIV) and a reputable open-source implementation of it, such as Miscreant, that provides a simple "black box" API with the least possible room for user mistakes. And if you're encrypting variable-length data, be very careful about possible leaks via its length, since no general-purpose encryption scheme can fully conceal that (and most don't even try).