a replay attack

Suppose a building lets you in if you wave a key card that broadcasts a fixed code. Now imagine someone records that radio code as you walk in, then plays it back later at the door — and it opens for them too. They never had to break the code or know what it means; they just captured a valid message and used it again. A replay attack is exactly that: an attacker captures a legitimate, even fully encrypted message and re-sends it later to trigger an effect a second time.

The crucial point is that a replay attack can succeed without the attacker ever decrypting anything. Suppose your banking app sends an encrypted, authenticated command meaning 'transfer 100 dollars to account X.' The attacker can't read or modify it — integrity and confidentiality both hold — but if they record the packet and send the exact same bytes again, and the server has no way to tell it apart from a fresh request, the transfer happens twice. The vulnerability is not in the encryption; it's in the lack of freshness — nothing in the message says when it was created or that it may only be used once.

Why it matters: replay shows that confidentiality and integrity are not enough; you also need to guarantee a message is fresh and used only once. The standard defenses add freshness: a nonce (a number used once that the receiver remembers and rejects if seen again), a timestamp with a short validity window, or a per-message sequence number inside the authenticated data. TLS, for instance, includes sequence numbers in its record protocol so a replayed record is detected and dropped. Whenever a protocol forgets freshness, replay sneaks back in.