Summary

  • RFC 10032 is an IRTF Informational publication reflecting CFRG consensus, not an IETF Standards Track mandate. Its six IANA identifiers create stable names, not deployment obligations.
  • The registry distinguishes AEGIS-128L, AEGIS-256 and four X2/X4 parallel forms, but it does not encode the 128- versus 256-bit tag choice. Parallel modes are optional and should be chosen only when all parties agree on the exact variant.
  • A library self-test can prove that one primitive implementation matches fixed vectors. It cannot prove what peers negotiated, which binary and hardware path ran, how nonces and associated data were constructed, or which suite protected live traffic.
  • An algorithm-custody receipt should join document and registry snapshots, protocol profile, authenticated selection, codepoint, tag length, key and nonce lifecycle, associated-data encoding, runtime path, positive and negative tests, failure behavior, usage counters, fallback and rollback.

Six numbers arrive before one packet

The new entries are neat. The IANA registry assigns 32 to AEAD_AEGIS128L, 33 to AEAD_AEGIS256, 34 and 35 to the two AEGIS-128 parallel degrees, and 36 and 37 to the corresponding AEGIS-256 forms. A configuration screen can expose those names. A library can report them as supported. A standards inventory can mark RFC 10032 as published.

None of those observations answers the operational question: what protected this session?

A registry number is a coordination device. It prevents two specifications from using the same public identifier for incompatible algorithms. RFC 5116, which created the AEAD registry and common interface, makes the boundary unusually explicit: registration is not an endorsement of the algorithm or its security. Nor does the interface decide anti-replay policy or access control. Those decisions belong to the calling protocol and deployment.

RFC 10032 supplies the primitive definitions, parameters, operational guidance and test vectors. It does not define one universal negotiation for TLS, IPsec, QUIC, storage or an application-specific channel. A protocol has to decide whether AEGIS is offered at all, which identifier carries which profile, how tag length is fixed, how keys and nonces are made, what becomes associated data and how failure is handled.

The distance from numeric allocation to live packet is therefore not administrative noise. It is the custody surface.

The stream label is part of the technical fact

RFC 10032 was published in September 2026 on the Internet Research Task Force stream. It is Informational, represents consensus of the Crypto Forum Research Group and says directly that it is not an IETF product or standard. The boilerplate warns that IRTF results might not be suitable for deployment.

That does not make the document weak or unofficial. It says what kind of review and authority the document carries. RFC 5743 describes research-group preparation, IRSG review and IESG conflict review. RFC 7841 explains that non-IETF-stream documents do not receive the ordinary IETF-wide standards review and approval path.

The distinction matters because the same acronym “RFC” can be mistaken for a single authority state. Here there are at least four separate facts: CFRG reached research-group consensus; the IRSG approved publication; the IESG checked for conflict with standardization activity; and IANA allocated unique identifiers. None says that a particular protocol adopted AEGIS, that a product enabled it by default or that two endpoints selected it.

The live IANA page adds a useful dated example. On 20 September, it displayed all six rows while its reference column still named draft 18 and the page showed a 7 July update date. The codepoints and the reference display are separate observable states. The lag does not invalidate the entries. It demonstrates why a review record should capture the registry snapshot it actually saw instead of compressing publication and registration into one green tick.

The codepoint omits a security decision

AEGIS-128L uses a 128-bit key and nonce; AEGIS-256 uses a 256-bit key and nonce. Both permit 128- or 256-bit authentication tags. Yet the six registry names encode the algorithm family and, for parallel forms, the degree. They do not encode tag length.

That missing bit of negotiation is material. RFC 10032 describes about 64 bits of committing security for a 128-bit tag and about 128 bits for a 256-bit tag when considering distinct keys or nonces that verify the same associated-data, ciphertext and tag tuple. A peer pair can agree on codepoint 32 while disagreeing about how many tag bits follow the ciphertext. The registry match is then true and the wire profile is still incompatible.

Framing must be bound too. RFC 10032 permits ciphertext and tag to remain separate or to be encoded together; in the combined form, the tag immediately follows the ciphertext. A receipt that stores only “AEGIS-128L” cannot tell a reviewer which tag length was parsed, where its boundary lay or whether both peers applied the same rule.

Associated data creates another boundary. RFC 5116 notes that clear protocol fields such as addresses, ports, sequence numbers and version numbers may be authenticated as AD. RFC 10032 discusses a restricted full-commitment property when an adversary cannot control AD and gives additional constructions for protocols requiring a stronger claim. The actual field set, order, lengths and domain separation are therefore protocol evidence. “The library accepted an AD buffer” is not enough.

Parallel speed is a compatibility choice

The X forms are designed for wide vector registers and vector AES instructions. X2 targets a degree of two and X4 a degree of four. On suitable processors they can process more material in parallel; implementations with different architectures may obtain different benefits.

RFC 10032 also sets a restraint. Protocols should select a parallel mode only when all involved parties agree on a specific variant. AEGIS-128L and AEGIS-256 should remain the default choices, and implementations may omit parallel support.

That language blocks a common inference. A benchmark showing AEGIS-128X4 at an attractive throughput does not create a portable suite. The remote peer may support only the base variant. The deployed binary may have been built without the X path. A virtual machine may expose a different instruction set after migration. A runtime dispatcher may fall back while the configuration still says “AEGIS”.

The receipt needs three layers of evidence: the suite the protocol offered and selected; the exact implementation capability present at each peer; and the path the runtime actually executed. They are related but not interchangeable.

Nonce custody survives the marketing number

For encryption, RFC 10032 requires a nonce to be used only once with a given key, even across different tag lengths. Reuse immediately reveals the bitwise difference between two messages. The nonce may be public or predictable and may be generated from a counter or another long-period construction. The document permits random nonces under stated bounds: up to 2^48 messages per key for the 128 family at the cited collision probability, and no practical random-nonce limit for the 256 family.

“No practical limit” is not “no custody”. The deployment still has to define the uniqueness domain, key epoch, restart behavior, counter persistence, random source, shard allocation and detection of rollback or clone reuse. If two processes restore the same snapshot, the size of the nonce field does not identify which process believed it owned the next value.

Key evidence is equally concrete: how the key was generated or derived, which context bound it to the protocol, when a new epoch began, what identifier separated users and when key material was erased. RFC 10032 allows an ephemeral key to be cleared after initialization because later operations depend on internal state. A security claim should record that boundary in the selected implementation, not infer it from the specification.

A self-test is necessary and still too small

RFC 10032 includes extensive fixed vectors for the AES round, the two base algorithms, X2 and X4 variants and MAC forms. They are excellent at exposing byte order, finalization, partial-block and tag-generation mistakes. Cross-implementation tests can prove that two independent implementations produce the same result for the same inputs.

Negative tests carry a different burden. A deployment should show that a changed tag fails, a changed AD field fails, a wrong nonce fails, a different parallel degree fails and unauthenticated plaintext is never released. RFC 10032 requires failed plaintext and computed tags to remain hidden, decrypted buffers to be cleared and tag comparison to be constant time. An acceleration path that passes positive vectors but releases bytes before authentication is not equivalent to the documented behavior.

Even a perfect test run stops at the laboratory boundary. It does not prove that a live handshake offered the tested suite, that both parties authenticated the selection, that the expected shared library was loaded, that the accelerated path was active or that usage counters stayed within the intended key epoch. Those are runtime facts.

A fourteen-part algorithm-custody receipt

The proposed receipt is Daniel Kade's editorial operating control, not a field in RFC 10032 and not an IETF or IANA compliance certificate.

First, record the document identity, IRTF stream, Informational category, publication and errata snapshot, and the IANA registry snapshot. Second, name the calling protocol, version, suite profile and configuration generation. Third, preserve an authenticated offer-and-selection transcript, or the protocol's equivalent proof of peer agreement.

Fourth, store the numeric identifier and exact base, X2 or X4 variant. Fifth, bind the tag length and ciphertext/tag framing. Sixth, keep peer capability evidence and the behavior used when a variant is unsupported.

Seventh, record key origin, derivation context, epoch, key identifier and zeroization boundary. Eighth, preserve nonce construction, persistence, uniqueness domain, restart handling and per-key usage counter. Ninth, describe the associated-data fields and canonical serialization, including lengths, ordering and version binding.

Tenth, identify the library build, enabled CPU/vector path and any fallback. Eleventh, retain positive vectors, cross-implementation results and negative cases. Twelfth, record authentication-failure semantics, plaintext suppression, constant-time comparison evidence and alerting.

Thirteenth, join the selected suite to bounded live-session or packet evidence and usage telemetry. Fourteenth, preserve fallback rules, downgrade rejection, rollback triggers, compatibility-set exit and the evidence-retention horizon.

No single component can replace the rest. A registry snapshot cannot prove a handshake. A handshake cannot prove nonce persistence after restart. A test vector cannot prove the loaded binary. A packet capture without key-epoch and AD rules cannot explain why its bytes should be accepted. The receipt is valuable because it refuses to turn those different statements into one word: supported.

Sources