Replay Attacks

The Need for Nonces

Even if an attacker cannot decrypt a secure packet, they might record the encrypted bytes and simply resend ('replay') them exactly as they are to the server, hoping to trigger the same action twice (like an authentication approval).

Systems defeat replay attacks by injecting unique timestamps or nonces (Numbers Used Once) into every single packet. The receiver remembers recent nonces and instantly rejects duplicated attempts.

Timestamps vs Nonces

API endpoints defend against replay attacks by including the server's current UNIX timestamp in the cryptographic signature payload, setting a strict expiration window (e.g., 30 seconds). Nonces are tracked in a transient database to aggressively reject duplicates specifically within that window.

Everyday Example

A thief stands next to your car while you use your key fob to unlock the doors. The thief uses a radio to record the encrypted 'unlock' beep. The thief has no idea how to decrypt the beep, but they don't have to! Later that night, they simply play the recorded beep back to the car. The car hears the valid beep and unlocks. Replay attacks are defeated by making every beep single-use.

The Deep Mathematics

Preventing spatial replay requires strictly enforcing monotonically increasing sequences or cryptographic Nonces within the signature payload. A server mathematically evaluates `hash(payload + Nonce + Secret)` and rigidly rejects any payload evaluating to a previously cached Nonce, guaranteeing that intercepted ciphertexts exhaust their utility instantly.