]> Cryptography Consulting LLC

nicholas.sullivan+ietf@gmail.com

IRTF Crypto Forum This document defines Random-Access Authenticated Encryption (raAE), a mechanism for encrypting segmented content that supports decryption of individual segments without processing others, selective re-encryption of individual segments in place, and content-level integrity via an accumulator binding all segment authentication tags. raAE is parameterized over an Authenticated Encryption with Associated Data (AEAD) algorithm, a key derivation function (KDF), segment size, epoch length, and nonce generation mode. raAE does not define wire formats, IANA registries, or key management; applications instantiate it with a chosen parameter set and protocol identifier. This document also defines "raAE-v1", a concrete profile with test vectors, supporting five AEAD algorithms: AES-256-GCM, ChaCha20-Poly1305, AES-256-GCM-SIV, AEGIS-256, and AEGIS-256X2, each with HKDF-SHA-256 and 65536-octet segments. Discussion Venues Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Consider a 1 tebibyte (TiB) encrypted backup stored as 2^24 segments of 64 KiB each. A user changes one segment. Today that service must either re-encrypt the entire file or treat each segment as an independent Authenticated Encryption with Associated Data (AEAD) message and give up cross-segment integrity. STREAM () does not help here; it chains nonces across segments, so reading segment 1000 requires verifying segments 0 through 999 first. Random-Access Authenticated Encryption (raAE) solves this. It encrypts each segment independently, supports in-place re-encryption, and binds all segment tags into a single accumulator for content-level integrity. The mechanism works in layers. Start with a 32-octet random Content Encryption Key (CEK) and a per-content salt. From these, derive a commitment (lets the reader reject a wrong key before decrypting anything), a payload key, an accumulator key, and optionally a nonce base. For each segment, derive a per-segment key from the payload key (either directly or through an epoch-key layer that bounds nonce reuse), generate a nonce, and encrypt with an AEAD. Take the AEAD tag from each segment, feed it through a keyed pseudorandom function (PRF), and XOR all the outputs together into the accumulator. The hierarchy is deterministic: CEK plus salt plus segment index is enough to derive any key. This document defines "raAE-v1", a concrete profile supporting AES-256-GCM, ChaCha20-Poly1305, AES-256-GCM-SIV, AEGIS-256, and AEGIS-256X2, all with HKDF-SHA-256, and includes test vectors for each nonce generation mode. raAE does not define wire formats, IANA code points, or key management; consuming protocols handle those. fixes notation. defines the mechanism. states the domain separation requirements any concrete KDF framing must meet. gives the security analysis. defines raAE-v1.

Related Work STREAM () encrypts sequential data by chaining a nonce from one segment to the next: segment N's nonce depends on segment N-1's ciphertext, so decryption is inherently sequential. raAE replaces this chain with independent per-segment nonces (random, derived, or plaintext-bound), which is what makes random-access reads possible. Both constructions authenticate each segment individually; raAE adds a content-level accumulator that STREAM does not need because STREAM's chain already binds segment order. FLOE () formalized the raAE security notion as ra-ROR (random-access real-or-random), a simulation-based definition that captures confidentiality and authenticity when segments can be encrypted and decrypted in any order. ra-ROR is strictly stronger than nonce-based online authenticated encryption (nOAE2): a scheme can be nOAE2-secure (secure for sequential encryption with random-access decryption) but insecure when encryption order is also arbitrary. FLOE proved that its construction (epoch key rotation, per-segment AEAD, and a hash-based integrity tag) satisfies ra-ROR, and defined ra-CMT (random-access context commitment) as a commitment notion independent of the underlying AEAD's commitment properties. raAE-v1 draws on FLOE's epoch key structure but uses a different integrity mechanism: a XOR-of-PRF accumulator that supports O(1) incremental update on segment rewrites. The informal security argument in follows FLOE's reduction structure, adapted for the XOR-of-PRF accumulator.

Applicability Use raAE when the content is too large for a single AEAD call and the application needs to read or write individual segments. The format must store per-segment nonces and tags. For small messages, a single AEAD call is simpler and sufficient. For sequential streaming, STREAM () gives stronger ordering guarantees with less machinery. For formats where per-segment metadata is prohibitively expensive, derived nonce mode removes the nonce overhead but restricts the AEAD to Misuse-Resistant Authenticated Encryption (MRAE, ) algorithms.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. A Segment is a fixed-size unit of plaintext. Each segment is individually encrypted and authenticated. The final segment of a message may be shorter than the nominal segment size. The Content Encryption Key (CEK) is a 32-octet uniform random master key from which all other keys for a given message are derived. The protocol_id is an application-chosen octet string that binds all KDF outputs to a specific protocol version and application context. Different applications MUST use different protocol_id values even when using the same underlying AEAD and KDF algorithms. Other terms (epoch, epoch_key, payload_key, accumulator, commitment, and related values) are defined in where they first appear.

Notation

I2OSP(n, w):

The w-octet big-endian encoding of the non-negative integer n, as defined in .

uint64(n):

Shorthand for I2OSP(n, 8).

uint8(n):

Shorthand for I2OSP(n, 1).

||:

Octet string concatenation.

lp16(x):

The 2-octet big-endian length of x followed by x: I2OSP(len(x), 2) || x.

Encode(x1, ..., xn):

Injective length-prefixed encoding: lp16(x1) || ... || lp16(xn). Each argument MUST be at most 65535 octets. The concrete framing in specifies how Encode is used in KDF calls.

XOR:

Bitwise exclusive-or of two octet strings of equal length.

x[a:b]:

Octets a through b-1 inclusive of x (zero-based, half-open interval).

Nk:

Key size in octets for the chosen AEAD algorithm.

Nn:

Nonce size in octets for the chosen AEAD algorithm.

Nh:

Hash or PRF output size in octets for the chosen KDF.

Nt:

Authentication tag size in octets for the chosen AEAD algorithm.

The raAE Framework The key hierarchy is shown below. A CEK and per-content salt feed the payload schedule, which derives four values. The payload key feeds per-segment keys (optionally through epoch keys), each segment produces an AEAD tag, and all tags feed the accumulator.

raAE Key Hierarchy XOR i i all contribs | v accumulator ]]>

Parameters A raAE parameter set is a tuple (AEAD, KDF, protocol_id, segment_size, epoch_length, nonce_mode, aad_label).

AEAD:

An authenticated encryption with associated data algorithm satisfying the interface of , with Nk-octet keys, Nn-octet nonces, and Nt-octet authentication tags.

KDF:

A key derivation function supporting the abstract interface defined in . Two-stage KDFs (HKDF) use Extract and Expand; single-stage KDFs (extendable-output function, XOF) use a direct derivation call.

protocol_id:

An application-chosen octet string that binds all derived values to a specific protocol version. Applications MUST NOT use the profile identifier "raAE-v1" as their protocol_id; the test vectors in this document use it for illustration only. A real application would use a value identifying itself (for example, "myapp-backup-v1").

segment_size:

A positive integer that is a power of two and at least 4096 octets. Power-of-two sizes align to memory page boundaries and simplify offset arithmetic. All segments except possibly the last have exactly this many octets of plaintext. The segment size MUST remain within the per-invocation plaintext limit of the chosen AEAD (for example, 2^36 - 32 octets for AES-GCM per ). A zero-length plaintext produces a single segment of length 0 with is_final = 1.

epoch_length:

A non-negative integer r, or absent (meaning the parameter is omitted from the tuple entirely, not set to a sentinel value). When present, each epoch covers exactly 2^r consecutive segments starting at a multiple of 2^r. When absent, all segments use the payload key directly and epoch derivation is skipped: segment_key(i) = payload_key for all i. When epoch_length = 0, each segment gets a unique derived key. The value r MUST be in the range 0 to 63 inclusive. Implementations MUST reject r >= 64.

nonce_mode:

One of the strings "random", "derived", or "plaintext-bound". See . When nonce_mode is "derived", epoch_length MUST be absent. When nonce_mode is "random" or "plaintext-bound" and the AEAD uses 96-bit nonces, epoch_length MUST be present to bound per-key nonce usage.

aad_label:

A protocol-chosen ASCII string used as the first argument to Encode in segment_aad construction. See .

Two sizes are determined by the chosen algorithms rather than by the parameter set directly.

Nh:

The hash or PRF output size for the KDF, in octets. This is also the size of each accumulator contribution and of the acc_key.

commitment_length:

A positive integer, defaulting to Nh, specifying the length of the key commitment prefix in octets.

Components An encrypted message is built from three input values, four payload schedule outputs, per-segment values derived from those outputs, and a content-level integrity value.

Inputs Three values are provided by the caller or constructed from parameters.

CEK:

A 32-octet uniform random Content Encryption Key generated fresh for each message.

salt:

A per-content random value of Nh octets, generated fresh for each message. The salt separates payload schedule outputs across messages even when the CEK is reused. An application that writes a new message MUST generate a fresh salt. Reusing a salt with the same CEK produces identical payload schedule outputs, causing nonce reuse in derived mode and correlated nonces in random mode. An application extending an existing message MUST reuse the existing salt.

payload_info:

A framed encoding of the parameter set context. When epoch_length is absent:

When epoch_length is present: The exact encoding is defined in .

Payload Schedule Outputs Four values are derived from the CEK and payload_info. They are computed once per message and fixed for its lifetime.

commitment:

A commitment_length-octet value derived from the CEK and payload_info. Stored at the start of the content to catch key or parameter mismatches before decryption begins.

payload_key:

An Nk-octet key derived from the CEK and payload_info. Used directly as the segment key when epoch_length is absent, or as the root for epoch key derivation.

acc_key:

An Nh-octet key derived from the CEK and payload_info. Used to compute per-segment accumulator contributions.

nonce_base:

An Nn-octet value derived from the CEK and payload_info, used in derived nonce mode only.

Per-Segment Values Each segment i has a set of derived values produced from the payload schedule outputs and the segment index.

epoch_key(i):

An Nk-octet key for the epoch containing segment i, derived from the payload_key and the epoch index. Present only when epoch_length is specified.

segment_key(i):

The AEAD key for segment i. Equal to epoch_key(i) when epoch_length is present; equal to payload_key otherwise.

nonce(i):

The Nn-octet nonce for AEAD operations on segment i. Derived per the chosen nonce_mode.

segment_aad(i, is_final):

Per-segment additional authenticated data that binds the segment to its index and whether it is the final segment.

tag(i):

The Nt-octet AEAD authentication tag for segment i, produced by the AEAD Seal operation.

Content-Level Integrity Two values provide integrity across the full set of segments.

contrib(i):

An Nh-octet accumulator contribution for segment i, derived from acc_key, the segment index, and tag(i).

accumulator:

An Nh-octet content-level integrity value equal to the aggregation of all contrib(i) values across all segments.

Key Derivation Structure A message's entire key hierarchy grows from two random values: the 32-octet CEK and the per-content salt. All other keys are derived deterministically from these two values, so there is no per-segment key state to manage or synchronize. The abstract interface below exists so that raAE can support both two-stage (HKDF) and single-stage (XOF) KDF families; defines the only current concrete framing. All key material flows through this interface:

• protocol_id: binds the output to a specific protocol version and application context.
• label: a unique ASCII string identifying the derivation role.
• ikm: input keying material, provided as a single octet string or an ordered list of octet strings.
• info: context information, provided as a single octet string or an ordered list of octet strings.
• L: the requested output length in octets.

The KDF MUST satisfy these requirements. Outputs MUST be computationally indistinguishable from random given an unknown ikm, under the assumption that the underlying hash or PRF is a secure pseudorandom function. The framing of (protocol_id, label, ikm, info, L) into the octet string input of the underlying primitive MUST be injective: each lp16 field is self-delimiting, so the concatenation can be uniquely parsed regardless of the number of arguments. Distinct input tuples MUST NOT produce the same primitive input. The concrete framing requirements are specified in . The requested output length L MUST be committed in the primitive input. This prevents attacks where an adversary truncates a longer output to obtain a valid shorter one. The protocol_id MUST appear in the primitive input. This prevents cross-protocol reuse of derived values. Each label used within a protocol version MUST be distinct across all derivation roles. The label appears in both the Extract and Expand phases of the two-stage KDF as a defensive redundancy measure: if either phase is weak in isolation, the label binding in the other phase preserves domain separation. Implementations MAY amortize the Extract computation internally when deriving multiple outputs from the same protocol_id, label, and ikm.

Payload Schedule Derivation Four values are derived from the CEK and per-content salt. The commitment allows early rejection of a wrong key. The payload key encrypts segments (directly, or via epoch keys). The accumulator key authenticates the set of segment tags. The nonce base (derived-mode only) seeds deterministic per-segment nonces. For derived nonce mode, a nonce base is also derived:

Epoch Key Derivation AES-256-GCM uses 96-bit nonces. The birthday bound for nonce collisions under a single key becomes a practical concern at around 2^32 encryptions. For rewritable content, this limit can be reached through repeated modifications to the same segments. Epoch keys partition the nonce space: each epoch key covers at most 2^r segment positions (initial writes plus rewrites), so the per-key invocation count is bounded regardless of the content's total size. When epoch_length = r is specified, the segment key for segment i is an epoch key derived from the payload key: > r return KDF(protocol_id, "epoch_key", [payload_key], [uint64(epoch_index)], Nk) ]]> When epoch_length is absent, segment_key(i) = payload_key for all segment indices i. Epoch keys implement the parallel external rekeying pattern of , adapted for random-access patterns.

Key Schedule Design Rationale The single-CEK design separates key agreement from content encryption. Different recipients can hold different wrappings of the same CEK; adding a recipient requires only a new key-wrapping operation, not re-encryption of the payload. The per-content salt makes the payload schedule unique even when a CEK is reused across messages, which matters for applications that derive CEKs from passwords or group keys. A separate salt lets the encryptor choose it at write time without coordinating with recipients; a counter in the CEK would require that coordination. Epoch keys exist because 96-bit-nonce AEADs hit their birthday bound quickly: without epoch partitioning, large content with many rewrites exhausts the nonce space under a single key. Rekeying the entire content would defeat the random-access property, so epoch keys bound the per-key invocation count without requiring a full re-encryption. Labels separate derivation roles: commitment and payload_key share the same inputs but different labels, making them independent under the PRF assumption. Once CEK and salt are chosen the hierarchy is fixed, with no mutable state to synchronize across writers.

Nonce Generation Three nonce modes trade off AEAD flexibility, storage cost, and random number generator (RNG) trust. The chosen mode is part of the parameter set and MUST be consistent across all segments of a message.

Nonce Generation Modes pt_hash | Random ---+ | nonce_i ]]>

Random Stored Nonces (nonce_mode = "random") Each segment gets an independent random nonce: The nonce is generated fresh on initial write and on each rewrite of that segment. Each segment's nonce is stored in per-segment metadata and MUST be accessible to any reader that decrypts individual segments. This mode requires a functioning cryptographically secure pseudorandom number generator (CSPRNG). The nonce collision probability across independently generated per-segment nonces follows the standard birthday bound; see .

Derived Nonces (nonce_mode = "derived") For MRAE AEADs, nonces are derived deterministically from the payload schedule. The AEAD nonce size Nn MUST be at least 8 octets. The XOR operation is applied to the last 8 octets of nonce_base, with the remaining octets unchanged: No per-segment nonce storage is required. Nonce reuse on rewrite is tolerated by the MRAE AEAD. The degraded security is deterministic encryption (equality leakage), not plaintext recovery. Applications MUST use an MRAE AEAD such as AES-256-GCM-SIV () when using derived nonce mode.

Plaintext-Bound Nonces (nonce_mode = "plaintext-bound") The plaintext-bound construction mixes plaintext content into nonce generation to defend against random number generator state duplication. It uses two passes. Pass 1 compresses the plaintext to a fixed-size digest and then derives a collision-resistant hash bound to the encryption parameters. The compression step avoids passing the full segment (up to 65536 octets) through lp16, which is limited to 65535 octets. The salt is excluded because an application may need to compute pt_hash before choosing an output destination (for example, during content-addressed deduplication): Hash is the hash function underlying the KDF (SHA-256 for HKDF-SHA-256). The pt_digest is always Nh octets, well within the lp16 limit. Pass 2 mixes fresh random material with the payload key and the plaintext commitment: Pass 1 is a deterministic function of the plaintext and algorithm parameters; it targets collision resistance, not PRF security. Pass 2 mixes fresh random material with the payload key and the plaintext commitment. When an RNG produces duplicated state (for example, from a virtual machine snapshot), two calls with different plaintexts at the same segment index produce different nonces because pt_hash(i) differs. Two calls with the same plaintext at the same index produce the same (key, nonce, aad) triple under RNG duplication, resulting in deterministic encryption: the ciphertexts are identical, revealing that the plaintexts are equal. No additional information beyond this equality is leaked. For plaintext-bound rewrites, the procedure is:

1. Recompute pt_hash(i) with the new plaintext.
2. Derive a fresh nonce(i) using the new pt_hash(i) and a new Random(Nn).
3. Seal the new plaintext under the new nonce.
4. Update the accumulator as in .

Nonce Mode Design Rationale Random mode is simplest but trusts the CSPRNG completely. Derived mode removes that trust entirely at the cost of requiring an MRAE AEAD. Plaintext-bound mode splits the difference: it mixes plaintext into the nonce, so different content at the same index gets different nonces even under RNG duplication. The cost is one hash of the full segment (for pt_digest) plus two short KDF calls, comparable in time to the AEAD encryption itself.

Hedged Randomness (Optional) When a long-term symmetric key sk of at least Nh octets is available to the encryptor, implementations SHOULD mix it into random generation using the hedging pattern of . If only an asymmetric private key is available, it MUST first be processed through a KDF to produce a uniform symmetric key. HedgedRandom output depends on both the CSPRNG and sk, so a weak CSPRNG alone cannot predict it. Hedging does not help when the CSPRNG state itself is duplicated (VM snapshots, fork without reseed); identical CSPRNG output still produces identical HedgedRandom output. The plaintext-bound nonce mode () addresses that distinct threat and is orthogonal to hedging; applications with a long-term key SHOULD apply both.

Segment AAD Each segment is encrypted with additional authenticated data (AAD) that binds it to its position in the content and to whether it is the final segment: The aad_label is the protocol-chosen label from the parameter set. The segment index i is encoded as a big-endian 8-octet integer, and is_final is 1 for the last segment and 0 for all others. The salt is not included in the AAD because it is already bound into segment_key via the payload schedule; different messages produce different segment keys even at the same index. Transposing two segments within a message fails because the AAD at each position encodes the expected index. Truncation is detectable: a reader that sees is_final = 0 knows more data must follow. Extension is also caught: appending after a segment marked is_final = 1 either invalidates the original final segment on re-read or produces a ciphertext that cannot verify. Encoding both the index and the finality bit in the AAD, rather than relying on the accumulator alone, catches these attacks per-segment without requiring the reader to hold all tags before decrypting any one of them.

Commitment and Aggregation Per-segment AEAD alone has two blind spots. Without a commitment, a reader with the wrong key attempts decryption of every segment before discovering the mismatch, leaking timing information in the process. Without an accumulator, an adversary who controls storage can replace segment 3's ciphertext with a different valid ciphertext for index 3 (from another message encrypted under the same key), and the per-segment AEAD check will pass. The commitment catches the first; the accumulator catches the second.

Key Commitment The commitment is a commitment_length-octet value derived from the CEK and payload_info: Before decrypting any segment, a reader derives the expected commitment from the CEK and payload_info and compares it octet-for-octet with the stored value. A mismatch indicates a wrong key, wrong parameter set, or corrupted header. The commitment achieves CMT-1 security (as defined in ). Under the PRF assumption on the KDF, the probability that any other (CEK, payload_info) pair produces the same commitment is at most 2^(-8 * commitment_length), which is 2^(-256) for commitment_length = 32. Across q key queries the birthday bound gives a collision probability of at most q^2 / 2^(8 * commitment_length + 1). Several AEADs including AES-GCM () and ChaCha20-Poly1305 () lack strong native key commitment. An external PRF-based commitment delivers uniform collision resistance regardless of the AEAD choice. FLOE () defines ra-CMT, a commitment notion for raAE schemes that is independent of the underlying AEAD's commitment properties. raAE achieves ra-CMT because the PRF-based commitment is checked before any AEAD operation: a wrong key is rejected at the commitment step, so the AEAD's lack of native key commitment cannot be exploited. For reference, CMT-4 () depends on AEAD-specific properties beyond indistinguishability under chosen-ciphertext attack (IND-CCA2). AES-256-GCM and ChaCha20-Poly1305 do not achieve CMT-4; AES-256-GCM-SIV does. raAE's ra-CMT guarantee holds regardless, as long as the commitment check is not bypassed.

Aggregation The accumulator binds all segment authentication tags into a single Nh-octet content-level integrity value. The per-segment accumulator contribution is: The aggregation function used to combine contributions MUST be commutative, associative, and support O(1) incremental update when a single segment is rewritten. Formally, the aggregation function Agg over Nh-octet values MUST satisfy:

• Agg(a, b) = Agg(b, a) for all a, b.
• Agg(Agg(a, b), c) = Agg(a, Agg(b, c)) for all a, b, c.
• There exists an identity element e such that Agg(a, e) = a for all a.
• Given the current accumulator, the old contribution, and the new contribution, the updated accumulator is computable in O(1) time.

The accumulator for a message with N segments is: When segment i is rewritten, the accumulator is updated as: For XOR-based aggregation (the concrete instantiation defined in ), this simplifies to: A Merkle tree of tags would give O(log N) per-segment verification, but updates cost O(log N) hashes and require storing the tree. XOR-of-PRF trades per-segment verification (which requires all tags) for O(1) update and no auxiliary storage. For a rewrite-heavy workload, O(1) update matters more. To rewrite segment i, compute contrib(i) from the old tag (which is already stored alongside the ciphertext), XOR it out of the current accumulator, encrypt the new plaintext to get a new tag, compute the new contrib(i), and XOR it in. No other segment is read or decrypted; the accumulator update touches only the rewritten segment's metadata. A hash chain would force re-reading all prior tags on every rewrite, defeating the random-access property. The PRF-keyed contribution prevents an adversary without acc_key from predicting any contrib(i) value, so forging a valid accumulator for a modified set of segment tags requires breaking the KDF's PRF security. The accumulator does not bind the total segment count; see for the implications and required mitigations.

Encryption and Decryption Three operations use the framework above.

Encryption Given a CEK, a fresh salt, a parameter set, and a plaintext P split into segments P_0 through P_{N-1}, encryption works in two phases. First, derive commitment, payload_key, acc_key (and nonce_base for derived mode) from the payload schedule. Store the commitment as the first commitment_length octets of output. Then, for each segment i from 0 to N-1:

1. Compute segment_key(i) per .
2. Compute nonce(i) per the chosen nonce_mode ().
3. Set is_final = 1 if i = N-1, else set is_final = 0.
4. Compute aad = segment_aad(i, is_final).
5. Compute C_i = AEAD.Seal(segment_key(i), nonce(i), aad, P_i). The ciphertext ct_i is the first len(P_i) octets of C_i and tag_i is the final Nt octets. This assumes C_i = ct_i || tag_i per Section 2.1, which holds for all AEADs profiled in .
6. Store nonce(i) (random mode only), ct_i, and tag_i.
7. Compute contrib(i) = KDF(protocol_id, "acc_contrib", [acc_key], [uint64(i), tag_i], Nh).

After all segments are encrypted, compute the accumulator as the XOR of all contrib values: Store the accumulator alongside the commitment and segment data.

Decryption of Segment i Given the CEK, salt, parameter set, segment index i, finality status, and the stored ciphertext for segment i:

1. Derive commitment, payload_key, acc_key from the CEK and salt via the payload schedule.
2. Verify that the stored commitment equals the derived commitment. If they differ, the implementation MUST NOT proceed with decryption, SHOULD zeroize derived key material, and MUST return an error to the caller.
3. Optionally, verify the stored accumulator against the derived contributions from all available segment tags before proceeding to segment decryption. Applications that have all segment tags available SHOULD perform this check. A reader decrypting a single segment without verifying the accumulator gets per-segment AEAD integrity only; cross-segment integrity (detecting substitution or removal) requires accumulator verification.
4. Compute segment_key(i) and nonce(i).
5. Compute aad = segment_aad(i, is_final).
6. Compute P_i = AEAD.Open(segment_key(i), nonce(i), aad, ct_i || tag_i) per Section 2.2. Return a decryption error if verification fails.

Decryption can fail in three distinguishable ways: commitment mismatch (wrong key or parameters), AEAD verification failure (corrupted or tampered segment), and accumulator mismatch (segment set modified). Implementations SHOULD report these as distinct error conditions for local diagnosis, but SHOULD return a single opaque error to untrusted callers to avoid leaking an oracle (for example, distinguishing "wrong key" from "tampered segment" over a network).

Rewriting Segment i The rewrite procedure assumes the caller has already verified the commitment or otherwise confirmed it holds the correct CEK. A rewrite under the wrong key produces unreadable ciphertext and corrupts the accumulator; the error is detectable only on a subsequent read. Rewriting a segment does not require reading or decrypting any other segment. The old tag is already stored alongside the old ciphertext. For random nonce mode:

1. Read the old tag_i from storage.
2. Compute old_contrib = KDF(protocol_id, "acc_contrib", [acc_key], [uint64(i), old_tag_i], Nh).
3. Generate a fresh nonce(i) = Random(Nn).
4. Compute C_i = AEAD.Seal(segment_key(i), nonce(i), segment_aad(i, is_final), new_P_i). Extract new_ct_i and new_tag_i.
5. Compute new_contrib = KDF(protocol_id, "acc_contrib", [acc_key], [uint64(i), new_tag_i], Nh).
6. Update the accumulator: acc = acc XOR old_contrib XOR new_contrib.
7. Store the new nonce(i), new_ct_i, new_tag_i, and the updated accumulator.

For derived nonce mode, nonce(i) is computed per and is the same on rewrite as on initial encryption. The MRAE AEAD tolerates this reuse. The accumulator update proceeds identically. Note that the accumulator cannot be validated during an in-place rewrite. Validation requires computing contrib(j) for every segment j and checking that their XOR matches the stored accumulator, which means reading all tags. During a rewrite the application trusts the stored accumulator and applies the delta. Full validation is a separate operation that an application performs when it has access to all tags (for example, on a full read or an integrity audit).

Accumulator Update on Segment Rewrite KDF("acc_contrib") --> old_contrib | accumulator ---XOR old_contrib ---------->XOR | new_tag_i --> KDF("acc_contrib") --> new_contrib | XOR new_contrib | v new accumulator ]]>

Framing and Domain Separation Requirements The security analysis in assumes that distinct KDF input tuples produce distinct primitive inputs. This section states the requirements that any concrete framing must satisfy for that assumption to hold.

Injectivity:

The mapping from the tuple (protocol_id, label, ikm, info, L) to the octet string input of the underlying hash or KDF primitive MUST be injective. Distinct input tuples MUST NOT produce the same primitive input.

Label uniqueness:

Each derivation role, including commitment, payload key, accumulator key, nonce base, epoch key, accumulator contribution, segment nonce, and hedged nonce, MUST use a distinct label string within each protocol version.

Protocol binding:

The protocol_id MUST appear as a distinct component of the KDF primitive input. Different application protocols using the same AEAD and KDF MUST use different protocol_id values to ensure that derived values from one protocol cannot be confused with those from another.

Output length commitment:

The requested output length L MUST be part of the KDF primitive input. This prevents attacks in which an adversary attempts to use a truncated version of a longer derived output as a valid shorter one.

Cross-role isolation:

A KDF output for one derivation role, such as payload_key, MUST be computationally independent of the output for any other role, such as acc_key, even when derived from the same CEK and payload_info. This property follows from label uniqueness and PRF security of the underlying primitive.

Security Properties and Assumptions The adversary can observe all ciphertexts and content metadata, tamper with individual segments or their ordering, replace the accumulator, and attempt decryption with chosen keys. The adversary does not know the CEK, any derived key, or the per-content salt. When multiple messages share a CEK, the per-content salt separates payload schedule outputs across messages under the PRF assumption; the multi-message advantage grows linearly in the number of messages. raAE claims the properties below against this adversary. The security argument assumes that the KDF is a PRF. For HKDF-SHA-256, HKDF-Extract with a public salt (protocol_id) acts as a randomness extractor on the IKM, which follows from the PRF property of the HMAC compression function per the HKDF analysis . All raAE-v1 KDF outputs are at most Nh octets, so HKDF-Expand makes a single HMAC call per derivation and the PRF assumption applies directly.

Segment Confidentiality and Integrity raAE targets ra-ROR security (): the adversary can adaptively interleave encryption and decryption of segments for different messages, in any order, across different keys. The security argument reduces ra-ROR to the multi-user real-or-random (mu-ROR) security of the underlying AEAD in three steps. First, PRF security of the KDF replaces payload_key with a uniformly random key (one hybrid step per message, since the salt makes each message's derivation independent). Second, each epoch_key is similarly replaced. Third, mu-ROR security of the AEAD bounds per-segment confidentiality and integrity loss. The bound below uses the following variables. Let F be the number of messages encrypted under adversary-chosen keys, E the total number of epoch keys derived across all messages, and S the total number of segment encryption queries. For each per-epoch key k, let q_k be the number of segment encryptions under that key. Conditioned on no nonce collisions among segments sharing a key (the birthday bound for each per-epoch key; see ), the advantage is informally bounded by: where Adv_PRF is the PRF advantage of the KDF, Adv_muROR is the per-query multi-user real-or-random advantage of the AEAD, and Adv_acc is the accumulator forgery advantage. The total advantage is the sum of the nonce collision probability and the conditioned bound above. In derived nonce mode, nonces are distinct by construction and the collision term vanishes. In random nonce mode with epoch_length = 0 (one key per segment), q_k equals the rewrite count for a single segment position. In practice the dominant term is Adv_muROR, which scales with the total number of segment encryption queries. The PRF terms (payload schedule and epoch keys) are typically negligible because F and E are small relative to S. The accumulator forgery advantage Adv_acc is bounded by Adv_PRF + q_forge * 2^(-8 * Nh), where q_forge is the number of forgery attempts. Under the PRF assumption each contrib value is uniformly random, so each attempt succeeds with probability at most 2^(-256) for Nh = 32. A formal proof extending the ra-ROR analysis of FLOE to the XOR-of-PRF accumulator is in preparation; the bound above captures the reduction structure. Segment ciphertexts are indistinguishable from random under the ra-ROR definition. Each segment is authenticated, including its binding to its index and finality status via the segment AAD. An adversary cannot modify, reorder, truncate, or extend the set of segments without causing an AEAD verification failure on at least one affected segment.

Key Commitment raAE-v1 uses commitment_length = 32 (Nh octets) and Nt = 16. The birthday bound and CMT-1 analysis in apply directly; the per-pair collision probability is at most 2^(-257), and the per-pair forgery probability is at most 2^(-128).

Accumulator Security The accumulator is unforgeable without knowledge of the acc_key. An adversary who does not know acc_key cannot predict any individual contrib(i) value (by the PRF security of the KDF), and therefore cannot construct a valid accumulator for any set of segment tags that differs from the authenticated set. The XOR-based aggregation is susceptible to cancellation: if an adversary can control two contributions simultaneously such that their XOR equals the XOR of two target contributions, a forgery is possible. However, each contrib(i) is a KDF output keyed by acc_key and bound to the segment index and AEAD tag. Without knowledge of acc_key, the adversary cannot select segment tags to achieve a target contribution value. An adversary who compromises acc_key can forge accumulator values without recovering any segment plaintext. Applications MUST treat acc_key exposure as equivalent to accumulator integrity loss and MUST rotate the CEK if acc_key compromise is suspected.

AEAD Usage Limits Two bounds constrain the number of segment operations under a single key: a confidentiality bound driven by nonce collisions and a per-query integrity bound driven by forgery probability. Both are analyzed in . For raAE with segment_size = 65536 octets (L = 4096 AES blocks, or L' ~ 4099 Poly1305 blocks), the per-key limits are:

Confidentiality (Nonce Collision) For random nonce mode with Nn-octet nonces and q segment encryptions under one key, the collision probability follows the birthday bound: When epoch_length = r is specified, q counts encryptions per epoch key (initial writes plus rewrites within that epoch), not across the whole content. Each epoch key has an independent budget. For derived nonce mode, nonces are deterministic and distinct across segment indices. Rewriting the same segment reuses the nonce, which is tolerated by the MRAE AEAD with degradation to equality leakage.

Integrity (Forgery) Each AEAD decryption query gives the adversary a chance to forge a valid ciphertext. The forgery advantage per query depends on the AEAD and the segment size. For AES-256-GCM ( Section 5.1): where v is the number of forgery attempts and L = 4096 blocks per segment. For ChaCha20-Poly1305 ( Section 5.2): The 2^103 denominator (not 2^128) reflects Poly1305's per-query forgery bound. At 65536-octet segments, the integrity limit for ChaCha20-Poly1305 is tighter than for AES-GCM.

Combined Budget The binding constraint is whichever limit is reached first. For random nonce mode with 96-bit nonces, nonce collision (q < 2^32 at 2^(-32) target) is typically the binding constraint because integrity limits are much larger (v < 2^83 for AES-GCM, v < 2^59 for ChaCha20-Poly1305 at the same target). Applications MUST track total segment encryptions per key and rotate the CEK before exceeding either limit.

Rewrite Budget The rewrite budget is the per-key limit from applied to segment rewrites. Each rewrite counts as one encryption query against the confidentiality bound and may trigger decryption queries (for verification) against the integrity bound. With epoch_length = r and Nn = 12, each epoch key covers at most 2^r segment positions. The per-epoch nonce budget is independent of other epochs, so the content's total rewrite capacity scales with the number of epochs. For derived nonce mode, nonce collisions cannot occur from rewrites because the AEAD is MRAE. The budget is limited by the AEAD's native integrity margin (approximately 2^48 messages for AES-256-GCM-SIV per Section 6.2) and the application's key rotation policy.

raAE-v1 Profile This section defines the "raAE-v1" profile. All values are as defined in this section unless otherwise specified. The identifier "raAE-v1" is reserved for the profile defined in this document. Applications MUST NOT reuse it for a different parameter set.

Algorithms Supported AEAD Algorithms

Algorithm	Identifier	Nk	Nn	Nt	MRAE
AES-256-GCM	aes-256-gcm	32	12	16	No
ChaCha20-Poly1305	chacha20-poly1305	32	12	16	No
AES-256-GCM-SIV	aes-256-gcm-siv	32	12	16	Yes
AEGIS-256	aegis-256	32	32	16	No
AEGIS-256X2	aegis-256x2	32	32	16	No

The MRAE column indicates Nonce Misuse-Resistant Authenticated Encryption as defined in . All algorithms provide semantics with 16-octet tags (Nt = 16). AES-256-GCM is specified in . ChaCha20-Poly1305 is specified in . AES-256-GCM-SIV is specified in . AEGIS-256 and AEGIS-256X2 are specified in . The epoch_length parameter interacts with the AEAD choice. For ChaCha20-Poly1305, epoch_length MUST be present because 96-bit nonces require epoch keys to bound the per-key AEAD invocation count. For AES-256-GCM, epoch_length MUST be present for the same reason. For AES-256-GCM-SIV, epoch_length MUST NOT be present because AES-256-GCM-SIV is an MRAE AEAD and uses derived nonce mode where epoch keys are not applicable. For AEGIS-256 and AEGIS-256X2, epoch_length SHOULD NOT be present because 256-bit nonces make collision probability negligible even without per-epoch key rotation. The following table summarizes valid parameter combinations: Valid Parameter Combinations

AEAD	nonce_mode	epoch_length
AES-256-GCM	random, pt-bound	MUST present
ChaCha20-Poly1305	random, pt-bound	MUST present
AES-256-GCM-SIV	derived	MUST NOT present
AEGIS-256	random, pt-bound	SHOULD NOT present
AEGIS-256X2	random, pt-bound	SHOULD NOT present

The KDF is HKDF-SHA-256 (), with Nh = 32. The framework supports single-stage KDFs; a future document may define a profile using one (for example, TurboSHAKE256). The supported segment sizes are 16384 and 65536 octets. Both values are powers of two and at least 4096 octets. The 16384-octet size aligns to 16 KiB memory pages (for example, on Apple Silicon). The 65536-octet size aligns to 64 KiB (four 16 KiB pages). The commitment_length is 32 octets. The aad_label is "raAE-DATA". The per-AEAD usage limits for raAE-v1 follow the analysis in . The table below gives per-key limits for 65536-octet segments at a 2^(-32) advantage target. Per-Key AEAD Usage Limits

AEAD	Conf. (q)	Integ. (v)	Binding
AES-256-GCM	2^32	2^83	conf.
ChaCha20-Poly1305	2^32	2^59	conf.
AES-256-GCM-SIV	(MRAE)	2^48	integ.
AEGIS-256	2^112	2^83	integ.
AEGIS-256X2	2^112	2^83	integ.

Confidentiality values are rounded down to the nearest integer exponent. The "Binding" column indicates which limit is reached first in practice. For 96-bit-nonce AEADs with random nonces, confidentiality (nonce collision) binds. For AEGIS and GCM-SIV, integrity binds because nonce collisions are either negligible (256-bit nonces) or impossible (derived nonces). The AEGIS integrity values are conservative: with 256-bit tags AEGIS has a stronger per-query forgery bound than AES-GCM, but raAE-v1 uses 128-bit tags (Nt = 16) where the per-query bound is comparable. 2^83 (the AES-GCM value) is used as a floor pending a published per-query analysis in . For AES-256-GCM with epoch_length = 0 (one segment per epoch): the per-epoch budget equals the rewrite count for a single segment position. At the default segment_size of 65536, a 1 TiB file contains approximately 2^24 segments. With epoch_length = 0, each segment can be rewritten approximately 2^32 times before the per-epoch birthday bound is reached at the 2^(-32) target. Epoch keys are fresh for each epoch, so rewrites in one epoch do not affect the collision bound for other epochs.

Concrete Framing The concrete framing uses a length-prefixed encoding. Each argument to Encode MUST be at most 65535 octets (the maximum representable by a 2-octet length prefix). Encode is injective: each lp16 field is self-delimiting, so the concatenation can be uniquely parsed regardless of the number of arguments. Distinct input tuples produce distinct output strings.

Two-Stage KDF (sha-256) The notation ...ikm means each element of the ikm list is a separate argument to Encode. When ikm is a single octet string rather than a list, it is treated as a one-element list. The protocol_id appears in both the HKDF salt and the extract_input as a defensive measure; binding in either position suffices for domain separation.

Payload Info Construction When epoch_length is absent: When epoch_length is present: Each element is an ASCII string or raw octet string. AEAD_id and KDF_id are the identifier strings from (for example, "aes-256-gcm" and "sha-256"). segment_size_str is the decimal ASCII representation of the segment size (for example, "65536"). epoch_length_str is the decimal ASCII representation of epoch_length (for example, "0" or "1").

Segment AAD The following instantiates the abstract segment AAD construction in for the raAE-v1 profile.

Labels KDF Labels by Role

Derivation Role	Label
Commitment	"commit"
Payload key	"payload_key"
Accumulator key	"acc_key"
Nonce base	"nonce_base"
Epoch key	"epoch_key"
Accumulator contribution	"acc_contrib"
Plaintext-bound hash	"pt-nonce"
Plaintext-bound nonce	"nonce"
Hedged key	"hedge"

Each label is an ASCII string and is distinct from all others.

Concrete Procedures

Concrete Payload Schedule The following instantiates the abstract payload schedule derivation in for the raAE-v1 profile.

Epoch Key > epoch_length return KDF("raAE-v1", "epoch_key", [payload_key], [I2OSP(epoch_index, 8)], Nk) ]]>

Segment Encryption

Accumulator

Rewrite Update Test vectors for the raAE-v1 profile are provided in .

Security Considerations raAE's ra-ROR security () rests on three assumptions: the AEAD is mu-ROR secure, the KDF is a secure PRF, and nonces do not collide. Each subsection below describes a way one of these can fail and what breaks.

Nonce Misuse Nonce reuse under a non-MRAE AEAD leaks plaintext: an adversary who observes two ciphertexts under the same key and nonce recovers the XOR of the plaintexts (for CTR-based AEADs) and can forge new ciphertexts. Random nonce mode depends entirely on the CSPRNG. If the CSPRNG returns duplicated state, segments collide. Derived nonce mode is immune because nonces are deterministic; the MRAE AEAD degrades to equality leakage on rewrite, not plaintext recovery. Plaintext-bound mode partially defends against CSPRNG duplication: different plaintexts at the same index produce different nonces because pt_hash differs, but equal plaintexts still collide. Implementations that need full RNG-duplication defense MUST use derived nonce mode with an MRAE AEAD.

Parameter Set Mismatch The nonce_mode and aad_label are not bound into the commitment or payload_info. If a reader uses a different nonce_mode or aad_label than the writer, the per-segment AEAD decryption will fail (wrong nonce or wrong AAD), but the commitment check will pass because the commitment depends only on the CEK and payload_info. Consuming protocols MUST authenticate the full parameter set, including nonce_mode and aad_label, before decryption. In particular, confusing derived for random mode with a non-MRAE AEAD causes nonce reuse on every rewrite, breaking confidentiality completely. Consuming protocols MUST integrity-protect the nonce_mode before attempting nonce recovery or AEAD decryption.

Framing and Label Errors Two classes of implementation error break cross-role isolation. A non-injective framing function maps distinct KDF input tuples to the same primitive input, correlating outputs that should be independent; implementations MUST verify injectivity per . Reusing a label across roles (for example, "commit" for both commitment and payload key) has the same effect. Labels MUST be distinct within a protocol version, and a new version that changes any derivation MUST change the protocol_id.

Parameter Misuse The nonce mode and AEAD choice are coupled. An MRAE AEAD in random nonce mode wastes its misuse resistance; a non-MRAE AEAD in derived nonce mode reuses nonces on every rewrite and breaks completely. Epoch keys compound the problem: they add a derivation layer that the MRAE nonce structure does not expect. The rule is simple. MRAE AEADs MUST use derived nonce mode and MUST NOT use epoch keys. Non-MRAE AEADs MUST use random or plaintext-bound nonce mode. See for per-AEAD guidance.

Accumulator Limitations The accumulator has four limitations worth highlighting. First, it does not bind the segment count. An adversary who controls the storage layer can remove the final segment (the one marked is_final = 1) and present truncated content where every remaining segment individually verifies. Applications MUST store the expected segment count or content size independently. A reader decrypting a single segment without verifying the accumulator and without an independent segment count cannot detect truncation. Applications that support random-access single-segment reads MUST either store the total segment count alongside the commitment and accumulator, or verify the accumulator on every read. Second, compromising acc_key lets an adversary forge accumulator values without recovering plaintext (see ). Rotate the CEK if acc_key compromise is suspected. Third, without accumulator verification a storage adversary can roll back individual segments to previously valid versions. The per-segment AEAD cannot detect this because the old ciphertext remains valid under the same key and index. Applications that skip accumulator verification on reads accept this rollback risk. Fourth, a different aggregation function (not XOR) must still be commutative, associative, and support O(1) incremental update. The XOR-of-PRF instantiation in satisfies all three; substitutes MUST be verified independently.

Salt Reuse Reusing a salt with the same CEK across two files produces identical payload schedule outputs: the same payload_key, acc_key, and (in derived mode) the same nonces. An adversary can silently swap segments between the two files, and both per-segment AEAD checks and the accumulator will pass. This is a complete integrity break. Applications MUST ensure salt uniqueness per CEK; the MUST at exists for this reason.

Rewrite Hazards Two rewrite-related hazards deserve attention. Applications MUST track total segment encryptions per key and rotate the CEK before exceeding the budget in . For AES-256-GCM with epoch_length = 0, that budget is roughly 2^32 rewrites per segment position; exceeding it risks nonce collisions and plaintext recovery. When multiple writers rewrite different segments concurrently, each computes an independent accumulator delta (old_contrib XOR new_contrib). Applying these deltas is commutative, but the read-modify-write on the stored accumulator requires coordination. As a recovery mechanism, the accumulator can always be rebuilt from scratch by XOR-ing all contrib values. raAE also does not guarantee atomic rewrites. A segment rewrite touches four values (nonce, ciphertext, tag, accumulator). A crash between any two of these leaves the content inconsistent. Applications MUST use write-ahead logging, copy-on-write, or an equivalent mechanism to make rewrites recoverable.

Password-Derived CEKs The CEK is specified as a 32-octet uniform random value. If an application derives the CEK from a password, the commitment becomes a deterministic function of the password and payload_info (both known to the attacker), enabling offline dictionary attacks. Applications that derive CEKs from passwords MUST use a memory-hard KDF (such as Argon2id) to produce the CEK, and MUST NOT use the raw password output as the CEK without stretching.

Constant-Time Implementation Several raAE operations handle secret data and MUST be implemented in constant time to prevent timing side-channels. The KDF calls in the payload schedule and epoch key derivation take the CEK or payload_key as input keying material. Implementations MUST ensure that HKDF-Extract and HKDF-Expand execute in constant time with respect to their key inputs. In practice this is satisfied by HMAC implementations that do not branch on key octets. The commitment comparison () MUST use a constant-time octet comparison. A variable-time comparison leaks the position of the first differing octet, which reveals partial information about the derived commitment and thus about the CEK. The XOR operations in accumulator update and derived nonce construction are inherently constant-time on standard hardware. No special care is needed for these. AEAD Seal and Open operations inherit the constant-time requirements of the underlying AEAD. Implementations SHOULD use AEAD libraries that document constant-time guarantees.

Properties Not Provided raAE protects segment content and binds segments together. It deliberately does not address four concerns that belong to the consuming protocol. The CEK must remain available as long as any reader needs access, so there is no forward secrecy. Ciphertexts are not bound to any sender identity; a signing or MAC layer is needed for sender authentication. Key identifiers and structural features of the encrypted format are visible, so unlinkability requires application-layer measures. Finally, the accumulator verifies segments within a message but cannot detect replacement of the message itself; an adversary who swaps one encrypted message for another goes undetected unless the application binds message identity externally.

Privacy Considerations raAE does not define wire formats, so the privacy properties below apply to the abstract mechanism; consuming protocols inherit responsibility for metadata protection. The number of segments and the size of the final segment reveal the plaintext length to within one segment_size boundary. Applications that require length hiding SHOULD pad the final segment before encryption. In random nonce mode, stored nonces change on each rewrite. An observer comparing two snapshots of the same encrypted content can identify which segments were rewritten by comparing per-segment nonces. The accumulator also changes on rewrite, revealing that at least one segment was modified. raAE does not provide write-pattern privacy; consuming protocols that require this property must re-encrypt all segments on each write. The per-content salt is stored unencrypted and uniquely identifies a content object. Observers can use the salt to link different copies or versions of the same encrypted content across storage locations or backups. Applications requiring unlinkability must encrypt the salt under a separate mechanism. In derived nonce mode, the accumulator is a deterministic function of the CEK, salt, and plaintext. Two encryptions of identical content under the same key material produce identical accumulators, revealing content equality to any observer of the stored accumulator. For a systematic treatment of privacy threats in Internet protocols, see .

IANA Considerations Algorithm identifiers in the raAE-v1 profile are scoped to that profile. Consuming protocols define their own identifier mappings. This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated. This document is the product of the Crypto Forum Research Group. Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties and aims to improve consistency in the terminology used in documentation. This document is a product of the Crypto Forum Research Group. Fastly Inc. Individual Contributor This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead. Informative References This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. IBM Research Europe - Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings.

Example File Layouts This appendix is informative. It describes two example layouts a consuming protocol might use to store raAE output. raAE does not mandate either layout.

Linear Layout In a linear layout the salt, commitment, accumulator, and segment data appear in sequence. The salt comes first because it is needed to derive all payload schedule values. The commitment follows so a reader can reject a wrong key before reading any segment data. The accumulator precedes the segment data so a streaming reader can verify content-level integrity before beginning decryption; this also removes any ambiguity about which segment is final. Segments then follow in index order.

Linear Layout

In random nonce mode the per-segment nonce is stored alongside the ciphertext and tag for that segment. In derived nonce mode no nonce storage is required. Linear layout supports streaming writes. A writer emits the salt, commitment, and a placeholder for the accumulator, then streams segments. After all segments are written the writer seeks back to the accumulator position and writes the final value in place.

Aligned Layout In an aligned layout all per-segment metadata is collected into a header, followed by fixed-size ciphertext blocks. The header contains the salt, commitment, accumulator, and one (nonce, tag) pair per segment. Ciphertext blocks follow at fixed offsets.

Aligned Layout

To read segment i, a reader seeks to header_size + i * segment_size. The header contains all nonces and tags, so the accumulator can be verified by reading only the header. This layout supports efficient random-access reads (one seek per segment) and enables accumulator verification without reading any segment ciphertext.

Test Vectors This appendix is informative. All test vectors use protocol_id = "raAE-v1" and KDF = sha-256. Unless stated otherwise, segment_size = 65536 octets. Vectors are provided for AES-256-GCM, ChaCha20-Poly1305, AES-256-GCM-SIV, AEGIS-256, and AEGIS-256X2. The initial vectors below use AES-256-GCM with nonce_mode = "random".

Single-Segment Vector This vector encrypts the 12-octet string "Hello, raAE!" as a single segment. The payload_info is constructed by Encode()-ing the AEAD identifier "aes-256-gcm", the segment size "65536", the KDF identifier "sha-256", and the 32-octet salt. The commitment is then derived by calling KDF with protocol_id "raAE-v1", label "commit", the CEK as ikm, and payload_info as info. The KDF trace below shows the HKDF-Extract input (Encode of protocol_id, label, CEK) and the HKDF-Expand info (Encode of protocol_id, label, payload_info, and output length), followed by the 32-octet commitment. The payload_key and acc_key follow the same pattern with their respective labels.

Two-Segment Vector

Epoch Key Vectors The following vectors use the same CEK and salt as above. They demonstrate the effect of epoch_length on payload_info and on segment key derivation. When epoch_length = 0, each segment receives a unique derived key (one segment per epoch). When epoch_length is absent, epoch derivation is skipped entirely and all segments use payload_key directly.

KDF Isolation Vectors The two outputs above share no prefix even though they differ only in the requested length L. This demonstrates that the output length commitment in the framing produces independent outputs for different L values.

Derived Nonce Mode Vector This vector uses the same CEK, salt, and plaintext as the single-segment random vector, but with nonce_mode = "derived" and epoch_length absent. The nonce is computed deterministically from nonce_base. This vector uses AES-256-GCM with derived nonces for KDF testing convenience (same CEK and salt as the random-nonce vector above). In production, derived nonce mode MUST only be used with MRAE AEADs; see .

Plaintext-Bound Nonce Mode Vector This vector uses the same CEK, salt, and plaintext as above, but with nonce_mode = "plaintext-bound". The nonce depends on both the plaintext content and fresh random material. For reproducibility, Random(12) = 0x070707...07 (12 octets of 0x07).

ChaCha20-Poly1305 Vector Single segment with random nonce mode and ChaCha20-Poly1305. Same CEK and salt as above; different AEAD_id changes the payload_info and all derived values.

AES-256-GCM-SIV Vector Single segment with derived nonce mode and AES-256-GCM-SIV. epoch_length is absent (required for MRAE AEADs).

Rewrite Vector This vector demonstrates accumulator update when segment 0 of the two-segment AES-256-GCM message is rewritten with new plaintext. The accumulator is updated by XOR-ing out the old contribution and XOR-ing in the new one.

Segment Size 16384 Vector This vector uses segment_size = 16384 with AES-256-GCM. The same CEK, salt, plaintext, and nonce as the single-segment vector above are used; the different segment_size changes payload_info and all derived values.

Multi-Segment Full-Size Vector This vector encrypts two full 65536-octet segments. It demonstrates the segment_aad is_final flag, per-segment AEAD, and accumulator XOR across full-size blocks. Segment 0 is 65536 octets of 0x00; segment 1 is 65536 octets of 0x01.

AEGIS-256 Vector Single segment with random nonce mode and AEGIS-256. Same CEK and salt as above. AEGIS-256 uses 32-octet nonces.

AEGIS-256X2 Vector Single segment with random nonce mode and AEGIS-256X2. Same CEK and salt as above. AEGIS-256X2 uses 32-octet nonces.