Summary

  • RFC 10032 specifies AEGIS as authenticated encryption, as a stream generator and as a message authentication code. Those roles reuse internal machinery but do not make the same promise: encryption requires a unique (key, nonce) pair and verified-before-release plaintext; stream mode discards the tag; only the MAC permits pair reuse across different inputs.
  • An IANA identifier, primitive test vector or performance result cannot prove that an application selected the right role, separated key purposes, allocated the correct nonce domain or contained unverified output. The decisive record belongs at the API boundary where bytes acquire meaning.

Put one hexadecimal key and one nonce on a desk. Pass them through three AEGIS doors.

Behind the first door, the pair encrypts a message and binds associated data to an authentication tag. The pair must not return for another encryption, even if the next call asks for a different tag length. Behind the second, AEGIS encrypts zeros and throws the tag away, leaving a keystream. Behind the third, the input becomes a MAC and the same pair may be reused with different inputs. That third permission is explicitly exceptional.

The inputs look similar. The state update machinery is related. The family name remains AEGIS. Yet the authority of the outputs is different before the first byte reaches an application.

This is the operational problem hidden inside RFC 10032. Cryptographic integration is often reviewed at the level of primitive choice: the algorithm is approved, the codepoint is registered, vectors pass, hardware acceleration is available. The dangerous substitution happens one layer later, when a wrapper, protocol or developer decides what the primitive is doing. A correct implementation called under the wrong role contract can produce exactly the specified bytes and still leave the system without the evidence it thinks it has.

Publication coordinates a primitive, not an application decision

RFC 10032 was published in September 2026 as an Informational RFC on the IRTF stream. It records consensus in the Crypto Forum Research Group. It is not an IETF Standards Track specification, and its publication does not mandate use in a calling protocol.

The RFC specifies AEGIS-128L, AEGIS-256 and vector-oriented AEGIS-128X and AEGIS-256X modes. All use the AES encryption round function. The base variants differ in key, nonce, state and input-block sizes. The X modes exploit large vector registers and vector AES instructions; their security requirements follow the corresponding base mode. Parallel execution is an implementation and profile choice, not a new authority over application data.

IANA assigns six AEAD numbers: identifiers 32 through 37 cover the two base algorithms and their X2 and X4 forms. Those numbers solve a naming problem. They do not encode whether the caller wants authenticated encryption, a raw keystream or a MAC. They do not encode the 128- versus 256-bit tag choice. They do not say which fields became associated data, how a nonce was allocated, whether the loaded binary used the expected CPU path or what happened after verification failed.

That boundary is worth preserving because the existing RFC 10032 analysis on BTW already owns the codepoint-versus-negotiation question. The narrower question here begins after a suite has been selected: which of the three AEGIS roles did the application actually invoke, and did it honor the contract attached to that role?

Authenticated encryption has a release gate

In the AEAD role, encryption takes a message, associated data, key and nonce. It returns ciphertext and a tag. Decryption computes an expected tag, compares it in constant time and returns either verified plaintext or an error.

The pair of key and nonce is single-use for encryption. RFC 10032 repeats the rule across variants and makes clear that changing tag length does not create a new nonce domain. Reusing the pair reveals the bitwise difference between the messages and exposes internal state under the described failure. A public or predictable nonce can be safe; a repeated one cannot.

The RFC gives useful random-nonce bounds. AEGIS-128L and AEGIS-128X can use random nonces for up to 2^48 messages under one key at roughly 2^-33 collision probability. AEGIS-256 and AEGIS-256X have no practical random-nonce limit in the stated analysis. “No practical limit” is not “reuse is permitted”. It describes collision risk for properly generated random values, while the uniqueness invariant still controls encryption.

The second AEAD obligation is an output barrier. If verification fails, unverified plaintext and the wrong or computed tag must not be released. Decrypted buffers must be overwritten before return. This is not cosmetic memory hygiene. Partial plaintext delivered to a parser, decompressor, database or log before final verification can give an attacker a chosen-ciphertext oracle even if the public function eventually returns error.

An API receipt must therefore record more than success or failure. It should identify the role, variant, tag length, key identifier, nonce-allocation event, associated-data encoding, verification result and whether any tentative output crossed a process, callback or side-effect boundary. The cryptographic tag judges a tuple under a key. It does not inspect the application architecture that may already have acted on unauthenticated bytes.

Stream mode discards the evidence on purpose

RFC 10032 also defines AEGIS as a stream cipher. The construction is direct: encrypt an all-zero message without associated data and discard the tag. An implementation may omit finalization entirely.

That is a legitimate primitive service. It is also an explicit loss of the AEAD claim. The returned bytes are a keystream; they are not an authenticated message, not a verified record and not proof that any peer created or accepted data. Combining that stream with plaintext can provide confidentiality only if the surrounding construction supplies all other required controls.

The danger is semantic inheritance. A library may expose aegis_stream() beside aegis_encrypt(). Telemetry may label both “AEGIS protected”. A migration tool may preserve the algorithm field while changing the function. A downstream team may see the family name and assume a tag exists somewhere outside the trace.

There is no tag to find. It was discarded by definition.

The stream role therefore needs its own key purpose and nonce namespace. It should not borrow an encryption key merely because the core update function is common. It should carry an explicit “unauthenticated keystream” type at the interface, not a byte array whose meaning depends on tribal knowledge. And the system that consumes it must identify the separate integrity or authentication construction, if one exists, along with the order in which verification and plaintext release occur.

Without that receipt, a correct stream output can be promoted into a false security claim by a dashboard string.

The MAC owns the only reuse exception

The MAC role absorbs data and returns a 128- or 256-bit tag. RFC 10032 states that this is the only function that allows a (key, nonce) pair to be reused with different inputs.

That sentence is easy to lift out of context. Its subject is the MAC function, not the AEGIS family in general. A wrapper that stores one “AEGIS nonce policy” can import the MAC exception into encryption. The primitive will not object. The first sign may be repeated ciphertext structure or a later security review.

The MAC output also has negative boundaries. It must not be used as a hash function: if the key is known, state-colliding inputs can be crafted. It must not be used for key derivation: the tag is not guaranteed to be uniformly random. A valid MAC proves that the supplied data and nonce produced the expected tag under the selected secret key. It does not become a content digest, a randomness extractor, a password verifier or a new secret merely because it is 128 or 256 bits long.

Those prohibitions reveal why role names are part of the security design. “Tag” describes a shape, not a universal capability. The AEAD tag governs release of a ciphertext tuple. The MAC tag authenticates input under its function. Neither authorizes a KDF. A stream has no tag at all.

Key separation should make the distinction physical. Use role-bound key identifiers and derivation labels; refuse a key minted for AEAD at the STREAM or MAC interface; maintain separate nonce allocators; and record the permitted tag uses. Relying on a developer to remember which reuse sentence applied is not a control plane.

Tag length and associated data remain protocol facts

RFC 10032 allows 128- and 256-bit authentication tags. It describes approximately 64 bits of key-commitment security for the 128-bit tag and approximately 128 bits for the 256-bit tag in the specified receiver-binding game. That claim does not mean a codepoint chooses the tag or that every protocol requires the same commitment property.

The document also draws a subtle associated-data boundary. AEGIS is fully committing in a restricted setting where the adversary cannot control associated data. With attacker-controlled associated data, the cited analysis permits efficient discovery of multiple keys that verify the same authenticated ciphertext. A protocol that requires full commitment can hash the associated data with an appropriate collision- and preimage-resistant hash before supplying it, or bind an unambiguous encoding through a KDF info field under the stated constraints.

These are construction decisions above the primitive. They require a protocol profile, field inventory, canonical serialization and threat model. The string AEGIS-256 does not show whether an attacker influences an AD field, whether two implementations serialize it identically, or whether the chosen tag length meets the application's commitment target.

This is where the role boundary meets reality. The primitive authenticates exactly the bits it receives. The application owns the decision about which facts those bits represent.

Test vectors stop before custody

RFC 10032 includes extensive test vectors. They can establish that a candidate implementation transforms specified inputs into specified outputs. Cross-implementation tests can establish that two implementations agree on those cases. Neither proves that production called the right function.

A defensible deployment test should include role-confusion negatives:

  1. a key issued for one role is rejected by the other two;
  2. encryption refuses a repeated pair even when tag length changes;
  3. MAC reuse tests do not alter the encryption allocator;
  4. stream output is typed and logged as unauthenticated;
  5. a failed AEAD tag releases no partial plaintext, callback, parse event or side effect;
  6. MAC tags are rejected by hash and KDF interfaces;
  7. the loaded binary and CPU path match the reviewed implementation;
  8. live counters distinguish encryptions, streams, MACs, failures and nonce-allocation anomalies.

The AES round implementation adds another custody layer. Timing, power and fault resistance depend on the actual software or hardware path and its threat model. RFC 10032 permits ephemeral keys to be erased after initialization because later operations use the derived state. Whether a compiler, runtime or library performs that erasure is a running-code fact, not a property inherited from the pseudocode.

A role receipt for one call

The minimum useful record for an AEGIS operation is compact but explicit. It joins application purpose and threat model; selected role; variant and parallel degree; tag length; key identity and permitted role; nonce namespace and allocation event; associated-data schema and encoding; implementation version and runtime path; verification and zeroization result; output-release boundary; live counters; and application acceptance or rollback.

This is not a demand for one central cryptographic authority. Lu Heng's minimum-specification doctrine supports the opposite arrangement: a small common primitive can coordinate implementations while applications retain the decisions they are competent and accountable to make. The registry names the algorithm. The library executes a role. The protocol defines fields and negotiation. The application decides whether verified content is authorized for an action.

Reality-layer discipline prevents these records from lending authority upward. A published RFC is not a deployed library. A vector pass is not a role-selection proof. A valid tag is not an identity or business authorization. A verified plaintext is not a completed transaction. Running-code primacy asks for evidence at each boundary, especially the failure path where a clean algorithm label is least informative.

RFC 10032's most important operational lesson is therefore not that AEGIS can do three jobs. It is that shared machinery does not erase job boundaries. The primitive kept its name. The application must keep the receipts separate.

Sources