0
$\begingroup$

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?

$\endgroup$

1 Answer 1

3
$\begingroup$

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)

$\endgroup$
4
  • $\begingroup$ Okay, thanks. This explains a lot. Since I'm exchanging files, I'm going to add a store for nounces used by the other party. $\endgroup$
    – Marek
    Dec 12, 2019 at 12:02
  • $\begingroup$ @Marek: Would it be sufficient to include the filename (or other unique identifier) into the AAD? That's (partially) what the AAD is there for - to bind this partial ciphertext into this context (so it can't be used in another one). $\endgroup$
    – poncho
    Dec 12, 2019 at 15:42
  • $\begingroup$ @Marek: also, if you are using the nonce idea, couldn't you use strictly incrementing nonces? That way, you need only remember the last one (assuming, of course, that you don't have to worry about multiple files being transferred at once, and the reception of a specific file is acknowledged - those details depends on your protocol...) $\endgroup$
    – poncho
    Dec 12, 2019 at 15:44
  • $\begingroup$ You're right about sequential nounces. I can implement that on my end, but I think the other party does random nounces for every encryption. This is mostly reasonable since we expect just two transfers per day (one in each direction) and the encryption key expires in two years. I'll just keep track of used nounces and if there's a repeat, I'll consider the key compromised and generate a new one. $\endgroup$
    – Marek
    Dec 12, 2019 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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