1

It is known that an authenticated encryption scheme is better than just encryption because, in the latter, an attacker can alter the ciphertext, which cannot be verified. In the former, altering the ciphertext can be detected by authentication tag verification.

However, it appears to me that in an authenticated encryption, if an attacker can replay a previously sent ciphertext, IV, and authentication tag altogether, we are back into a situation where the receiver would not be able to detect the alteration.

Is my understanding correct? If this is correct, then saying that the authenticated encryption scheme is "authenticated" does not appear to be justified.

1
  • 2
    "if an attacker can replay a previously sent ciphertext, IV, and authentication tag altogether, we are back into a situation where the receiver would not be able to detect the alteration" - which alteration? Nothing was altered here. A replay attack does not change the authenticity and integrity of the message - it still was generated by the same sender (authenticity) and was not altered (integrity). If the use case requires resistance against replay (not all do) then additional mechanism are used, like sequence numbers, timestamps ... Dec 21, 2023 at 6:31

1 Answer 1

1

To expand on Steffen's comment, replay protection is separate from integrity protection / authentication. You're correct that authenticated encryption doesn't inherently provide replay protection. In many cases, replay protection isn't necessary (for example, a duplicate email or IM will generally not cause a problem, and emails at least are often dated). In others, it's fairly easy to add replay protection on top of integrity protection, so using authenticated encryption simplifies replay protection even though it doesn't provide it inherently.

Simply add a value that is supposed to change with every message, and require that the recipient verify that the message is as expected / hasn't been seen before. It can be a simple counter (such as a sequence number), a timestamp (with a narrow window of acceptance around it), a completely unique message ID (for low-message-count channels), or some combination of those things or similar ones. In most cases this adds the advantage that out-of-order or delayed messages can be detected, and in some cases missed messages can too.

There exist secure protocols that have such protection built in, such as TLS and SSH. I'm not aware of any cryptographic construction that directly provides such protection - some use counters, but they start at a known value and often repeat - but it's a known problem with standard solutions for most use cases where it's necessary.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .