Summary

  • RFC 5297 makes nonce reuse less catastrophic: authenticity remains, while an observer can learn when the same plaintext and associated data recur under the same key and nonce.
  • That residual disclosure still matters. A complete receipt must bind the selected SIV mode, ordered associated-data vector, nonce decision, synthetic IV, authentication result, plaintext-release boundary and application outcome.

A safety net is not a new floor

Conventional nonce-based authenticated encryption carries a brittle condition. Repeating a key-and-nonce pair can destroy confidentiality and, for some constructions, integrity. SIV changes the consequence. It first computes a synthetic initialization vector from the associated-data vector and plaintext, then uses that value to drive counter-mode encryption. The authentication value is not an unrelated label attached at the end; it is part of the encryption trajectory.

If a nonce never repeats, SIV offers the ordinary nonce-based security described by RFC 5297. If it does repeat, an attacker still cannot manufacture a ciphertext that decrypts to anything other than FAIL, but can tell whether the same plaintext and the same associated data were protected again with that nonce and key. The system has survived one class of accident and disclosed a relationship between records.

That distinction is easy to erase in governance. A control catalogue says “nonce-misuse resistant.” A product requirement shortens it to “nonce reuse safe.” A capacity team then gives a fixed nonce to a stateless worker because the primitive appears to tolerate it. The adjective has crossed three authority boundaries and become an exemption that the RFC never grants. RFC 5297 says the definition of a nonce precludes reuse. Later AES-GCM-SIV guidance makes the policy point explicit: resistance supplies the best possible security when reuse occurs; it is not intended to be coupled with intentional reuse.

Two modes share an API and not an intention

RFC 5297 supports two legitimate operating modes. In nonce-based authenticated encryption, the nonce occupies the final associated-data position immediately before the plaintext. The application decides what other associated data precedes it. A random nonce should be at least 128 bits and come from a pool with at least 128 bits of entropy; a counter or timestamp can instead be used if the application can preserve its invariant.

In deterministic mode, there is no nonce component. When the protected plaintext is unpredictable to an adversary—such as a cryptographic key—SIV can act as an authenticated key wrapper. Other associated data may still bind a recipient, purpose, algorithm or version.

The ciphertext does not announce which institutional decision produced it. The same library entry point can serve a randomized record channel, a counter-based protocol and deterministic key custody. A successful tag proves the bytes presented to the construction, not that the caller was entitled to select deterministic mode, that the input was suitably unpredictable, or that a nonce-bearing profile actually supplied a fresh nonce. Mode belongs in the authorization and audit record.

The vector is part of the statement

S2V accepts associated data as a vector of distinct variable-length strings. Order and component boundaries therefore belong to the authenticated statement. A tenant, object type, version and recipient are not merely four byte ranges. They occupy named positions in a schema whose interpretation must be shared by producer and consumer.

RFC 5116 exposes one associated-data component. An implementation using that interface must marshal a native SIV vector into one string. That bridge is a semantic control surface. Concatenating ab with c must not become indistinguishable from a with bc; a length-prefix or equally unambiguous encoding has to preserve the vector. Passing authentication proves only that both sides processed the same flattened bytes. It does not prove that two software versions divided or named those bytes the same way.

The component count is also bounded. S2V's security analysis permits at most 127 components in total, and plaintext occupies one of them, leaving 126 associated-data components. An adapter that silently drops, coalesces or reorders a field to fit an interface has changed the authenticated claim even if decryption later succeeds.

Verification is a release gate

SIV splits a 256-, 384- or 512-bit key into equal halves. One drives CMAC/S2V; the other drives AES-CTR. Encryption derives the 128-bit synthetic IV over associated data and plaintext, clears two specified counter bits for CTR processing, and emits that IV followed by ciphertext. Decryption first obtains a candidate plaintext, recomputes S2V over the same vector and candidate, and returns the plaintext only if the recomputed value matches the received IV. Otherwise the result is FAIL.

The internal existence of candidate bytes is not permission to release them. A streaming wrapper that logs, parses, caches or hands those bytes to a caller before the comparison has converted authenticated decryption into speculative plaintext processing. The cryptographic primitive can be correct while the surrounding interface violates the security boundary.

Operational evidence should therefore distinguish decrypt_started, candidate_quarantined, tag_compared, authentication_passed and plaintext_released. A single “decrypt succeeded” event is too late to show whether an untrusted parser already consumed unauthenticated material, and too early to show whether the application accepted the authenticated object.

Equality is a disclosure, not a footnote

Suppose an encrypted control object has only two plausible values. Repeating the same nonce and associated data can reveal when the hidden choice repeats, even though the observer cannot directly read it or forge an alternative. The same applies to wrapped keys drawn from a small or structured space, status flags, acknowledgments, entitlement records or compact commands. Equality can expose cadence, coordination, unchanged policy or repeated identity.

The response to detected reuse is not automatically “rotate everything” or “nothing happened.” It is an evidence question. Which key generation was involved? Which nonce and AD schema? How many objects share the tuple? Were plaintexts high entropy or drawn from a small set? Did all decrypt paths enforce verify-before-release? Was the recurrence expected deterministic wrapping or unintended nonce-based reuse? Without those distinctions, incident handling either understates disclosure or destroys healthy deterministic data in the name of repairing the wrong mode.

The receipt SIV actually needs

A non-secret receipt can join: algorithm and implementation version; key identity and generation; intended mode and application profile; ordered AD component names and digests; nonce source and uniqueness verdict; a protected-item identifier under an appropriate confidentiality policy; synthetic-IV digest; authentication result; release decision; duplicate-tuple classification; equality-exposure assessment; downstream parse and acceptance; and per-key invocation counters.

The IANA assignments—15, 16 and 17 for the three AES-SIV-CMAC key sizes—supply shared vocabulary. They do not supply any of those runtime facts. Nor does a passing test vector prove that production callers preserved vector boundaries, budgets or quarantine behavior. A registry record, a correct primitive and an accepted business object are three different layers of truth.

Sources