Symmetric Encryption and Block Ciphers Questions

Direct answer

AES-SIV (Synthetic Initialization Vector) is a deterministic authenticated-encryption-with-associated-data (AEAD) mode: instead of requiring the caller to supply a fresh nonce, it derives its own internal initialization vector (IV) from the plaintext and associated data (AAD) via a pseudorandom function (PRF) called S2V, then uses that synthetic IV to drive counter (CTR) mode encryption. Because the IV is a deterministic function of the input rather than external randomness, encrypting the exact same (plaintext, AAD) pair twice always produces the exact same ciphertext, and there is no external nonce for a caller to ever accidentally reuse, which is exactly what makes it nonce-misuse-resistant.

Structured elaboration

The S2V construction, at a high level: S2V ("string to vector") takes a vector of inputs, the AAD component(s) followed by the plaintext, and combines them using a cipher-based MAC (CMAC, built from a block cipher) chained together with a "doubling" operation over the finite field GF(2^128) (roughly, multiplying the running value by the field element corresponding to $x$ before XORing in the next component's CMAC), producing a single 128-bit synthetic IV that depends on every input component. That synthetic IV then seeds CTR-mode encryption under a second, independent key.

Why it is deterministic: the whole pipeline, CMAC and the doubling chain, is a pure function of its inputs and the key; there is no randomness or external nonce anywhere in it. The same (AAD, plaintext) under the same key always produces the same synthetic IV, and CTR mode with the same IV under the same key always produces the same keystream, so the ciphertext is identical every time.

Why that provides nonce-misuse resistance: traditional nonce-based modes like Galois/Counter Mode (GCM) derive their security proof from the nonce never repeating; if a caller ever reuses a GCM nonce, the scheme's confidentiality and authenticity guarantees both collapse (the keystream repeats, directly leaking the plaintext XOR, and the authentication key's internal state becomes solvable). SIV sidesteps the entire failure category by removing the external nonce as an attack surface: there is nothing for a caller to misuse, because SIV never asks for it.

Where determinism is acceptable, and where it is not: deterministic encryption is desirable when the caller cannot guarantee fresh, unique randomness (embedded devices with weak boot entropy, storage/deduplication systems that specifically want equal records to look equal so they can be deduplicated) or where messages are inherently unique enough that repeats are not sensitive (each message includes a unique ID as AAD, for instance). It is undesirable whenever equal-looking ciphertext for equal plaintext is itself sensitive information, for example authenticating a small, low-entropy field (a yes/no flag, a status code) where an observer who sees two identical ciphertexts learns the two underlying values were equal, without ever decrypting either.

Worked example

from cryptography.hazmat.primitives.ciphers.aead import AESSIV
key = AESSIV.generate_key(bit_length=256)  # split into two independent 128-bit subkeys
siv = AESSIV(key)

pt = b"invoice #4471: $250.00"
ct_a = siv.encrypt(pt, [b"customer:118"])
ct_b = siv.encrypt(pt, [b"customer:118"])
print("same (plaintext, AAD), no nonce supplied, twice:")
print(" identical ciphertext (deterministic):", ct_a == ct_b)

ct_c = siv.encrypt(b"invoice #4471: $250.01", [b"customer:118"])  # one cent different
print(" different plaintext -> different ciphertext:", ct_c != ct_a)

ct_d = siv.encrypt(pt, [b"customer:999"])  # different AAD, same plaintext
print(" different AAD, same plaintext -> different ciphertext:", ct_d != ct_a)

Output:

same (plaintext, AAD), no nonce supplied, twice:
 identical ciphertext (deterministic): True
 different plaintext -> different ciphertext: True
 different AAD, same plaintext -> different ciphertext: True

This confirms the two claims directly: identical inputs give identical output (the determinism the S2V construction guarantees), and any change to either the plaintext or the AAD (both are inputs to S2V's chain) changes the ciphertext, since a different input to a PRF-based chain produces, with overwhelming probability, a different synthetic IV.

Trade-offs and pitfalls

The most common mistake is describing SIV as "just GCM but safer" without naming the actual price paid: determinism intentionally reveals equality of (AAD, plaintext) pairs, a strictly different (and for some applications unacceptable) leak profile from GCM's nonce-reuse failure mode, which leaks plaintext XOR and can enable full forgery, a much more severe but avoidable failure if nonces are managed correctly. Second, SIV requires buffering the entire plaintext before encryption can begin (S2V has to process the whole message to produce the synthetic IV before CTR mode can start), which makes it unsuitable for streaming very large or unbounded messages the way a nonce-based streaming AEAD can handle; SIV is a better fit for whole, bounded messages (key wrapping, records, small documents) than for high-throughput streaming pipelines. Finally, the two internal keys (the CMAC key for S2V, and the CTR encryption key) must be cryptographically independent for the security proof to hold; a real implementation should never derive them from each other or from any related process.

Direct answer

XTS (a tweaked-codebook mode with ciphertext stealing, standardized for disk encryption in IEEE 1619) encrypts each disk sector independently under a "tweak" derived from the sector number, so identical plaintext in two different sectors produces different ciphertext, and repeated blocks within one sector do not repeat in ciphertext either, unlike plain ECB (Electronic Codebook mode, where identical plaintext blocks always produce identical ciphertext blocks). It deliberately carries no message authentication code or tag: a bit flip in the ciphertext decrypts "successfully" into silently corrupted plaintext rather than raising an error. Adding integrity while keeping random-access performance means layering an out-of-band authentication tag per sector (or per larger block), accepting either extra storage or extra I/O to fetch it, or switching the sector-encryption construction entirely to an AEAD (Authenticated Encryption with Associated Data) mode that carries its own tag.

Structured elaboration

How XTS achieves per-sector confidentiality. XTS-AES uses two independent AES keys: one encrypts the actual sector data, the other encrypts the sector's "tweak" (its sector number) to produce a per-sector, per-block whitening value that is XORed into the data before and after the core AES-ECB step (the "XEX" construction: XOR-Encrypt-XOR). Because the tweak depends on the sector number, two sectors holding byte-for-byte identical plaintext still produce entirely different ciphertext, and within one sector, the whitening value also advances per 16-byte block, so repeated 16-byte blocks inside a sector do not produce repeated ciphertext blocks the way ECB would. Ciphertext stealing handles sector sizes that are not an exact multiple of the AES block size by folding the final partial block into the second-to-last block rather than padding, which keeps ciphertext length exactly equal to plaintext length, a hard requirement for a fixed-size disk sector.

Why XTS deliberately omits integrity. Two constraints, by design, not oversight: a physical disk sector traditionally has a fixed size (512 or 4096 bytes) with essentially no spare room for an extra authentication tag without changing the sector format itself, and XTS's threat model is specifically confidentiality of data at rest against an adversary who steals the physical medium, not defense against an adversary who can actively tamper with sector contents on a system otherwise still trusted. The specification's own authors treated authenticity as a separate, higher-layer concern (a filesystem checksum, a signed manifest, or a dedicated authenticated mode) rather than trying to fit it into a fixed physical sector.

Adding integrity while keeping random access. Two practical directions:

1. Out-of-band tag storage: keep XTS (or replace it with a plain non-authenticated mode) for the bulk data, and store a per-sector authentication tag in a separate reserved region of the disk, indexed by sector number, read alongside the data sector during verification. This is what real full-disk-encryption integrity layers (dm-integrity paired with dm-crypt, or filesystem-level authenticated encryption) actually do. Cost: an extra I/O (or extra bytes in an enlarged logical sector) per read and write, and a consistency problem, since the tag and the data must be updated atomically or a crash between the two writes leaves a tag that no longer matches valid data; this typically needs journaling or copy-on-write to avoid a torn write corrupting the tag/data pairing.
2. Switch construction to a per-sector AEAD: replace XTS with an AEAD mode (AES-GCM, or a nonce-misuse-resistant construction) keyed and nonced per sector, which carries its own tag in the AEAD output. This gets full integrity in one construction rather than two coordinated pieces, but the tag (commonly 16 bytes) no longer fits in a bare 512-byte physical sector, forcing a move to a larger logical sector size (for example treating four 512-byte physical sectors as one 2048-byte logical AEAD unit, or working natively at 4096-byte "advanced format" sectors) to absorb the overhead as a small percentage rather than growing every sector individually.

Worked example

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

# AES-XTS needs a 2*keylen key: key1 (data unit encryption) || key2 (tweak encryption).
# AES-128-XTS => 32-byte combined key. Pinned for reproducibility.
key = bytes(range(32))

def xts_encrypt_sector(sector_number: int, sector_data: bytes) -> bytes:
    # cryptography's XTS mode takes the tweak (sector number) as a 16-byte little-endian value.
    tweak = sector_number.to_bytes(16, "little")
    enc = Cipher(algorithms.AES(key), modes.XTS(tweak)).encryptor()
    return enc.update(sector_data) + enc.finalize()

def xts_decrypt_sector(sector_number: int, ct: bytes) -> bytes:
    tweak = sector_number.to_bytes(16, "little")
    dec = Cipher(algorithms.AES(key), modes.XTS(tweak)).decryptor()
    return dec.update(ct) + dec.finalize()

# identical plaintext content in two different sectors
plaintext_512 = (b"A" * 16) * 32  # 512 bytes, one AES-disk sector, all-identical 16-byte blocks
ct_sector5 = xts_encrypt_sector(5, plaintext_512)
ct_sector9 = xts_encrypt_sector(9, plaintext_512)

print("same plaintext, different sector -> different ciphertext:", ct_sector5 != ct_sector9)
# also confirm identical repeated 16-byte blocks WITHIN one sector don't repeat in ciphertext
# (unlike ECB, where they would be identical)
blocks = [ct_sector5[i:i+16] for i in range(0, len(ct_sector5), 16)]
print("no repeated ciphertext block within one sector:", len(set(blocks)) == len(blocks))

# round trip
pt_back = xts_decrypt_sector(5, ct_sector5)
print("round trip ok:", pt_back == plaintext_512)

# no integrity: flip one ciphertext bit, decryption 'succeeds' silently with corrupted plaintext
tampered = bytearray(ct_sector5)
tampered[100] ^= 0x01
pt_tampered = xts_decrypt_sector(5, bytes(tampered))
print("tampered ciphertext decrypts without error:", True)  # XTS API raises nothing
print("tampered plaintext differs from original:", pt_tampered != plaintext_512)
# how much of the plaintext is corrupted? XTS is a wide-block mode over the AES block containing
# the flipped bit; because ciphertext stealing links the last two blocks, corruption can spread
# within that data unit but never propagates to OTHER sectors.
diff_bytes = sum(1 for a, b in zip(pt_tampered, plaintext_512) if a != b)
print(f"bytes changed in the 512-byte sector after a 1-bit ciphertext flip: {diff_bytes}")

Output:

same plaintext, different sector -> different ciphertext: True
no repeated ciphertext block within one sector: True
round trip ok: True
tampered ciphertext decrypts without error: True
tampered plaintext differs from original: True
bytes changed in the 512-byte sector after a 1-bit ciphertext flip: 16

Trade-offs and pitfalls

The tampered-ciphertext test above is the core of why XTS alone is unsafe against an active adversary: flipping one ciphertext bit changes 16 bytes of recovered plaintext (one AES block worth, since this example's sector length is an exact multiple of the block size and so never invokes ciphertext stealing) and the decrypt call raises nothing at all. A filesystem or application reading that sector has no signal that anything is wrong unless a higher layer independently checks integrity.

Metadata overhead versus security is a real, not a rounding-error, trade-off: an out-of-band tag region adds storage proportional to sector count and extra I/O per access, while a per-sector AEAD switch adds storage proportional to logical-sector count but concentrates it (fewer, larger authenticated units), reducing per-unit overhead percentage at the cost of larger minimum write granularity (updating one physical sub-sector now requires re-authenticating the whole logical AEAD unit it belongs to).

Do not reach for XTS when you can afford full AEAD per unit in the first place; XTS's specific value is being tightly optimized for the constrained, integrity-out-of-scope, fixed-physical-sector case. If the storage layer can tolerate a variable or padded unit size, a purpose-built AEAD-based sector scheme is simpler to reason about than XTS-plus-bolted-on-tags.

Direct answer

Confusion is the design goal of making the relationship between the key and the ciphertext as complex and nonlinear as possible, so an attacker cannot express the key algebraically from known plaintext/ciphertext pairs. Diffusion is the goal of spreading each input bit's influence across as much of the output as possible, so that statistical patterns in the plaintext do not survive into the ciphertext. Feistel networks and Substitution-Permutation Networks (SPNs) are the two classical paradigms for achieving both, and they differ mainly in HOW they guarantee invertibility (the ability to decrypt) while doing so.

Structured elaboration

Feistel networks. Each round splits the block into two halves and computes $(L, R) \to (R, L \oplus F(R, K_i))$, where F is a round function that need NOT itself be invertible or even a permutation: it can be arbitrarily complex, since the Feistel structure's swap-and-XOR shape guarantees the WHOLE round is invertible regardless of what F does inside. Confusion comes from F's nonlinearity (S-boxes, modular arithmetic); diffusion builds up gradually as each half repeatedly feeds into the other across many rounds. DES (the Data Encryption Standard, a 16-round Feistel cipher) is the classic real-world example.

Substitution-Permutation Networks (SPNs). Every round transforms the FULL block through two layers: a substitution layer (parallel, independent, small nonlinear S-boxes, providing confusion) and a permutation/mixing layer (a linear transformation that spreads bits across positions, providing diffusion). Unlike a Feistel round function, every individual component here MUST be invertible on its own, since there is no swap-based trick to fall back on; decryption simply runs the inverse of each layer in reverse order. AES (a full-block SPN) is the classic real-world example.

Comparison.

Worked example

Diffusion made concrete: flip exactly ONE plaintext bit and measure how many output bits change, for AES (a full SPN with 10 rounds) versus a toy 4-round Feistel cipher whose round function is deliberately weak (pure XOR, no substitution at all), to show what diffusion failure actually looks like when the nonlinear/mixing machinery is missing:

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes

def hamming(a, b): return sum(bin(x ^ y).count("1") for x, y in zip(a, b))

key = bytes.fromhex("2b7e151628aed2a6abf7158809cf4f3c"[:32])
p1 = bytes.fromhex("6bc1bee22e409f96e93d7e117393172a"[:32])
p2 = bytearray(p1); p2[0] ^= 0x01
p2 = bytes(p2)

enc = Cipher(algorithms.AES(key), modes.ECB()).encryptor()
c1 = enc.update(p1) + enc.finalize()
enc2 = Cipher(algorithms.AES(key), modes.ECB()).encryptor()
c2 = enc2.update(p2) + enc2.finalize()
print(f"AES: output bits changed = {hamming(c1, c2)} / 128 ({hamming(c1, c2)/128:.1%})")

def weak_round_function(half, round_key):
    return bytes(a ^ b for a, b in zip(half, round_key))  # pure XOR: no nonlinearity, no mixing

def tiny_feistel_encrypt(block16, rounds, round_keys):
    left, right = block16[:8], block16[8:]
    for r in range(rounds):
        f_out = weak_round_function(right, round_keys[r % len(round_keys)])
        left, right = right, bytes(a ^ b for a, b in zip(left, f_out))
    return left + right

round_keys = [bytes([i]*8) for i in range(1, 5)]
c1f = tiny_feistel_encrypt(p1, 4, round_keys)
c2f = tiny_feistel_encrypt(p2, 4, round_keys)
print(f"toy weak Feistel: output bits changed = {hamming(c1f, c2f)} / 128 ({hamming(c1f, c2f)/128:.1%})")

Output:

AES: output bits changed = 60 / 128 (46.9%)
toy weak Feistel: output bits changed = 1 / 128 (0.8%)

AES's full round structure (S-boxes plus MixColumns) spreads a single flipped input bit to nearly half of the output bits, close to the ideal 50% an unpredictable random function would give. The toy Feistel cipher, built with a deliberately non-diffusing (pure-XOR) round function, barely moves the needle: the flipped bit stays almost entirely localized. This isolates WHY the round function's internal design matters, not just the number of rounds: a real Feistel cipher's F includes genuine nonlinear substitution, which is what actually produces AES-level diffusion in a Feistel structure too, over enough rounds.

Trade-offs and pitfalls

• Neither paradigm is universally "better"; the choice is a real engineering trade-off between round-function freedom (Feistel) and per-round parallelism and hardware throughput (SPN).
• A common misconception is that Feistel structures are inherently weaker; DES's real weaknesses (small 56-bit effective key, not enough rounds by modern standards) are separate from the Feistel PARADIGM itself, which is still used in modern designs (some lightweight and format-preserving ciphers).
• Comparing round counts alone across paradigms is misleading: a Feistel round only transforms half the block, so "rounds" are not directly comparable between a 16-round Feistel cipher and a 10-round SPN without accounting for how much of the state each round actually touches.

Direct answer

Derive the per-message nonce as a truncated keyed commitment (a message authentication code, computed with a key independent of the payload key) over the associated data and the whole plaintext, then run standard AES-GCM (Galois/Counter Mode) using that derived value as the nonce; on decrypt, after GCM's own tag verifies, independently recompute the expected nonce from the recovered plaintext and reject unless it matches, which binds the nonce to (associated data, plaintext) even though GCM itself never checks that binding. This buys the misuse-resistance property that re-encrypting the identical message is always safe, at the honest cost that it is still a two-pass construction, exactly like the already-standardized AES-SIV and AES-GCM-SIV it is imitating, so its real advantage over those is a cheaper first pass, not avoiding the second pass.

Structured elaboration

Precise construction. Two independently keyed primitives: K1 for the commitment (an HMAC, hash-based message authentication code, over associated data then plaintext, truncated to 96 bits for GCM's nonce), K2 for the GCM payload encryption. Independent keys matter: reusing the same key for both the commitment and the cipher risks related-key issues, where an attacker who can influence or observe the commitment's output space gains leverage reasoning about the cipher under a related key; separating them is cheap insurance and standard practice whenever two different cryptographic roles are combined in one construction.

Security trade-offs. Deriving the nonce from the message content means encrypting the identical (associated data, plaintext) pair twice always reproduces the identical nonce and ciphertext, so an accidental nonce collision on two different plaintexts, catastrophic for plain GCM, simply cannot happen here: the nonce is a function of the plaintext, not an independent random draw. The honest cost is the mirror image of that guarantee: two equal plaintexts under the same associated data are now linkable, since equal input always produces equal output, exactly the same trade-off any deterministic or synthetic-IV scheme accepts.

Performance framing. This construction does not avoid the two-pass cost that AES-SIV and AES-GCM-SIV already pay, since deriving the nonce still requires seeing the entire plaintext before GCM encryption can begin, demonstrated directly in the worked example's byte-counting pass. What it can offer instead is a cheaper first pass: a plain HMAC evaluation (a single hash function pass, which hardware SHA extensions accelerate well) in place of a second block-cipher-based MAC pass, the CMAC-style step AES-SIV's S2V ("string-to-vector") construction uses, whose cost is comparable to a second CTR-mode encryption. So the realistic performance story is "one cheap hash pass plus one AES-GCM pass," not "single-pass, GCM-speed misuse resistance," and that distinction matters for anyone evaluating the trade-off honestly.

Pitfalls.

1. Subtle leak, equality linkability: demonstrated directly, encrypting the same (AD, plaintext) pair twice reproduces the identical ciphertext, letting an observer detect message repetition even without the key, the same cost any SIV-style deterministic scheme accepts.
2. Double-encryption / key-reuse footgun: if K2 is ever reused by some other part of the system for ordinary, non-derived-nonce GCM, an attacker able to influence which path a message takes could hunt for nonce collisions across the two uses of the same key, since key separation between K1 and K2 alone does not protect K2 from being reused elsewhere in the system under a different nonce-generation scheme; K2 needs to be scoped exclusively to this construction.
3. IV-check-replaces-tag-check trap: because the derived nonce is functionally a commitment over the plaintext, an implementer could be tempted to treat "the recomputed nonce matches" as sufficient authentication and skip GCM's own tag check. That reasoning is backwards: the nonce only proves what the sender committed to; GCM's own tag is what actually prevents an attacker with no key from tampering with ciphertext bits. The demonstrated design keeps GCM's own AEAD verification (Authenticated Encryption with Associated Data) as the first, primary gate, hybrid_decrypt calls the GCM decrypt before ever checking the nonce binding, and adds the nonce-rebinding check strictly on top, precisely to avoid this trap; the tamper test above confirms GCM's tag alone already catches a corrupted ciphertext.

Worked example

import hmac as hmac_mod
import hashlib
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

# Two independently-keyed primitives (key separation to avoid related-key issues).
K1 = bytes(range(16))          # keyed commitment / synthetic-IV derivation key
K2 = bytes(range(16, 32))      # AES-128-GCM payload key

def keyed_commitment(k1: bytes, associated_data: bytes, plaintext: bytes) -> bytes:
    # Stand-in for KMAC/streaming-HMAC over the plaintext: in a real streaming
    # implementation this is computed incrementally as bytes arrive (HMAC supports
    # .update()), so it costs one extra pass over the data, not a second copy of it.
    mac = hmac_mod.new(k1, digestmod=hashlib.sha256)
    mac.update(associated_data)
    mac.update(plaintext)
    return mac.digest()

def derive_iv(k1: bytes, associated_data: bytes, plaintext: bytes) -> bytes:
    commitment = keyed_commitment(k1, associated_data, plaintext)
    return commitment[:12]  # truncate to 96 bits for GCM

def hybrid_encrypt(k1, k2, associated_data, plaintext):
    iv = derive_iv(k1, associated_data, plaintext)
    ct = AESGCM(k2).encrypt(iv, plaintext, associated_data)
    return iv, ct

def hybrid_decrypt(k1, k2, associated_data, iv, ct):
    pt = AESGCM(k2).decrypt(iv, ct, associated_data)
    # Reject unless the IV matches what an honest sender would have derived
    # (binds IV to (AD, plaintext) even though GCM itself does not check this).
    if not hmac_mod.compare_digest(iv, derive_iv(k1, associated_data, pt)):
        raise ValueError("IV/plaintext binding check failed")
    return pt

AD = b"stream-7"

pt1 = b"first message body............."
iv1, ct1 = hybrid_encrypt(K1, K2, AD, pt1)
print("round trip ok:", hybrid_decrypt(K1, K2, AD, iv1, ct1) == pt1)

# --- 1. correctness / misuse-resistance intuition: an accidental IV collision from a
#     bad RNG would be catastrophic for plain GCM but here the IV is a function of the
#     message, so encrypting the SAME (AD, plaintext) twice is safe (idempotent) ---
iv1_again, ct1_again = hybrid_encrypt(K1, K2, AD, pt1)
print("re-encrypting identical (AD,PT) reproduces the same IV (safe, no keystream reuse):",
      iv1_again == iv1 and ct1_again == ct1)

# --- 2. the promised trade-off: this is NOT free. Equal (AD, plaintext) pairs are
#     LINKABLE, because the IV (and hence ciphertext) is deterministic in them. ---
pt2 = b"second, DIFFERENT message body."
iv2, ct2 = hybrid_encrypt(K1, K2, AD, pt2)
print("different plaintext -> different IV (expected):", iv2 != iv1)
print("equal plaintexts leak equality via identical IV/ciphertext (the honest cost):",
      hybrid_encrypt(K1, K2, AD, pt1)[1] == ct1)

# --- 3. tamper check: flipping the ciphertext (and hence recovered plaintext) must be
#     caught by GCM's own tag, independent of the extra IV-binding check ---
tampered = bytearray(ct1); tampered[0] ^= 0x01
try:
    hybrid_decrypt(K1, K2, AD, iv1, bytes(tampered))
    print("TAMPER NOT DETECTED (bug)")
except Exception as e:
    print("tampered ciphertext rejected by GCM tag:", type(e).__name__)

# --- 4. streaming cost: derive_iv() requires seeing the WHOLE plaintext before GCM
#     encryption can start, because the IV depends on the commitment over all of P.
#     Demonstrate the two-pass cost directly by counting bytes touched. ---
big_pt = b"X" * 1_000_000
touches = {"commitment_pass": 0, "gcm_pass": 0}
mac = hmac_mod.new(K1, digestmod=hashlib.sha256)
mac.update(AD)
CHUNK = 65536
for i in range(0, len(big_pt), CHUNK):
    mac.update(big_pt[i:i+CHUNK])
    touches["commitment_pass"] += len(big_pt[i:i+CHUNK])
iv_big = mac.digest()[:12]
ct_big = AESGCM(K2).encrypt(iv_big, big_pt, AD)
touches["gcm_pass"] = len(big_pt)
print("bytes touched in pass 1 (commitment) and pass 2 (GCM):", touches,
      "-> total work = 2x plaintext size, confirming the two-pass cost")

Output:

round trip ok: True
re-encrypting identical (AD,PT) reproduces the same IV (safe, no keystream reuse): True
different plaintext -> different IV (expected): True
equal plaintexts leak equality via identical IV/ciphertext (the honest cost): True
tampered ciphertext rejected by GCM tag: InvalidTag
bytes touched in pass 1 (commitment) and pass 2 (GCM): {'commitment_pass': 1000000, 'gcm_pass': 1000000} -> total work = 2x plaintext size, confirming the two-pass cost

Trade-offs and pitfalls

Implementation complexity roughly doubles versus plain GCM: two independent key schedules to manage, one extra hashing pass over the full plaintext, and the loss of single-pass streaming entirely, since the whole message must be buffered before the nonce can be derived, exactly the same structural cost RFC 5297 (AES-SIV) and RFC 8452 (AES-GCM-SIV) already pay.

This is a legitimate design exercise that demonstrates the right instinct, deriving the nonce from content to buy misuse resistance, but a production system should prefer the already-standardized, peer-reviewed constructions (AES-SIV or AES-GCM-SIV) over a bespoke hybrid like this one. Subtle mistakes in exactly this kind of home-grown combination of two primitives, especially around key separation and which check gates security, are a recurring, historically real failure mode in applied cryptography, and the standardized alternatives have already had that scrutiny applied to them.

Direct answer

AES-SIV is preferable to nonce-based authenticated-encryption-with-associated-data (AEAD) modes like AES-Galois/Counter Mode (GCM) or ChaCha20-Poly1305 whenever the deployment cannot reliably guarantee a fresh, unique nonce for every encryption, deterministic output is actually useful (storage deduplication, content-addressable systems), or the data is long-lived at-rest data where a single nonce-reuse mistake anywhere in a multi-year lifetime would be catastrophic. It is the wrong choice whenever low-latency streaming throughput matters, or whenever the deterministic leak (equal plaintext plus equal AAD always produces equal ciphertext) is itself unacceptable for the data being protected.

Structured elaboration

Storage and deduplication: a storage system that wants to detect and collapse duplicate encrypted blocks (a common design in backup and content-addressable storage) needs identical plaintexts to produce identical ciphertexts, which is exactly what SIV's determinism provides and what a nonce-based mode structurally prevents (since a fresh nonce makes even identical plaintexts produce different ciphertexts every time, defeating deduplication entirely).

Environments with poor randomness: an embedded device with a weak or predictable random-number generator at boot cannot safely generate the fresh nonces GCM's proof requires; a single nonce collision under GCM is catastrophic (keystream reuse leaks plaintext directly, and the authentication key's internal state becomes algebraically solvable, enabling forgery). SIV removes the nonce entirely, so a weak RNG at boot cannot cause this specific failure category, though the device still needs the underlying key material to be properly random.

Long-term data-at-rest protection: for records that will sit encrypted for years, the operational risk of a nonce ever repeating across that entire lifetime (software bugs, clock resets, VM snapshot/restore duplicating a counter's starting state) compounds with every additional record written. SIV's misuse resistance means that even a caller-side bug that would otherwise cause nonce reuse has no catastrophic failure mode to trigger, a meaningfully different risk profile for data you cannot afford to be wrong about even once.

Where streaming or low-latency requirements dominate instead: SIV's S2V step has to process the entire (AAD, plaintext) before producing the synthetic IV that CTR-mode encryption depends on, so encryption cannot begin until the whole message is available; this is a poor fit for high-throughput streaming (live network protocols, large unbounded files) where nonce-based AEAD can begin encrypting and transmitting the first bytes immediately.

Worked example

The concrete trade-off between SIV's deduplication-friendly leak and GCM's much worse nonce-misuse failure, run side by side:

from cryptography.hazmat.primitives.ciphers.aead import AESSIV, AESGCM

siv = AESSIV(AESSIV.generate_key(bit_length=256))
dup1 = siv.encrypt(b"status:active", [b"row:1"])
dup2 = siv.encrypt(b"status:active", [b"row:2"])   # different AAD
dup3 = siv.encrypt(b"status:active", [b"row:1"])   # exact same (plaintext, AAD) as dup1
print("SIV: equal plaintext, different AAD -> ciphertexts differ:", dup1 != dup2)
print("SIV: equal plaintext, same AAD -> ciphertexts match (a duplicate-row signal):", dup1 == dup3)

gcm = AESGCM(AESGCM.generate_key(bit_length=128))
reused_nonce = b"\x00" * 12
g1 = gcm.encrypt(reused_nonce, b"transfer $500 ", None)
g2 = gcm.encrypt(reused_nonce, b"transfer $9999", None)  # SAME nonce misused
xor_ct = bytes(a ^ b for a, b in zip(g1, g2))
xor_pt = bytes(a ^ b for a, b in zip(b"transfer $500 ", b"transfer $9999"))
print("GCM with a misused nonce leaks plaintext XOR directly, no key needed:", xor_ct[:len(xor_pt)] == xor_pt)

Output:

SIV: equal plaintext, different AAD -> ciphertexts differ: True
SIV: equal plaintext, same AAD -> ciphertexts match (a duplicate-row signal): True
GCM with a misused nonce leaks plaintext XOR directly, no key needed: True

This is the core of the trade-off in one comparison: SIV's worst case, under normal correct use, is a bounded, well-understood leak (equal input reveals equal output); GCM's worst case, the moment misuse happens even once, is direct plaintext recovery with no key required. For deployments that cannot guarantee flawless nonce handling forever, SIV's bounded failure mode is the safer default even though GCM has strictly better throughput and no equality leak when used correctly.

Trade-offs and pitfalls

The most common mistake is treating this as "SIV is always safer, use it everywhere"; that ignores the deduplication-signal leak, which is a real, sometimes unacceptable cost (authenticating a low-entropy field like a status flag under SIV lets an observer learn when two records share the same value, without decrypting either). A second pitfall is choosing SIV purely for its misuse resistance in a system that actually has a solid, well-tested nonce-management layer already; in that case GCM or ChaCha20-Poly1305 give strictly better throughput and no equality leak, and SIV's protection is solving a problem that does not exist in that deployment. The right framing is a risk trade: SIV trades a small, well-understood, always-present leak for eliminating a rare-but-catastrophic failure mode; whether that trade is worth it depends entirely on how much you trust your own nonce-management discipline and how sensitive the equality-of-input leak is for that specific data.