How does AEAD guarantee authenticated encryption and plain AES does not? This is a follow up to my earlier question. This is more out of curiosity in how AEAD (like CCM or GCM) works compared to encryption in other modes (like CBC or ECB).

Suppose you have AES-256-CBC encrypted blocks of data, each encrypted with a proper nonce (no collisions). How is it less safe and non-authenticated compared to the same blocks of data, but encrypted with AES-256-GCM? What sort of an adversary attack does AEAD prevent that no other mode can prevent?

I understand that if the adversary replaces the entire ciphertext block with another valid ciphertext, this will go undetected in non-AEAD capable mode, but will be detected with AEAD.

However, if data is encoded with a nonce that's clearly visible (one common implementation prepends the ciphertext with a nonce), then it is possible to replace the entire ciphertext with a previously valid ciphertext (since the nonce is known).

Do I understand correctly that a proper implementation requires that you store all previously used nonces and never reuse them?
However, if data is encoded with a nonce that's clearly visible (one common implementation prepends the ciphertext with a nonce), then it is possible to replace the entire ciphertext with a previously valid ciphertext (since the nonce is known).


This is known as a 'replay attack', and is typically handled at a higher level.

One easy way is the TLS approach; it just keeps a record counter on both sides, and the counter (which increments for each record) is included with the AAD.  If someone were to replay the record, the counter of the original encryptor (which was at some original value) and the counter of the decryptor (which would be at some larger value) would not be the same, and hence the integrity check would fail.

Another approach is the DTLS and IPsec approach; they don't assume a reliable transport (packets sent by one side might not make it to the receiver, or packets might be received out of order), hence counters on the two sides would not necessarily be synced.  Hence, what the do is have the encryptor keep a counter, which is explicitly sent in the packet (and which is included in the AAD).  Then, the receiver checks the counter to see if it's one it has seen before; if so, it rejects the packet.  This protects against replay attacks; if the attacker replays the packet with the original counter value, then the packet will be rejected by the above logic; if it adjusts the counter, then the GCM integrity check will fail.

Of course, there are other possible strategies; these are just two which are used in practice.


  Suppose you have AES-256-CBC encrypted blocks of data, each encrypted with a proper nonce (no collisions). How is it less safe and non-authenticated compared to the same blocks of data, but encrypted with AES-256-GCM?


I just showed you how GCM can protect against replay attacks; there are also message-reordering attacks which the higher level protocol needs to protect against.  GCM itself protects you against other attacks which modify a message to something that the valid encryptor hasn't produced.  On constrast, CBC mode does not; the attacker can do a number of modifications of CBC-encrypted messages without being detected (unless you also include some sort of MAC, which anyone sane would)