Summary

  • RFC 9771 turns familiar AEAD adjectives into four different claim families; confusing those families can make a true statement about an algorithm misleading at the deployment boundary.
  • A defensible procurement or approval decision needs a property receipt connecting the precise claim to its proof notion, construction and version, API behavior, negative tests, key lifecycle, and protocol integration.

The adjective was never the assurance

“Authenticated encryption” sounds like a completed security decision. It is not. It names a useful primitive whose protection depends on a contract among an algorithm, a key and nonce discipline, associated data, an API, and the protocol state surrounding them. RFC 9771, published by the IRTF's Crypto Forum Research Group in May 2025, matters because it refuses to flatten that contract into one quality label.

The document is Informational, not an Internet Standard, and it does not certify algorithms for deployment. Its power is taxonomic. It separates conventional security from properties that strengthen security against a more capable adversary; it then separates both from implementation properties and from additional functionality that changes the interface itself. That makes RFC 9771 a useful control document for buyers, reviewers and operators: it tells them what kind of sentence they are hearing before they decide what evidence the sentence requires.

The conventional interface, inherited from RFC 5116, takes a key, nonce, associated data and plaintext, and returns ciphertext; decryption returns plaintext or failure. Even this compact interface hides an operational obligation: a nonce must be unique for each invocation under a key. A product sheet saying “AES-GCM” does not reveal who owns that uniqueness, whether it survives a snapshot restore, how concurrent senders divide the nonce space, or whether an accelerator and software fallback share state.

RFC 9771 widens the vocabulary without removing those questions. The result is not a menu from which more adjectives automatically mean more safety. It is a map of distinct proof obligations.

Four families, four kinds of evidence

Claim family What the claim changes Evidence that should accompany it
Conventional security The baseline confidentiality and ciphertext integrity goal Exact construction, parameters, security notion, concrete limits, test vectors and usage limits
Additional security property The adversary gains a capability, such as nonce repetition, multiple users, leakage or early plaintext release Separate confidentiality/integrity claim, formal notion, non-equivalence disclosures and misuse-specific negative tests
Implementation property How the computation can be carried out Measured implementation path, memory and pass behavior, buffering/verification boundary, hardware and fallback parity
Additional functionality The caller gets a different interface, such as updates or selectable ciphertext expansion New API contract, revised conventional notion, state transitions, compatibility rules and failure semantics

This division exposes a common assurance error. “Single pass,” “parallelizable” and “streamable” describe ways an implementation can process data. They do not themselves prove confidentiality or integrity. RFC 9771 explicitly notes that a streamable construction may also need blockwise security and integrity when unverified plaintext is released. A throughput benchmark therefore cannot serve as the security receipt for a streaming API.

The reverse error also occurs. A formal result for a construction does not prove that a wrapper preserves the result. If a decryptor releases bytes before the authentication tag is verified, the application has entered the release-of-unverified-plaintext, or RUP, setting. Conventional confidentiality is impossible once plaintext is deliberately released; the relevant integrity and awareness goals are different. A buffered API and an incremental API using the same primitive can therefore carry materially different claims.

Additional functionality makes the boundary clearer still. RFC 9771 places incremental authenticated encryption and robust authenticated encryption in an appendix because they require interfaces beyond conventional AEAD. In robust authenticated encryption, the caller selects a ciphertext expansion, often called stretch, trading length for the strongest integrity available at that expansion. Here “robust” is not “key robustness,” a synonym sometimes used for key commitment. An approval record that stores only the word “robust” has already lost the distinction that mattered.

Near-synonyms are where assumptions hide

Nonce-misuse resilience and nonce-misuse resistance sound interchangeable. RFC 9771 says they are not. Resilience protects messages using fresh nonces even when an adversary causes nonce repetition elsewhere. Resistance also protects messages under repeated nonces, except for the unavoidable leakage when the same plaintext is repeated under the same nonce. Resistance implies resilience; resilience does not imply resistance.

That distinction changes a test plan. For a resilience claim, reviewers must show that a repeated-nonce incident does not contaminate fresh-nonce traffic. For a resistance claim, they must also characterize confidentiality and integrity for the traffic that actually reused the nonce. AES-GCM-SIV in RFC 8452 is a standardized example of a misuse-resistant construction. Its existence does not transfer misuse resistance to ordinary GCM, nor does it prove that a surrounding library correctly manages keys, message limits or error paths.

Commitment has a similar trap. Key commitment asks whether one ciphertext can be valid under different keys. Full commitment also accounts for different nonces, associated data and plaintext. Full commitment implies key commitment, not the other way around. The difference becomes operational when the application uses successful decryption to discover context: which tenant, account, conversation or envelope produced this ciphertext? Research on context-discovery attacks shows why ambiguity among valid contexts is not merely terminological. But a commitment claim still needs to identify the construction, context encoding, tag length and proof notion. The word cannot bind what the system failed to encode.

From property statement to property receipt

A property receipt is a compact, versioned evidence object. It should be readable by procurement, security engineering, platform operations and incident response without asking them to infer one another's assumptions.

It begins with the exact property and RFC 9771 family. “Nonce-misuse resistant confidentiality and integrity” is a claim; “safer nonces” is marketing. “Streamable with no plaintext released before successful verification” is an interface claim; “streaming ready” is not. Where confidentiality and integrity use different notions, both must be named. RFC 9771 says alternative notions need an equivalence proof or a disclosure that they are not equivalent.

The receipt then freezes the subject of the evidence: algorithm and construction, parameter set, tag length, provider or library, version and build, CPU or accelerator path, and any software fallback. A proof about a design and a conformance test against a binary answer different questions; the receipt needs both without pretending they are interchangeable.

The interface section records inputs, output-release timing, the tag-verification boundary, chunk ordering, cancellation and error semantics. It names who constructs nonces and associated data. It states whether failed decryption produces no output, buffered output, partial output, or an error after the caller may already have acted. Those are not low-level details. They determine which security model the deployment inhabits.

Negative tests should be generated from the property rather than copied from a generic cipher checklist. Depending on the claim, they include repeated nonces, wrong keys, altered associated data, cross-context ciphertexts, truncated and forged tags, reordered or duplicated chunks, early-output checks, process rollback, snapshot restore, counter exhaustion, key-phase transitions and software/offload disagreement. A passing negative test is observed behavior, not a proof; a proof is not evidence that the tested API implemented its premises.

The key-lifecycle section records generation and derivation, key identity, nonce and sequence scope, concurrency rules, usage ceilings, rotation, destruction, backup and restore, and aggregation across users. RFC 8645 describes rekeying mechanisms, but a deployment must still show which trigger it implements and how old and new state overlap. The receipt should expire when a provider version, offload path, nonce allocator, persistence model or rotation policy changes.

Finally, protocol integration supplies the evidence between the primitive and the wire. TLS 1.3 builds record nonces from sequence state; QUIC adds packet-number and key-phase behavior. The relevant questions include retry and replay paths, crash recovery, migration, record framing, transcript or context binding, peer interoperability and whether hardware termination preserves the same failure contract. The algorithm name sits inside this system. It does not describe the system.

What a buyer can ask for now

RFC 9771 makes a precise request possible: “For every non-conventional AEAD property you claim, provide the exact security notion, the implementation and version to which it applies, the API behavior that preserves its premises, the negative tests that exercise its boundary, the key-lifecycle controls, and the protocol paths covered.”

A supplier may answer that a property is unsupported, applies only to one path, or remains unproved under a particular failure mode. Those are useful answers. They create an explicit boundary that can be priced, monitored and revisited. The dangerous answer is a property name with no owner and no expiry, because it turns a conditional result into permanent institutional memory.

Sources