Most authenticated encryption modes have a foot-cannon footnote: "thou shalt not reuse a nonce." Reuse a GCM nonce twice with the same key and you don't just lose confidentiality of those two messages — you leak the authentication key, letting an attacker forge anything. In practice nonces get reused all the time: virtual machines fork, RNGs misbehave, counters reset on reboot, key-wrapping contexts have no obvious nonce at all. RFC 5297 specifies AES-SIV, a mode designed by Phil Rogaway and Tom Shrimpton (and standardized by Dan Harkins) that fails gracefully when this happens.

The core trick: the IV isn't random — it's derived deterministically from the plaintext and associated data. SIV runs in two passes:

• S2V (String-to-Vector): a PRF built on CMAC that absorbs a vector of associated-data strings plus the plaintext and outputs a 128-bit value. This value is the authentication tag.
• AES-CTR: that same tag is used as the counter-mode IV to encrypt the plaintext.

The ciphertext is just tag || ctr_output. To decrypt, you run CTR with the embedded tag, then recompute S2V over the recovered plaintext and check it matches. Because the IV is a function of the plaintext, repeating an encryption call with identical inputs yields identical ciphertexts — and the only thing an attacker learns from "nonce reuse" is whether two plaintexts were equal. No key leakage, no forgery oracle. Rogaway called this misuse-resistant AEAD, and it's now the gold standard for any context where nonces are awkward.

The associated-data vector is the second clever bit. Most AEAD modes take a single AD blob. SIV takes a list of AD strings, each independently authenticated. This means you can stuff in a nonce, a header, a context label, and a timestamp as separate fields and the construction handles them unambiguously — no "length extension" pitfalls, no manual canonicalization. If you do supply a nonce as one of the AD strings and it's unique, SIV is also a conventional nonce-based AEAD with standard security. If the nonce repeats or is absent, you degrade to deterministic encryption rather than catastrophe.

Where it actually shows up:

• Key wrapping. When you encrypt a data key with a key-encryption key, there's no natural nonce. AES-SIV replaces the older RFC 3394 AES Key Wrap in many systems precisely because it adds associated-data binding and arbitrary-length payloads.
• Cloud KMS envelopes. Several KMS implementations use SIV-family modes internally for deterministic, idempotent re-encryption.
• 802.11 / 802.1AE follow-ons and MIKEY-SAKKE use SIV variants.
• AES-GCM-SIV (RFC 8452, 2019) — Google's higher-performance successor — directly descends from this design, swapping CMAC for POLYVAL but keeping the synthetic-IV idea.

The cost: two passes. SIV is not online — you can't stream encrypt without buffering, because you must compute the tag before you can encrypt. That's the price of misuse resistance. For high-throughput TLS-style streaming, you still want GCM or ChaCha20-Poly1305 with disciplined nonces. For key wrapping, database field encryption, deterministic search tokens, or any "encrypt this small blob safely" use case, SIV is almost always the right answer.

The RFC itself is unusually readable — it presents S2V with a worked example using the doubling-in-GF(2¹²⁸) trick borrowed from CMAC, and the test vectors are reproducible by hand on a whiteboard if you're patient.