]> Cryptography Consulting LLC

nicholas.sullivan+ietf@gmail.com

SEAL (Segmented Encryption and Authentication Layer) is a construction that realizes random-access authenticated encryption (raAE), a primitive that partitions a message into an indexed sequence of independently accessible, individually authenticated segments. This document specifies concrete, interoperable instantiations of SEAL for particular uses, built from previously specified primitives, and applies the analysis in a companion document to state their security properties and safe usage limits. Discussion Venues Discussion of this document takes place on the raae mailing list (raae@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction SEAL (Segmented Encryption and Authentication Layer) is a construction that realizes random-access authenticated encryption (raAE). A SEAL object is an indexed sequence of segments, each encrypted and authenticated on its own, so a reader can decrypt any one segment without decrypting the rest. In a profile that permits it, a writer can re-encrypt one segment in place, append to the end, or truncate from the end. An object can also carry a keyed snapshot that binds the whole segment set as the writer recorded it. A SEAL scheme is parameterized by a cipher suite, a set of operational parameters, and a serialization layout. The immutable profile suits whole files, archives, and backups, whether read straight through or verified segment by segment against a snapshot that binds every segment. How far that binding reaches, and in particular whether it holds against a holder of the content key, depends on the snapshot authenticator, whether the ciphertext digest is set, and external authentication of the keyed snapshot (). The mutable profile suits objects edited in place, including memory-mapped files and disk encryption. The append-only profile suits growing archives and logs that are never rewritten. SEAL is specified across two documents. The companion () defines the raAE primitive, specifies the SEAL construction and its algorithms, and gives the security analysis: reductions, bounds, and budgets. This document builds its concrete suites and instantiations on that construction and derives their safe-use limits from that analysis (). It fixes what two implementations must share to interoperate: the cipher suites, the serialization layouts, and the code points. An implementer needs both, and this document uses the companion's terminology and notation. A relying protocol that does not want to make every choice can cite one of the named instantiations () and supply only a cipher suite, an AEAD algorithm paired with a KDF. The instantiation fixes the rest: the serialization layout, the snapshot authenticator, the ciphertext digest, the segment size, the nonce mode, and the epoch length, within one of the three profiles. The aead_id and kdf_id code points come from existing IANA registries, the AEAD Algorithms registry and the HPKE KDF registry. This document adds two registries of its own, one for the named instantiations and one for the snapshot authenticators ().

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. This document uses the terminology and notation of the companion () without restating them, including segment, object, commitment, snapshot authenticator, snap_id, profile, cipher suite, CEK, salt, epoch, the key-schedule and snapshot symbols (payload_info, payload_key, snap_key, LH, Np, and the per-segment leaf), the ciphertext digest, the witness, and the advantage notation used for the security bounds. ct_i and tag_i are the two parts of a segment's AEAD output under the companion's AEAD-specific split. Every suite in places its tag in the final Nt octets of that output, so tag_i is those Nt octets and ct_i is every octet before them. In random nonce mode, the stored nonce is not part of ct_i or tag_i; the leaf carries it separately as nonce_field(i) ().

aux:

The aux region, the serialized summary of that a layout stores outside the keyed snapshot and the per-segment metadata entries. It is untrusted: a reader checks it only through the keyed snapshot, as part of a witness. Its contents are fixed by the authenticator: none under the null snapshot and the digest transcript; the masked accumulator, Nh octets, under the masked multiset hash; and the keyed epoch heads d_0 through d_{n_ep-1}, in epoch order, n_ep * Nh octets, under the epoch digest tree.

Run:

The octet string a snapshot value hashes with LH: the encoded leaves of the whole object (transcript_run), the encoded leaves of one epoch (epoch_run(e)), or the concatenated epoch heads. Each leaf in a run is framed by encode; heads are concatenated, since each is Nh octets.

SEAL Suites The suites below are examples for the SEAL construction, whose concrete framing and procedures are defined in .

Algorithms SEAL defines the following AEAD algorithms. For each, the table lists its code point and the sizes the construction takes from the AEAD (): the key size Nk, the nonce size Nn, the tag size Nt, and the cipher-block size Nb, in octets. Nb is written n/a where no block-size limit applies: for a stream cipher, or for an AEAD whose analysis binds on forgery instead. The MRAE column marks whether the AEAD is misuse-resistant. Only a misuse-resistant AEAD may be paired with a derived nonce under rewrite (). SEAL AEAD algorithms and their sizes

Algorithm	aead_id	Nk	Nn	Nt	Nb	MRAE	committing
AES-128-GCM	0x0001	16	12	16	16	no	no
AES-256-GCM	0x0002	32	12	16	16	no	no
ChaCha20-Poly1305	0x001D	32	12	16	n/a	no	no
AES-256-GCM-SIV	0x001F	32	12	16	16	yes	no
AEGIS-256	0x0021	32	32	16	n/a	no	no
AEGIS-256X2	0x0024	32	32	16	n/a	no	no

The aead_id values are the unsigned 16-bit code points from the IANA AEAD Algorithms Registry (), encoded as uint16(id). The registry's textual identifiers are, in table order, AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_CHACHA20_POLY1305, AEAD_AES_256_GCM_SIV, AEAD_AEGIS256, and AEAD_AEGIS256X2. AES-128-GCM and AES-256-GCM are specified in , ChaCha20-Poly1305 in , AES-256-GCM-SIV in , and AEGIS-256 and AEGIS-256X2 in . The AEGIS code points 0x0021 and 0x0024 are registered in the AEAD Algorithms registry. The nonce mode and epoch_length are not properties of the AEAD. A profile and the referencing protocol set them (, ), within the per-suite budgets of . The append-only and immutable profiles accept any AEAD, because their writer disciplines keep every derived nonce unique (). For ChaCha20-Poly1305, random nonce mode departs from Section 2.6, which requires the nonce to be unique per invocation with the same key and so forbids generating it at random. SEAL relies instead on the birthday bound of : within the random-nonce budget of , about 2^32 encryptions per epoch key, a nonce repeats under that key with probability at most 2^-32. A repeated nonce reproduces both the keystream and the one-time Poly1305 key, so it costs authentication as well as confidentiality for that nonce ( Section 4). No SEAL AEAD is natively committing (the committing column). An instantiation that must bind its segments against a CEK holder sets the ciphertext digest (), so each segment's leaf carries LH(ct_i). The commitment is a payload_info choice independent of snap_id. Content binding against a CEK holder needs it together with a strict authenticator (snap_id 0x0002 or 0x0003, ) and a snapshot authenticated outside the construction, and a linear authenticator MUST NOT set it (). Only the attachment instantiations () set it. An AEGIS profile that a shared-object protocol consumes SHOULD set it too, since AEGIS's 128-bit tag does not bind its segments (). These conditions bind ciphertext bytes. The strict authenticators' leaf also carries each segment's nonce field and segment additional authenticated data (AAD). The strict authenticators therefore fix each index's nonce and AAD in either nonce mode and give per-index binding for every suite (). SEAL permits the KDF cipher suites in , identified by entries from the HPKE KDF Registry ( Section 7.2 and ): Permitted SEAL KDF Cipher Suites

kdf_id	Name	Construction	Nh
0x0001	HKDF-SHA-256	Two-step HKDF-Extract+Expand	32
0x0002	HKDF-SHA-384	Two-step HKDF-Extract+Expand	48
0x0003	HKDF-SHA-512	Two-step HKDF-Extract+Expand	64
0x0013	TurboSHAKE-256	One-step XOF (absorb+squeeze)	64

HKDF-SHA-256 is specified in . TurboSHAKE-256 is the extendable-output mode of the Keccak-p permutation family, specified in and selected by for the HPKE KDF Registry. The kdf_id values are the unsigned 16-bit code points from the HPKE KDF Registry, encoded as uint16(id). Nh and commitment_length equal the KDF's primitive output size, 32 octets for HKDF-SHA-256, 48 for HKDF-SHA-384, and 64 for HKDF-SHA-512 and TurboSHAKE-256. HKDF-SHA-256 is the baseline KDF. The others are optional alternatives. The two-step Extract and Expand are HKDF-Extract and HKDF-Expand. The one-step XOF uses TurboSHAKE256 with D = 0x1F, the Derive convention's domain-separator byte, which an implementation MUST NOT change. The snapshot authenticator is selected by snap_id: SEAL Snapshot Authenticators

snap_id	Name	Values produced
0x0000	none	none produced
0x0001	masked multiset hash	keyed snapshot, per
0x0002	digest transcript	keyed snapshot and public snapshot, per
0x0003	epoch digest tree	keyed snapshot and public snapshot, per

snap_id 0x0000 selects no snapshot authenticator, a null snapshot: no keyed snapshot is produced (Na = 0) and a reader relies on per-segment authentication alone. A null snapshot is not the same as a snapshot taken over an empty segment set, itself a produced value. Which snap_id values each profile admits, and the rewrite cost of each authenticator, are set in and . The nonce mode is carried explicitly by nonce_mode: SEAL Nonce Modes

nonce_mode	Name
0x00	random
0x01	derived

The two constructions are defined in . The supported maximum 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 aad_label is "SEAL-DATA".

Composing a SEAL Suite A SEAL suite fixes an AEAD and a KDF (, ), a maximum segment size, a snapshot authenticator (snap_id, ), a nonce mode (nonce_mode, ), and an epoch length. The protocol_id identifies the parameters a profile fixes, and only certain (nonce_mode, snap_id) tuples are valid under each one. This document defines three named profiles, SEAL-RW-v1, SEAL-AO-v1, and SEAL-RO-v1. The profile names describe the writer's discipline, not tamper evidence. A profile's payload_info MUST carry the full parameter context affecting key derivation, AEAD operations, AAD construction, and nonce construction, so that the commitment () binds that context. SEAL-RW-v1 is the mutable profile (read-write). It requires a snapshot authenticator, so it admits any snap_id but a null snapshot, which among the authenticators defined here is 0x0001 (the masked multiset hash), 0x0002 (the digest transcript), or 0x0003 (the epoch digest tree), and it permits a random nonce or a derived nonce with an MRAE AEAD. It supports rewrite, extend, and truncate. SEAL-AO-v1 is the append-only profile. Because its derived nonce repeats on re-encryption (), an encryptor under SEAL-AO-v1 MUST NOT rewrite a segment with a different plaintext or associated data, and MUST NOT truncate. It changes length by the append direction of alone, whose re-mark carries the segment's existing plaintext and changes only the finality bit. The profile admits any snap_id, and the choice does not affect the append-only discipline. A protocol that needs rewrites or truncation picks SEAL-RW-v1 instead, per and . SEAL-AO-v1 provides the per-segment guarantees of SEAL-RO-v1, with one difference. Its re-mark leaves every formerly-terminal segment with an earlier ciphertext, the is_final = 1 form it held while it was terminal, which a write-once object never has. Presenting that earlier form in place of the current one is a same-index version substitution, which SnapVerify rejects. Under a null snapshot no SnapVerify runs, so an adversary can present the object at any length it legitimately held. That is rollback to an earlier honest state, which raAE places outside its scope at every snap_id () and against which the consuming protocol supplies freshness. It does mean the finality check alone no longer detects truncation under this profile, which states. A protocol that needs the current segment set bound picks any snap_id but a null snapshot. SEAL-RO-v1 is the immutable profile (read-only). Because a rewrite would repeat the segment's derived nonce (), an encryptor under SEAL-RO-v1 MUST NOT rewrite a segment once it has been written. SEAL-RO-v1 provides per-segment confidentiality and integrity, binding the segment index and the finality bit, and key commitment through the commitment field. Under a null snapshot it has no snapshot or whole-object integrity: that, when needed, comes from any snap_id but a null snapshot, or from a layer above SEAL. Truncation detection under a null snapshot rests on the finality bit alone and surfaces only when the highest-indexed present segment verifies under is_final = 1 (), so a consumer of streamed plaintext has no completeness guarantee before that terminal check. SEAL profiles

protocol_id	nonce_mode	snap_id	mutability
SEAL-RW-v1	random or derived	any but null	rewrite/extend/truncate
SEAL-AO-v1	derived	any	append-only
SEAL-RO-v1	derived	any	write-once

The snap_id column is a rule rather than a list, so an authenticator registered after this document is admitted without revising the table. Only SEAL-RW-v1 constrains the choice. It forbids the null snapshot, because a mutable object needs a snapshot to reject a superseded segment presented at its own index, and a profile that produces no keyed snapshot has nothing to reject it with. An encryptor MUST set payload_info to a (nonce_mode, snap_id, segment_commitment) tuple that is valid for its protocol_id, and a decryptor MUST reject any object whose tuple is not. A linear authenticator with the ciphertext digest set is one such invalid tuple (). A derived nonce under SEAL-RW-v1 requires an MRAE AEAD. SEAL-AO-v1 and SEAL-RO-v1 admit any AEAD because their disciplines keep each derived nonce unique ().

Choosing a Profile Pick the profile from how the stored content changes after it is first written. SEAL-RW-v1 (mutable) fits content updated in place: editable files, mutable object stores, and append-or-truncate logs. Its snapshot detects tampering with the current segment set as a whole, and the authenticators differ in update cost and per-segment-verify locality (). SEAL-AO-v1 (append-only) fits content finished in pieces and never revised: growing archives, chunk stores, and logs that are never trimmed. Unlike SEAL-RO-v1 it admits the append of . The snapshot authenticator is the remaining choice. For a growing object the masked multiset hash (0x0001) suits best: it updates in time independent of n_seg wherever the tag it removes needs no check or comes from trusted state (), and its keyed snapshot does not grow. The epoch digest tree trades that for per-segment verify locality at a higher per-append cost. The digest transcript recomputes over the full leaf list, so appending an object costs O(n^2) in total (). SEAL-log () names this profile. It forgoes even the masked multiset hash for a null snapshot, taking per-segment integrity alone and leaving freshness to the consuming protocol, and pairs it with the append-log layout, which represents the short interior segment a re-mark leaves (). No named instantiation pairs this profile with a non-null snapshot. SEAL-RO-v1 (immutable) fits write-once content: archives, backups, content-addressed blobs, and write-once media. It is the smaller and simpler choice when content is never rewritten. covers epoch_length selection, and covers the per-AEAD trade-offs that further narrow the suite.

Serialization Layouts Four serialization layouts, linear, aligned, split, and append-log, let a consuming protocol store raAE output. The parameterized SEAL construction mandates none of them. Each named instantiation binds one, and the consuming protocol pins the remaining details (). The commitment field in every layout is commitment_length octets (). The figures annotate it with its default, commitment_length = Nh. A layout's snapshot field holds the keyed snapshot. No layout stores the public snapshot. A verifier without the key recomputes it from the header, the metadata entries, which hold each leaf's leading fields, and each segment's A_i, without reading any ciphertext. The ciphertext digest is set whenever a public snapshot is used (), so for each segment it reads, the verifier recomputes LH(ct_i) from the bytes and compares it with the digest in that segment's metadata entry (). Under the epoch digest tree, the aux region holds only the keyed heads, so a keyless one-segment check takes the public heads as a witness (). In the aligned and split layouts, and in a linear layout read as a stream, each interior position has a fixed length: segment_max, or the leading slot's length for the aligned layout's unpadded first segment (, , ). That length is the minimum segment size of for interior segments. A rewrite or length change under one of these layouts MUST leave no interior segment shorter than that length, or a reader cannot locate the segment. Under a mutable profile, a writer appending after a short terminal segment first rewrites it with its existing plaintext followed by the leading octets of the new content, filling it to that length, and then appends the rest. If the new content fits in the spare capacity, the rewrite alone is enough. In the aligned layout that rewrite can land in the unpadded leading slot, because an object with one segment keeps its terminal segment there. The slot's length depends on n_seg through the header size and is not monotone: n_slot steps up at each segment_max boundary of ct_start (), so a rewrite made before the append may not fit the slot the append leaves. An aligned object that will be appended to therefore takes the padded option (). So does one that will be truncated to a different count, because the slot's length changes with n_seg. An append-only profile cannot rewrite, so it can append after a short terminal segment only in a layout that stores each ciphertext length, such as the append-log layout ().

Linear Layout In a linear layout the salt, commitment, keyed snapshot, aux region (), 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 keyed snapshot (Na octets), the configured authenticator's output, and the aux region precede the segment data so a streaming reader has both before the segments and can check the snapshot once all are read. Segments then follow in index order. When the object has at least one segment, that final segment carries is_final = 1. An empty object (n_seg = 0) has no final segment.

Linear Layout

The aux region is present when the authenticator keeps whole-object state. Because the header here precedes the segments, a streaming write can reserve the region only when its size is known before the segments are written: a fixed-size aux is reserved and filled on the seek-back that also writes the keyed snapshot, while a count-dependent aux cannot be, so a streaming linear layout carries only a fixed-size one. A non-streaming linear write, which knows n_seg in advance, has no such limit. Each segment stores its ciphertext followed by its metadata entry, meta, the same meta_len-octet entry the aligned and split layouts hold in a separate region (, ). A streaming reader recovers segment boundaries from the segment lengths. Because a segment MAY be shorter than segment_max (), a linear layout that is to be read as a stream MUST keep every non-final segment at the full segment_max, leaving only the final segment short. A reader then finds each boundary at the fixed segment length. A layout that stores shorter interior segments MUST record their lengths so the reader can locate each segment. Linear layout supports streaming writes when the aux region is fixed size or empty. A writer emits the salt, the commitment, and a placeholder for the keyed snapshot and the aux region, then streams segments. After all segments are written the writer seeks back and writes the keyed snapshot and the aux region in place. A count-dependent aux has no placeholder to seek back to, so an authenticator with one is written in a non-streaming linear layout or in the aligned or split layout instead.

Aligned Layout In an aligned layout the ciphertext segments occupy slots aligned to segment_max, so a reader can seek to any segment with page-aligned I/O. An arbitrary-length prefix, which the consuming protocol uses for its own machinery and which raAE does not specify, comes first. The raAE header follows, and the ciphertext follows the header.

Aligned Layout

Offsets are measured from index 0, the start of the prefix. Let ct_start be the offset at which the ciphertext begins (the prefix length plus the header length). The leading slot, from ct_start up to the first segment boundary n_slot * segment_max, is filled in one of two ways, chosen before writing:

• No padding: the first ciphertext segment occupies the slot, with n_slot = ceil(ct_start / segment_max). It is shorter than segment_max and ends on the boundary n_slot * segment_max.
• Padding: the slot is zero-padded to a multiple of segment_max, with n_slot >= ceil(ct_start / segment_max) (the next boundary, or a larger multiple to reserve whole segment slots for append headroom).

From n_slot * segment_max onward every ciphertext segment begins at a multiple of segment_max and is a full segment_max octets, with the final segment at most segment_max. ct_start, n_slot, and the first-segment length all follow from the prefix and header sizes, so a writer computes them before emitting any ciphertext. The header holds the salt, the commitment, the keyed snapshot, the authenticator's aux region, and one metadata entry per segment:

Aligned Layout Header

The bracketed aux region is present when the authenticator keeps whole-object state, and absent when it does not. The aligned header is sized from n_seg before it is written, so it carries a count-dependent aux without difficulty. Each metadata entry holds the optional ciphertext digest, the AEAD tag, and the optional stored nonce, in that order:

Metadata Entry

The bracketed ciphertext digest LH(ct_i) is present only when the ciphertext digest is set, and the bracketed nonce_i only in random nonce mode. The tag is always present, Nt = 16 octets in every SEAL suite (). The fields are stored in leaf order: the metadata entry is the leading part of the strict authenticators' leaf, which appends the derived-mode counter and the segment AAD (), so an implementation forms each leaf from the stored bytes, the index, the finality bit, and A_i. Each metadata entry holds the optional Nh-octet digest, the Nt-octet tag, and the Np-octet presented nonce, so meta_len = Nt + Np octets, plus Nh when the ciphertext digest is set. A random-nonce entry sets Np = Nn and is Nt + Nn octets without the digest. A derived-nonce entry recomputes the nonce from the key schedule, so Np = 0 and the entry is Nt octets without the digest. The per-suite values, for a metadata entry with no ciphertext digest, are: Metadata entry size by AEAD

AEAD	nonce mode	meta_len
AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305	random (Nn = 12)	28
AEGIS-256, AEGIS-256X2	random (Nn = 32)	48
AES-256-GCM-SIV	derived	16

The n_seg entries total n_seg * meta_len octets, so the whole header size is: The aux term is defined in . Per-segment state does not count toward it: the stored part of a leaf sits in the metadata entry and is already carried by meta_len. A layout reserves the aux region whenever it is non-empty, so header_size and every offset derived from it follow from the wire parameters. Reserving the region is separate from populating it from storage: lets an implementation recompute its heads from the leaves rather than keep them, which changes what a reader reads, not what the layout holds. Under the epoch digest tree the heads in this region are part of the witness that a subset SnapVerify reads (). With the default commitment_length = Nh, this specializes by authenticator. meta_len is not uniform across them: it grows by Nh when the ciphertext digest is set, which adds LH(ct_i) to each metadata entry (). A reader verifies the commitment and the keyed snapshot from the header alone, then seeks to any segment using these offsets. The metadata entries hold the authenticator's per-segment inputs: tag_i for the masked multiset hash, or the leading fields of the strict authenticators' leaf, which a reader completes with each segment's index, finality bit, and A_i. A reader authenticates the whole object's snapshot from the header without reading or streaming any ciphertext. Under the digest transcript it MUST then check each leaf against the segment it reads (). Under the epoch digest tree a reader fetches the keyed snapshot and the epoch-heads region together, then reads one epoch's leaf run () to check a segment.

Split Layout A split layout separates the ciphertext from the metadata into two streams that grow independently. The data stream holds the ciphertext segments, each a full segment_max except the last. Segment i is at offset i * segment_max. The metadata stream holds the salt, the commitment, any aux region, the n_seg per-segment metadata entries (each meta_len octets, broken out in ), and the keyed snapshot last. The metadata stream holds the authenticator's per-segment inputs (): tag_i for the masked multiset hash, or the leading fields of the strict authenticators' leaf, which a reader completes with each segment's index, finality bit, and A_i. A reader therefore authenticates the snapshot by reading only the metadata stream, never the data stream. When the authenticator keeps whole-object state, its aux region follows the commitment: the masked accumulator (Nh octets) or the epoch heads (n_ep * Nh octets). An entry's offset in the metadata stream therefore includes the aux length, which the authenticator and n_seg fix. gives the region's byte layout.

Split Layout

Because neither stream embeds the other, both grow by appending. Extending a nonempty message replaces the old terminal ciphertext and its metadata entry, then appends k ciphertext segments to the data stream and k metadata entries to the metadata stream, with k >= 1, and updates the keyed snapshot and any aux region. An extension from the empty object only adds the k records and updates the snapshot and aux. Truncating drops the tail of each stream, re-marks the new last segment and rewrites its metadata entry unless it empties the object, and rewrites the keyed snapshot and any aux region. Neither operation shifts an existing ciphertext segment, which the in-place aligned layout cannot avoid once the header grows.

Append-Log Layout An append-log layout serves an append-only object read or extended sequentially. It holds the salt, the commitment, then each segment preceded by the two-octet length of its ciphertext. Nothing follows the segments: the append-log layout holds no keyed snapshot or aux region, so it supports only a null snapshot, which SEAL-log selects ().

Append-Log Layout

The length before segment i is uint16(len_i), the octet length of ct_i. The field limits the layout to a segment_max of at most 65535 octets, so of the sizes this document defines only 16384 fits it. The length covers ct_i only: the meta_len-octet metadata entry () follows the ciphertext and, being fixed-width, needs no length of its own. Storing the length lets an interior segment be shorter than segment_max. An append writes the new segments at the end and re-marks the previous terminal segment in place, disturbing neither the header nor any earlier segment. Sequential append and streaming read are native. Random access needs a walk from the start or an external index, which suits a log.

Reduced Layouts under a Derived Nonce Under a derived-nonce profile (SEAL-RO-v1 or SEAL-AO-v1), stored fields drop out of the layouts above. Each nonce is recomputed from the key schedule, so Np = 0 and no nonce is stored. SEAL-AO-v1 additionally lets an append-only object carry a short interior segment, held by the append-log layout (). Under a null snapshot the keyed snapshot drops (Na = 0) and a metadata entry is the Nt-octet tag alone. The linear layout reduces to the salt, the commitment, and the per-segment ciphertext and tags. The aligned and split header sizes are: The two strict-authenticator lines take the ciphertext digest () as set, so each entry carries LH(ct_i) beside the tag. Without it the entry is the Nt-octet tag, as under snap_id 0x0000. An authenticator that keeps whole-object state also carries its aux region in the header (). In the aligned layout every ciphertext segment begins at a multiple of segment_max, so a reader seeks to any segment by arithmetic on its index and verifies it from its own tag.

Content-Defined Chunking (Reserved) Segments take writer-chosen boundaries, each carrying up to segment_max octets. Two modes that place those boundaries by content, using content-defined chunking, are reserved for a future revision. They are an append-only mode and an in-place-editing mode with expansion. Neither is specified here.

Snapshot Authenticator Instantiations These snapshot authenticators instantiate the interface of , each selected by a snap_id value (). A null snapshot (snap_id 0x0000) configures no authenticator and is defined in .

Masked Multiset Hash This snapshot authenticator builds an updatable, masked multiset hash over the segment tags. It accumulates one indexed, keyed contribution per segment, in the MSet-XOR-Hash form of Clarke et al. (), then publishes that accumulator behind a deterministic mask this document adds. Its per-segment contribution is: The masked multiset hash fixes three labels: contrib_label = "acc_contrib", snapshot_label = "snap_acc", and acc_mask_label = "acc_mask", each distinct from all other SEAL labels. The finality bit is bound through tag_i: it is an AEAD input in both nonce modes (segment_aad in random mode, the low nonce bit in derived mode, ), so flipping it changes tag_i, hence contrib(i), hence the accumulator. No explicit binding in contrib is needed. The masked multiset hash aggregates the per-segment contributions into the accumulator acc by bitwise XOR: The accumulator is an Nh-octet value, with the all-zero string as the value for the empty segment set. XOR is order-independent, so the accumulator does not depend on segment order, and it is its own inverse, so rewriting segment i removes its old contribution and adds the new one by XOR, in O(1) time, and without re-reading any other segment where the old tag needs no check or comes from trusted state. The accumulator is linear, and publishing it in the clear would let a write adversary recombine the differences between successive values into a non-historical segment set (). The masked multiset hash therefore does two things. First it authenticates the count and accumulator as the snapshot, a message authentication code (MAC) under snap_key with its own label: Write snapshot = snapshot(n_seg, acc) for the present count and accumulator. Second, the masked multiset hash derives a mask from snap_key under the third label, seeded by that snapshot rather than by a fresh nonce, and XORs it into the accumulator to form the masked accumulator wrapped_acc: Seeding the mask with the snapshot rather than a fresh nonce is the synthetic-IV derandomization of deterministic authenticated encryption (): the snapshot stays a deterministic function of (n_seg, acc) while the stored accumulator is hidden behind a one-time pad (). The count n_seg is not stored in the keyed snapshot. The verifier supplies it as the number of segments present, and the snapshot binds it under the MAC. An object with n_seg = 0 is a valid empty object. It holds the salt, the commitment, and the keyed snapshot, with no ciphertext segments and no per-segment tags. Its accumulator is the XOR over the empty segment set, namely 0^Nh, and the same masking as any other count applies, so the empty snapshot, meaning this authenticator's snapshot over zero segments rather than an absent one, is not a fixed constant but a masked authenticator over that empty set: An empty object is distinct from a zero-length plaintext, which is one final segment (n_seg = 1) whose plaintext has length 0. Where the old tag needs no check or comes from trusted state, the writer can rewrite segment i without re-reading the other tags. The writer first recovers the accumulator from the stored wrapped_acc by removing the mask, acc = wrapped_acc XOR acc_mask(n_seg, snapshot). It then XORs contrib(i) computed from the old tag (stored alongside the ciphertext) out of acc, XORs in contrib(i) computed from the new tag, and produces the new snapshot over the unchanged count. Under the writer rule of , a writer that does not take wrapped_acc from locally trusted snapshot state recovers acc by checking it against a verified snapshot, with n_seg the count that snapshot is for: A party without snap_key that alters wrapped_acc, or the count, changes an input to snapshot(n_seg, acc), so the check passes only if that function agrees on two distinct inputs, which under the PRF assumption on snap_key that the key schedule already carries happens with probability about 2^-(8*Nh) per attempt. On a mismatch the writer can instead recompute acc from every stored tag, with verify's index-set check. It uses that acc only if snapshot(n_seg, acc) matches the verified snapshot under the same constant-time comparison, and otherwise the update fails. The update's witness () is therefore wrapped_acc and, where a removed tag is checked by recomputation, every stored tag. As with verify, the writer MUST NOT surface any unmasked accumulator it holds, whether recovered, recomputed, or updated, or any contribution value, and the only snapshot state it publishes is the new snapshot and wrapped_acc (). The tag that an update XORs out, for a segment it rewrites, re-marks, or drops, needs no check under the writer rule of in two cases only: in random nonce mode while the nonce source does not repeat, and in a SEAL-AO-v1 re-mark. In both, where the update decrypts the segment, the tag removed is that record's own, read once with it. If the tag removed is not the one whose contribution acc holds, acc keeps the XOR of the two contributions, and the in-place update carries that leftover into every later update. In a SEAL-AO-v1 re-mark the record decrypts under the derived nonce of (t, 1), and permits one encryption at that pair under the salt. So a record that decrypts is the one the writer wrote, and its tag is the one acc holds. A record that does not decrypt fails the update. In random nonce mode, while the nonce source does not repeat, the argument is a count over the terms at one index. A stale removal leaves two terms unpaired, the tag acc still holds and the stale tag it removed. Those two, and every fresh tag added there from the stale update on, are cancelled only by a removed tag the adversary chooses afterwards, or by the one tag a verifying set presents. A rewrite or re-mark brings one removed tag and one fresh tag, a drop a removed tag alone, and a re-add a fresh tag alone. An index is dropped only while the object holds it and re-added only while it does not. So the tags removed after the stale one, together with any tag that a verifying set presents there, always number two fewer than the terms left to cancel. The index can be made unverifiable, but never laundered. Every other removal takes its tag from locally trusted snapshot state or checks it by the recompute above: any removal under SEAL-RW-v1 with a derived nonce, and any removal once the random nonce source can repeat. Duplicated state of a cryptographically secure pseudorandom number generator (CSPRNG) can make it repeat: directly drawn nonces repeat, and a plaintext-bound nonce repeats when the plaintext, index, and segment AAD repeat too. Under HedgedRandom a nonce repeats on duplicated state only when tag2 repeats with it, which the companion forbids, or by an output collision (). Where such an update decrypts the segment, as a re-mark does, it compares that record's tag with the checked one. Under a derived nonce, an identical rewrite reproduces the current tag, so XORing out an older tag in its place leaves exactly the accumulator of the set that holds the older version. A rewrite back to the older plaintext reproduces the removed tag instead and leaves acc unchanged, so the new snapshot keeps certifying the version the writer replaced. The snapshot is Nh octets, so Na = Nh, as it is for every other authenticator here that produces one ( defines Na in general). wrapped_acc is not part of it. SnapVerify never reads wrapped_acc: it recomputes the accumulator from the tags present and recomputes the snapshot over the count it observes. wrapped_acc exists so that a writer can rewrite one segment without re-reading every other tag where the old tag needs no check or comes from trusted state. That makes it a summary in the sense of , derivable from the per-segment inputs and stored only to bound the read set. It is this authenticator's aux region, Nh octets (). The epoch digest tree's heads are another authenticator's aux region, and an object carries the aux region of its own snap_id alone. SnapVerify runs only under a state derived from the CEK, payload_info, and G: the writer's own, or a reader's after the commitment check of decryption (). The snapshot's per-object binding rests on snap_key (). The masked multiset hash realizes verify(snapshot) for the SnapVerify of . SnapVerify supplies the count n_seg and the present segment tags: The comparison runs in constant time (). Because the accumulator is order-independent under XOR, a duplicate or missing index can leave acc_calc recomputing to the genuine accumulator and the comparison passing, which is why SnapVerify's index-set check () is mandatory. verify returns only accept or reject. An implementation MUST NOT surface the recomputed accumulator, any contribution value, or any value derived from them, and MUST NOT signal through an error code or timing anything beyond that one bit. The recomputed accumulator is what the at-rest mask hides from a write adversary (): exposing it here would reinstate the recombination attack. A modified tag or count changes the recomputed snapshot, and a different key or parameter context fails the commitment check that precedes a reader's SnapVerify (). The forgery bound is in and the rollback limitation in .

Digest Transcript This snapshot authenticator is a per-object digest transcript: one keyed KDF evaluation over the digest of the ordered run of per-segment leaves (). It has no accumulator and no mask, and it recomputes over the full leaf list on any rewrite. Its ordering is strict: a fixed, published snapshot cannot be made to verify a different ordered leaf list, even by a party that holds the CEK and every key derived from it. When the ciphertext digest is set, so the leaf carries LH(ct_i), the snapshot additionally binds each segment's ciphertext bytes, along with its AEAD tag, nonce field, and segment AAD (). A consuming protocol that authenticates the keyed snapshot, for example by binding it into a signed reference or manifest, extends that binding to per-segment ciphertext origin authentication. Its per-segment input is the segment leaf leaf(i) of , with ct_i and tag_i following the AEAD-output convention of . In derived nonce mode the leaf's nonce field is an 8-octet counter. LH is the over-large-field digest of , so where the ciphertext digest is set LH(ct_i) is a fixed Nh-octet value that binds segment i's ciphertext through the collision resistance of LH for any segment length. The leaf's length varies with A_i, and the run that carries the leaves frames each one. Without the ciphertext digest, the transcript binds the tags, nonce fields, and segment AAD but not the ciphertext content. The ciphertext digest is a deterministic function of public object bytes, so any party can recompute or publish it without holding a key. The tag is the value the AEAD already produced for the segment. leaf(i) is the digest transcript's per-segment input, taking the role the tag plays for the masked multiset hash (). In random nonce mode the leaf carries the presented nonce, so different nonces give different leaves even against a key holder. In both nonce modes the leaf carries the finality bit and the segment AAD, so a verifier needs each segment's A_i to form it. Position within the object is bound by the ordered run below and the count by n_seg. The digest transcript places no restriction on the nonce mode. Every value of the digest transcript and of the epoch digest tree (), keyed or public, has one shape: a KDF over the payload_info elements, the commitment, a count, and the LH digest of a run, with ikm = [snap_key] for a keyed value and ikm = [] for a public one. The digest transcript's keyed snapshot, written snapshot, and its public snapshot (), written pub_snapshot, take the count n_seg and the run of every leaf in index order: Digest Transcript Values

Value	label	ikm	count	run
snapshot	transcript_label	[snap_key]	n_seg	transcript_run
pub_snapshot	pub_transcript_label	[]	n_seg	transcript_run

Each value is Nh octets, so Na = Nh. The two labels, transcript_label = "snap_transcript" and pub_transcript_label = "snap_transcript_pub", are distinct from each other and from all other SEAL labels under the encode frame, and ...payload_info passes each payload_info element as a separate info element (). The run enters as its LH digest, so a reader can absorb the leaves into an incremental LH state as segments arrive and derive the value from the digest and the count without holding the run. The ordering is strict, so the digest transcript has intermediate snapshots (): at a count k at which the object is open, its values are the formulas above with k in place of n_seg, over leaf(0) through leaf(k-1), each formed with is_final = 0, and a reader absorbing leaves in order derives the value at any k from a copy of its LH state. The commitment element repeats the object's commitment () inside the value. For SnapVerify it binds G, which snap_key does not: a snapshot from an object that shares this object's CEK and payload_info but not its G fails against this object's commitment. It is also load-bearing for a consuming protocol that lifts either value into a signature or MAC, which then carries the full object context (CEK, payload_info, and G) and cannot be replayed against an object with a different context (). The payload_info elements add nothing to the keyed snapshot that the commitment element and snap_key do not already bind. For the public snapshot they are what binds every parameter that governs parsing and algorithm choice, since a verifier without the key cannot check payload_info through the commitment. The digest transcript realizes verify(snapshot) as follows. The caller (SnapVerify, ) MUST already have checked that the present indices are exactly 0..n_seg-1, each once. The comparison runs in constant time (). The index-set check in SnapVerify remains mandatory (). Here it is defense in depth rather than load-bearing, because a malformed index multiset changes the framed leaf list and the recomputed value with it. The digest transcript is per-object (): it provides no add, remove, or set_length, and produces the snapshot in a single KDF call over the digest of the leaf run. Any change to the segment set recomputes the transcript over the new leaf list and re-publishes the keyed snapshot. A write-once profile computes it once, at encryption, and only verifies it thereafter. A change folds every leaf it keeps unchanged into the new snapshot, formed from the stored entries and each segment's A_i, read from a carried leaf list, or recomputed from the stored segments, so the writer rule of covers the list, which is the witness of both an update and a subset SnapVerify (), with length the count. Unless the writer produced the list itself as the sole writer, it first recomputes the transcript over it as it stands and compares the result with a verified snapshot in constant time, as verify does. On a mismatch the update fails. A segment the change decrypts, as a re-mark does, passes when the leaf recomputed from its record matches its entry in the checked list. An object with n_seg = 0 is a valid empty object under the digest transcript. The run is empty and the keyed snapshot is KDF(protocol_id, transcript_label, [snap_key], [...payload_info, commitment, uint64(0), LH("")], Nh), so the count is bound and truncation to the empty object is distinguishable from a legitimate empty object. verify above recomputes each leaf from the stored segment bytes and A_i, so whole-object SnapVerify reads the full object. A layout holds the leading fields of leaf(i) in each per-segment metadata entry, and a consuming protocol MAY carry the leaf list beside the object, for example in a manifest. A reader MAY then verify the transcript over the leaves formed from the stored entries and each segment's A_i, or over the carried leaves, without reading any ciphertext. It MUST compare leaf(i), recomputed from the one segment it reads and its A_i, against the leaf at position i before treating that segment as covered by the snapshot. A segment whose recomputed leaf does not match fails authentication. The procedure verifies any subset of the segments, down to a single one, against the whole-object snapshot, and is how a consuming protocol obtains per-segment ciphertext origin authentication from one authenticated keyed snapshot. No layout stores the public snapshot (). Once it is authenticated, so is every parameter payload_info carries, and a verifier that holds no key MUST parse the leaves under those parameters. Such a verifier checks an authenticated public snapshot as verify does, with the public label and an empty ikm, recomputing it over leaves formed from the stored segments or entries and each segment's A_i, or over carried leaves under the per-segment comparison above, and comparing in constant time, though the comparison carries no secret. A modified leaf or count changes the recomputed transcript, and a different key or parameter context fails the commitment check that precedes a reader's SnapVerify (). The forgery and binding arguments are in .

Epoch Digest Tree This snapshot authenticator is an epoch digest tree. Segment leaves () fold into per-epoch heads, and the heads fold into the snapshot. A reader verifies one segment from two aligned metadata reads plus the segment itself: the target epoch's leaf run, and the epoch-heads region. Each of those two metadata reads is one segment_max or less for objects up to roughly 128 GiB at the recommended parameters (). The design has the digest transcript's binding properties and adds this bounded random-access verification for large objects.

Epoch digest tree: leaves in each epoch are folded by a keyed transcript into one epoch head, and the epoch heads are folded by a keyed transcript into the snapshot. There is no Merkle path

Its per-segment input is the segment leaf of , as for the digest transcript (). d_e and pd_e are the epoch heads over one epoch's leaves, and snapshot and pub_snapshot are the digests over d_0 through d_{n_ep-1} and over pd_0 through pd_{n_ep-1}. Segments are grouped into epochs of 2^r consecutive indices, where r = epoch_length () is reused as the grouping fan-out, so no new parameter is added. Only the final epoch may be short. There are n_ep epochs, the same grouping the epoch key uses, so each epoch head covers exactly the segments under one epoch key. Each value of the epoch digest tree has the shape of . Epoch e's two heads, d_e for the keyed snapshot and pd_e for the public snapshot, take as count the number of leaves in the epoch, m_e, and as run the epoch's leaves. The two values over the heads, snapshot and pub_snapshot, take n_seg and the heads in order: Epoch Digest Tree Values

Value	label	ikm	count	run
d_e	epoch_head_label	[snap_key]	m_e	epoch_run(e)
pd_e	pub_epoch_head_label	[]	m_e	epoch_run(e)
snapshot	head_label	[snap_key]	n_seg	d_0 || ... || d_{n_ep-1}
pub_snapshot	pub_head_label	[]	n_seg	pd_0 || ... || pd_{n_ep-1}

In an object with one epoch, d_0 is the digest transcript's snapshot formula over the same object under epoch_head_label in place of transcript_label. The leaves vary in length with A_i, so the epoch run frames each one as an element of encode (), and a leaf longer than 0xFFFE octets enters as its LH digest. The epoch heads are fixed length (Nh octets). Each run therefore parses unambiguously, with an element count that n_seg and epoch_length fix. A reader forms epoch_run(e) from the epoch's stored run, its metadata entries in leaf order, with each segment's index, finality bit, and A_i. Where this document gives the size of an epoch's leaf run or counts reads of it, it means the stored run. Each head carries payload_info, the commitment, and its leaf count, and each leaf in its run carries its own index, in the nonce field in derived nonce mode and in the segment AAD in random nonce mode. The heads of different objects or epochs are therefore computed over different inputs, and each head's place in the ordered heads run binds its position as well. A short final epoch is bound by its head's count and by n_seg and epoch_length in the root. The segmentation is recovered only from n_seg and epoch_length, so a profile that selects the epoch digest tree MUST carry epoch_length in payload_info, as every profile in this document does. The heads and the root then bind it for both values, and the keyed snapshot binds it through snap_key as well, so no party can present one heads run under a different fan-out. Each run enters the KDF as its LH digest, as in , so a reader carries an incremental LH state across segments and epoch boundaries. Every element the KDF sees is at most Nh octets, the 32-octet salt included. Each value is Nh octets, so Na = Nh. The epoch digest tree fixes four labels, epoch_head_label = "snap_epoch" and head_label = "snap_epoch_root" for the keyed snapshot, and pub_epoch_head_label = "snap_epoch_pub" and pub_head_label = "snap_epoch_root_pub" for the public snapshot, each distinct from all other SEAL labels under the encode frame (). The payload_info elements, the commitment, and the count are bound as in , and the snap_key ikm makes the keyed snapshot unforgeable without the key (). The leaf binds the tag, the nonce field, and the segment AAD (), so the epoch digest tree places no restriction on the nonce mode. The layout stores the n_ep epoch heads, in the aligned layout's header beside the keyed snapshot or after the commitment in the split layout's metadata stream (), and the leading fields of each leaf in its metadata entry. The keyed snapshot is Nh octets. The epoch heads are recomputable from the leaves, so an implementation MAY recompute them rather than rely on the stored ones, at the cost of reading every entry. The serialization layouts reserve and populate the region whenever snap_id is 0x0003 (), because header_size and the segment offsets derived from it must follow from the wire parameters alone. Recomputing is therefore a choice about what a reader trusts, not a licence to omit the octets. The two-read random-access verification below requires a layout whose metadata entries are contiguous within an epoch, so one seek reads the whole epoch. A layout that interleaves the entries with the ciphertext does not have this property, and a reader gathers an epoch's entries with one seek per segment. verify(snapshot) recomputes the whole transcript. The caller (SnapVerify, ) MUST already have checked that the present indices are exactly 0..n_seg-1, each once. Random-access verification of one segment, in the aligned or split layout (, ), costs two aligned reads beyond the segment itself. A reader verifies the head once and keeps the epoch heads, then per segment: > r read epoch e's metadata entries, m_e of them, from segment e * 2^r's metadata entry ;; one aligned read form epoch_run(e) from them with each segment's index, finality bit, and A_i d_calc = KDF(protocol_id, epoch_head_label, [snap_key], [...payload_info, commitment, uint64(m_e), LH(epoch_run(e))], Nh) check d_calc equals the cached d_e (constant time) read segment i from the data region leaf_calc = [LH(ct_i)] || tag_i || nonce_field(i) || segment_aad(i, is_final, A_i) check leaf_calc equals the leaf at position i mod 2^r within epoch e's run (constant time) ]]> A cold single-segment check is two metadata reads, the epoch-heads region and one epoch's leaf run, each one aligned read up to the ceiling (). A reader scanning many segments reads the epoch-heads region once and then one epoch leaf run per epoch, so the amortized cost is one metadata read per segment. Those two reads, with the count n_seg that head_calc binds, are the witness of a subset SnapVerify (). For several presented segments the witness is the count, the epoch heads, and the leaf run of each epoch that holds one, and an update's witness is the epoch heads and the affected epoch's leaf run. These costs hold when the epoch's A_i are empty or available to the reader without further reads. All comparisons run in constant time (). A segment whose recomputed leaf, epoch head, or head does not match fails authentication. The reader recomputes only its own leaf and its own epoch head and reads no other segment's ciphertext. The epoch digest tree is per-object (): it provides no add, remove, or set_length. A rewrite of segment i recomputes only epoch e's head and the keyed snapshot, where e = i >> epoch_length, leaving the other epoch heads unchanged. As with any keyed snapshot, a consuming protocol that signed the value re-signs the new one. Under a write-once profile each snapshot, the final one and any intermediate one, is computed once, at its count. Under an append-only or mutable profile a change is the same two aligned metadata reads as verification (the epoch's leaf run and the epoch-heads region) followed by three metadata writes: the new entry, the new epoch head, and the new keyed snapshot. A change folds into the new snapshot the heads of the epochs it leaves unchanged, the leaves it keeps unchanged in each epoch whose head it recomputes, and the plaintext of any segment it decrypts. Unless the writer produced them itself as the sole writer, it checks the heads and leaves with the first two comparisons of verify_segment, made against a verified snapshot () rather than the stored one: head_calc over the stored heads, then d_calc over the run formed from each such epoch's stored entries against that epoch's checked head. On any mismatch the update fails. A segment the change decrypts passes when the leaf recomputed from its record matches its entry in the checked run, verify_segment's third comparison. An object with n_seg = 0 has n_ep = 0 and an empty heads run: so the count is bound and truncation to the empty object is distinguishable. Choose the largest epoch_length whose epoch leaf run still fits one aligned read, so recomputing an epoch head is a single read: The values below are for a derived-nonce entry with the ciphertext digest set (Np = 0, meta_len = Nh + Nt). A random-nonce entry has meta_len = Nh + Nt + Np, so its stored run grows by Np octets per segment. Recompute r from the rule above. Suggested epoch_length by segment_max and KDF output length Nh

segment_max	Nh	Suggested epoch_length
65536	32 or 48	10
65536	64	9
16384	32 or 48	8
16384	64	7

The epoch-heads region of the header is n_ep * Nh octets, one aligned read up to about 128 GiB at r = 10, Nh = 32, and segment_max 65536. Past that it spans 1 + ceil(content size / that ceiling) reads. The forgery and binding arguments are in . The random-access benefit is realized only when epoch_length is in the grouping range of . A profile that sets a large epoch_length for key rotation, such as a flat key at 63, makes n_ep = 1, so the fold is a single epoch: still correct, with no random-access benefit. A single epoch is still the two-level epoch digest tree under its own labels, not the digest transcript value. A profile that wants random-access verification sets epoch_length to the value and accounts for the resulting per-epoch-key write budget in .

Public and Intermediate Snapshots The epoch digest tree's public snapshot takes the public labels and an empty ikm at both levels, so its heads pd_e are separate values from the keyed heads d_e. A verifier that holds no key MUST parse leaves, runs, and witness heads under the parameters the authenticated value carries. No layout stores the public heads or the public snapshot (). A verifier that holds no key recomputes them from the leaves, or takes exactly n_ep * Nh octets of heads as a witness that the consuming protocol carries beside the authenticated pub_snapshot, and checks the witness by recomputing pub_snapshot from it. It MUST reject a witness of any other length. It checks one segment as verify_segment does, with the public labels, an empty ikm, and the witness heads in place of the stored ones. The epoch digest tree's ordering is strict, so it has snapshots () at every count k at which the object is open. The formulas above with k in place of n_seg give snapshot(k) over d_0 through d_e and pub_snapshot(k) over pd_0 through pd_e, where e = (k-1) >> r, and the last head d_e, or pd_e, folds the leaves of epoch e present at k, with their count k - e * 2^r. A writer that produces intermediate snapshots holds one complete segment back until more content or the end arrives, and marks the last segment final when it encrypts it (). The leaves of each intermediate snapshot are then a prefix of those of every later snapshot, the final one included, as long as the writer neither re-marks nor rewrites a segment below a count at which it produced one. A reader that receives segments in index order checks each intermediate snapshot as it arrives. It forms each leaf from the segment bytes it holds and the segment's A_i, with is_final = 0, and with is_final = 1 at n_seg-1 when it checks the final value after that segment decrypts as final, never taking a stored or carried leaf or head in place of one it can compute. It keeps two running LH states, one over the current epoch's leaf run and one over the heads of the full epochs below it, both incremental because LH is the suite's Extract or XOF (). To check the value at k it finalizes a copy of the epoch-run state into the head of epoch e with its count, absorbs that head into a copy of the heads state, finalizes it, derives the value at k, and compares in constant time. At an epoch boundary it absorbs the full epoch's head into the heads state itself and starts the next epoch's run. A reader that joins late does so at an epoch boundary k = (e+1) * 2^r, where every head below k is full and never changes. It takes d_0 through d_e, or pd_0 through pd_e, exactly (e+1) * Nh octets, from the consuming protocol, derives the value at k from them, and compares it in constant time with the value published at k, which for pub_snapshot(k) is accepted only under the signed statement. On acceptance it adopts the heads as its running state and continues in order from segment k. It has authenticated a summary of the segments below k, not their ciphertext or their availability. Every leaf of an intermediate snapshot at count k is formed with is_final = 0, in the nonce field in derived nonce mode and in the segment AAD in random nonce mode, so the value fixes is_final = 0 at index k-1, and a verifier MUST NOT infer finality from the value's count. A consuming protocol that signs intermediate snapshots MUST define how a checkpoint is identified, its rollback policy, and any fork detection it claims.

Snapshot Authenticator Security Snapshot integrity instantiates the snapshot-forgery advantage Adv_snap of the master ra-ROR bound () per snap_id: the None selection contributes zero, and each authenticator below contributes the terms its construction requires. Every keyed snapshot in this document is a KDF output over an intermediate value that commits to the segments: the accumulator with the count under the masked multiset hash, the LH digest of the encoded leaf run under the digest transcript, and the LH digest of the heads run under the epoch digest tree. Call that the committed value. Matching it at the same count matches the snapshot, because the KDF that follows is deterministic, so an adversary attacks the committed value rather than the snapshot.

Masked Multiset Hash SEAL's masked multiset hash publishes its keyed snapshot, a MAC over the count and accumulator under snap_key, and stores the masked accumulator wrapped_acc beside it as a summary. wrapped_acc is that accumulator hidden behind a deterministic, tag-derived one-time pad. The mask stops a write adversary that does not hold snap_key from recombining the differences between published accumulators into a non-historical segment set. A party that holds snap_key derives the mask and strips it. The three labels contrib_label, snapshot_label, and acc_mask_label are distinct under the encode frame. For snap_id 0x0001 the Adv_snap term of the master ra-ROR bound () is bounded by a fresh-input MAC term, a mix-and-match term, and a birthday term in the number of published snapshots that the deterministic masking introduces, on no assumption beyond the multi-user PRF the key schedule already uses. derives the value. Under this authenticator, SnapVerify recomputes the keyed snapshot from the observed count and the recomputed accumulator and compares it against the stored keyed snapshot in one constant-time comparison. A variable-time comparison would reveal the position of the first differing octet, letting an adversary who retries tampered inputs learn the expected keyed snapshot one octet at a time.

Digest Transcript SEAL's digest transcript publishes one keyed KDF evaluation over the payload_info elements, the commitment, the segment count, and the LH digest of the encoded leaf run (). Its transcript label is distinct under the encode frame, the encode framing of the run binds each leaf's position, and the count element binds the count. Without snap_key, a forgery is one of two events. The first is a fresh-input forgery of the keyed derivation, on the same multi-user PRF assumption as the rest of the key schedule. The second is a second preimage of LH at the leaf run, a multi-target term over the run under each published snapshot, since a different run with the same digest leaves the keyed snapshot unchanged. It is the term the epoch digest tree carries at its runs, and the long-message and sponge figures of apply to it, with the run of n_seg leaves, the longest LH input of either authenticator, as the target. There is no accumulator to recombine, no mask, and no birthday term in the number of published snapshots. The leaf gives the transcript ciphertext binding and nonce binding against a key holder. Ciphertext binding holds only when the ciphertext digest is set, so the leaf carries LH(ct_i). LH(ct_i) () is the ciphertext digest, and a fixed transcript binds the ordered leaf list under the collision resistance of the KDF over framed inputs and of LH over the encoded run, so the ciphertext binding rests on the collision resistance of LH for any segment length. Against a fixed published transcript, a substitution needs a second preimage at one of n_seg + 1 targets, the leaves and the run. Every input to LH is public, so this is a collision-resistance requirement, separate from the PRF assumption above, and it does not degrade when the adversary holds the CEK and every key derived from it. Without the ciphertext digest the transcript binds the tags, nonce fields, segment AAD, and order but not the ciphertext content, which suits a single-CEK-holder deployment. The digest transcript is still a symmetric authenticator: any snap_key holder can compute a valid snapshot for an object it writes itself. What a key holder cannot do without a collision is exhibit a different ordered leaf list that verifies under a fixed, already-published transcript value. In random nonce mode the leaf carries the stored nonce, so two nonces give two leaves. A fixed authenticated transcript fixes each index's nonce for every suite, independently of whether the AEAD tag is injective in the nonce. In derived nonce mode the leaf carries the counter (i << 1) | is_final, and the commitment fixes the CEK and payload_info, so the authenticated transcript fixes the nonce through the derivation for a decryptor that verifies the commitment. The digest transcript accepts either nonce mode for ciphertext, nonce, and AAD binding. With the ciphertext digest set, the leaf fixes the ciphertext, the tag, the nonce field, and the segment AAD, A_i included, so the plaintext-binding claims here need no external binding of A_i. The masked multiset hash gives no such binding, in two independent ways. Its contributions bind AEAD tags, and under an adversarially known CEK a non-committing AEAD admits a second ciphertext with the same tag (), so segment content can change under an unchanged accumulator. Separately, its ordering is linear: a party that knows snap_key evaluates contributions offline and solves for a different segment set with the same accumulator by the k-list XOR algorithm of , at about 2^(8*Nh / (1 + floor(log2(n_seg)))) operations over n_seg lists. The floor is there because the k-tree needs a power-of-two list count, so a count between two powers gives the lower one's cost. That cost meets the digest transcript's 2^(4*Nh) ciphertext equivocation floor at n_seg = 2 and drops below it at n_seg = 4. The search needs many candidate contributions at each index, which a CEK holder obtains at unchanged plaintext by re-encrypting under fresh nonces in random nonce mode, or by varying padding in derived nonce mode, so the forged object decrypts to plaintext the CEK holder chose. Above 8*Nh segments two candidates per index suffice: the n_seg differences between them, each 8*Nh bits, are then linearly dependent, and Gaussian elimination finds a set of indices to switch that leaves the accumulator unchanged. Carrying the ciphertext digest in each contribution does not repair this. It does repair the first weakness: a contribution covering LH(ct_i) moves the accumulator whenever the ciphertext changes, so the substitution that was free under a non-committing AEAD now costs the search above. What it cannot do is change that cost, which the accumulator width and the segment count fix, not what each contribution is computed over. A linear authenticator therefore MUST NOT carry the ciphertext digest. Setting it is how an instantiation states that its segments are bound against a CEK holder (), and makes that binding hold under three conditions: the keyed snapshot is authenticated outside the construction, the leaf carries LH(ct_i), and the ordering is strict. A linear ordering fails the third condition, because the k-list search reaches a different segment set without disturbing the first two. The count that sets the search cost belongs to the object rather than to any row, which fixes segment_max and never n_seg. The binding thus weakens as an object grows, passing the digest transcript's ciphertext equivocation floor at four segments. The ordering is settled by snap_id (), so the prohibition binds the registrant of a snap_id rather than a protocol choosing among the ones defined here. The masked multiset hash accordingly folds the AEAD tag alone. Only a non-linear ordering, as the digest transcript and the epoch digest tree use, turns the search into a collision problem and holds the binding at every count. Neither observation weakens the masked multiset hash in its own threat model, which excludes key holders: snap_key is derived from the CEK (), so in a single-owner deployment no adversary holds snap_key. Both matter only when a keyed snapshot is lifted into a stronger statement. That lifting is the signing layer this section requires for sender attribution. A signature or MAC over a keyed snapshot carries content binding against CEK holders only when the underlying value already binds content against key holders. The digest transcript is designed for that use, and its commitment element carries the full object context (CEK, payload_info, and G) into the authenticated value, so a signed value binds one object context. An application MUST NOT rely on a signature over the masked multiset hash's keyed snapshot for content attribution among CEK holders. The ciphertext digest is what grounds content binding on collision resistance. With the ciphertext digest set, an authenticated digest transcript pins each index to one ciphertext, tag, nonce field, and segment AAD, even against a party that holds or chose the CEK, which gives the per-index binding of with its stated gap to ra-CMT-p. The public snapshot () is the same framed derivation with an empty ikm and its own label, so its binding rests on collision and second-preimage resistance alone, with no PRF term, and it is not unforgeable: anyone computes it. In the two-step class the extract step then takes only public inputs, so the output at length Nh is HMAC under a known key over the framed input. An output collision on distinct inputs is then a collision of LH on the run or on an over-large element, or of the inner or the outer hash call. In the one-step class it is a collision of the XOF or of LH. A signed pub_snapshot therefore binds payload_info, the commitment, the count, and the ordered leaf list for a verifier that holds no key, as an authenticated keyed snapshot does for a key holder. The formal forgery and content-binding reductions for the digest transcript are deferred to the combined proof in preparation (), with SEAL's other snapshot proofs.

Epoch Digest Tree The epoch digest tree () has the same per-segment leaf and the same key as the digest transcript, so its ciphertext, nonce, and AAD binding in both modes, and its per-index binding for every suite, with the same gap to ra-CMT-p, are those of . They hold for an intermediate snapshot () too, whose leaves fix is_final = 0 at its last index. The two-level fold rests on the same collision-resistance assumption. An epoch head binds its epoch's leaf run through LH and the KDF, and the snapshot binds the epoch heads the same way, so a forged snapshot requires an LH or KDF collision at one of the two levels or a snap_key PRF forgery at either keyed level. Each leaf carries its index, and the snapshot binds the heads in order and binds n_seg and payload_info, so a head cannot move to another position and the segmentation is fixed by n_seg and epoch_length. Without snap_key, a forgery is one of three events. The first is a fresh-input forgery of a keyed digest, at the root or at an epoch head: the digest transcript's PRF term (), once at each keyed level, with no birthday term in the number of published snapshots. The second is a collision between two heads over different runs at the same epoch, a birthday term in the number of epoch runs folded under snap_key, n_ep plus one for each epoch head a change recomputes and one for each intermediate snapshot produced between epoch boundaries, whose last head is partial, at most about q_h^2 / 2^(8*Nh + 1) for q_h such heads. The header stores the full heads in the clear. A run whose head equals another run's head verifies in its place under an unchanged heads run, as at an earlier version of the same slot. A run formed at another epoch cannot take that place: the verifier forms each leaf with the index of the segment it checks, in the nonce field or the segment AAD (), so this leaf-index binding separates epochs, only pairs of runs at the same epoch count toward the term, and the figure is an upper bound. The third is a second preimage of LH at an epoch run or at the heads run, a multi-target term over the n_ep epoch runs and the heads run under each published snapshot, since a different run with the same digest leaves every keyed value above it unchanged. Against a key holder, and where the ciphertext digest is set, substituting ciphertext bytes under a fixed published snapshot requires an LH or KDF collision against that fixed target, a second preimage, at one of three target classes: the n_seg leaves shared with the digest transcript, the n_ep epoch heads, and the single root. The work factor is 2^(8*Nh) per target for an ideal hash, or 2^(c/2) for a sponge of capacity c, 2^256 for TurboSHAKE-256 at Nh = 64, with a benign multiplicity of n_seg + n_ep + 1. The two fold levels thus add epoch and root targets to the transcript's leaf targets without lowering the per-target strength. When LH is HMAC over a Merkle-Damgard hash whose chaining value is Nh octets, SHA-256 and SHA-512, a long-message second preimage lowers the work to about 2^(8*Nh) divided by the total number of compression blocks across the targets. SHA-384's 64-octet chaining value leaves the generic figure in force below 2^128 blocks. A writer that chooses different ciphertext or leaf lists for both openings of one snapshot instead faces a birthday collision at 2^(4*Nh), the same ciphertext equivocation floor as the digest transcript, which the fold does not lower. The public snapshot's two levels bind as the keyed levels do, by the collision resistance of LH and of the KDF under a public key (), with no PRF term. Every party is then in the key holder's position above: a different leaf list or count under a fixed, authenticated pub_snapshot needs a second preimage at a leaf, a public head, or the root, and a signer that wants two openings of one value faces the birthday collision at 2^(4*Nh). A substituted witness head leaves the recomputed pub_snapshot unchanged only through a collision at the root. The LH digests at every level are unkeyed and shared by every object, for the keyed value as for the public one, so the accounting is aggregate over objects, epochs, intermediate snapshots, and internal digests. The commitment and payload_info in each head, and the leaf indices in each run, separate only the heads themselves, for both values, and the long-message and sponge figures above apply to the public runs as to the keyed ones. Changing a nonce field or a segment AAD changes the leaf, so the authenticated snapshot fixes both, and per-index binding holds in both nonce modes for every suite under the conditions of . The formal two-level reduction, the fresh-input forgery term at either keyed level and the LH and KDF terms at the epoch and root levels, is deferred to the combined proof in preparation (), with the digest transcript's. This authenticator's verify_segment compares recomputed values against stored ones at three levels, the snapshot, the epoch head, and the leaf, and MUST use a constant-time octet comparison at each. The stored value compared against at each level is public metadata, and snap_key enters only through the KDF, whose constant-time requirement is in , so no comparison carries a secret. Because the reference operands are public, the fused single-comparison rule of the masked multiset hash () does not apply: a per-level early return reveals only which stored region a tampering party altered, which that party already knows, and leaks no keyed value.

SEAL Named Instantiations SEAL has many parameters (). A relying protocol that does not want to choose them all can cite one of the named instantiations in the table below. Each row fixes a profile, a segment size, the nonce mode, a snapshot authenticator, and one of the serialization layouts of , leaving the cipher suite (an aead_id and a kdf_id from ) to the referencing protocol. Each instantiation applies to a cipher suite the same way, so a protocol writes SEAL-simple(aead_id, kdf_id), SEAL-disk(aead_id, kdf_id), and so on, to obtain a complete raAE scheme. SEAL named instantiations

instantiation_id	Name	Profile	segment_max	nonce_mode	epoch	snap_id	layout	ciphertext digest
0x0001	SEAL-simple	SEAL-RO-v1	65536	derived	32	0x0000	linear	no
0x0002	SEAL-attachment	SEAL-RO-v1	65536	derived	10	0x0003	aligned	yes
0x0003	SEAL-attachment-small	SEAL-RO-v1	65536	derived	10	0x0002	aligned	yes
0x0004	SEAL-editable	SEAL-RW-v1	65536	random	16	0x0001	linear	no
0x0005	SEAL-memory	SEAL-RW-v1	16384	random	16	0x0001	aligned	no
0x0006	SEAL-disk	SEAL-RW-v1	16384	random	16	0x0001	split	no
0x0007	SEAL-compact	SEAL-RW-v1	16384	derived	16	0x0001	aligned	no
0x0008	SEAL-log	SEAL-AO-v1	16384	derived	16	0x0000	append-log	no

The instantiation_id column is a uint16 code point naming the instantiation as a whole. No field defined in this document carries an instantiation_id. An instantiation is cited by name, and its parameters reach the key schedule individually through payload_info (), which carries aead_id, kdf_id and snap_id but nothing identifying the instantiation they came from. The code point exists so that a protocol negotiating an instantiation need not mint an identifier of its own. The snap_id column selects the snapshot authenticator within the profile's admitted set (). The ciphertext digest column is a payload_info choice independent of snap_id (), and each instantiation pins it: the attachment instantiations set it, over their strict authenticators, and the others do not. Every instantiation uses commitment_length = Nh, a fresh 32-octet salt per object, and the epoch_length in its row (): 32 for the whole-file SEAL-simple, 10 for both SEAL-attachment rows, and 16 for the mutable rows and SEAL-log, a conservative value. The mutable rows spend that per-epoch-key headroom on rewrites. SEAL-log rewrites a segment only by its one re-mark, so its 16 bounds how many segments share an epoch key, plus the one extra derived nonce each re-mark draws. The two SEAL-attachment rows spend their 10 differently. SEAL-attachment selects the epoch digest tree, which reuses epoch_length as its grouping fan-out (), so 10 is the value. SEAL-attachment-small selects the flat digest transcript, which has no grouping, so there 10 is key rotation alone. A row's epoch_length is a choice, so the cipher suite's default epoch_length () does not apply to a named instantiation. That default fills a gap where no value is chosen, so the row's value stands even under a 256-bit-nonce suite, whose nonce size would otherwise make a flat key the natural pick. A referencing protocol MAY override the row's value. Because a row fixes epoch_length while leaving the KDF open, a suite with Nh = 64 puts SEAL-attachment outside the guidance, which gives 9 there rather than 10: 2^10 * (Nh + Nt) is 81920, above the 65536 segment_max. The epoch digest tree stays correct, and an epoch head then costs two aligned reads rather than one. A protocol that wants the single read back pairs SEAL-attachment with an Nh of 32 or 48, or sets epoch_length to 9. The consuming protocol pins the remaining serialization details for byte-level interoperability (). SEAL-simple is for write-once content read whole: no snapshot authenticator, in the reduced immutable linear layout (). SEAL-attachment is for write-once content whose segments a reader verifies or decrypts individually. It requires the epoch digest tree (snap_id 0x0003), and an object under SEAL-attachment MUST carry its keyed snapshot. Its aligned layout () lets a reader verify one segment in two aligned metadata reads plus the segment itself, without reading the others when the epoch's A_i are empty or at hand, for objects up to about 128 GiB at the recommended parameters (). SEAL-attachment-small is the same for small write-once content, using the flat digest transcript (snap_id 0x0002) instead of the epoch digest tree: the reader checks one segment against the full leaf list rather than one epoch's run, a fit when the leaf list is one read anyway or the consumer verifies every segment on the way through. SEAL-editable is the basic mutable object with whole-object integrity from the masked multiset hash (), stored in the linear layout (). SEAL-memory targets in-memory random access with the aligned layout (). SEAL-disk rewrites individual segments on stored media, with the split layout () holding the headers apart from the segment data so a rewrite touches one segment and extension appends to both streams. SEAL-compact is random-access mutable in the aligned layout with a derived nonce, recomputed rather than stored: each per-segment metadata entry is Nt octets instead of Nn + Nt (), saving Nn octets per segment across the large objects the aligned layout targets. The in-place rewrite reuses that nonce, so it requires an MRAE AEAD and is deterministic. For the same reason the writer takes every tag an update removes, in a rewrite, a re-mark, or a truncation, from locally trusted state or recomputes the snapshot from every tag (). SEAL-log is for a growing archive or log, appended and read in order. It selects the append-only profile SEAL-AO-v1 with a derived nonce and the append-log layout (), which stores each ciphertext length so the segment left short by a re-mark can be an interior one. It selects a null snapshot, so integrity is per-segment: a reader authenticates each segment at its index, but the current segment set is not bound, and truncation or rollback to an earlier honest length is out of scope, for which a consuming protocol supplies freshness (). As under every snap_id, the stored log gives an appender no current count, so a SEAL-log writer keeps its own count or obtains a fresh one before it appends ().

Binding Limits for Profiled Suites For each suite and nonce mode it lists, the table identifies the binding usage-limit class of . Numerical entries are single-key, single-term figures at 2^-32, except the AES-GCM random-nonce budget, which AES-GCM's own specification caps at 2^32 encryptions per key, here the epoch key, rewrites included ( Section 8.3). All are subject to the AEAD's full analysis and are not aggregate allowances (). Binding limits for profiled suites, length-dependent figures at 64 KiB

Suite / mode	Binding limit	Budget	Failure mode
AES-128-GCM, random	random-nonce collision	at most 2^32 per epoch key (specification cap)	confidentiality and integrity
AES-256-GCM, random	random-nonce collision	at most 2^32 per epoch key (specification cap)	confidentiality and integrity
ChaCha20-Poly1305, random	random-nonce collision	~2^32 per epoch key	confidentiality and integrity
AES-256-GCM-SIV, derived, distinct segments	derived-nonce MRAE workload	workload-dependent multi-user bound	confidentiality and integrity
AES-256-GCM-SIV, derived, hot segment	derived-nonce MRAE workload	workload-dependent multi-user bound	confidentiality and integrity
AEGIS-256, random	forgery bound	~2^83 forgery attempts per key	integrity
AEGIS-256X2, random	forgery bound	~2^83 forgery attempts per key	integrity

The random-nonce counts depend on nonce size. Data-volume and forgery limits also depend on segment length and effective associated data, under the full block accounting of the applicable AEAD analysis. AEGIS makes nonce collision negligible with a 256-bit nonce (~2^112) and binds on forgery. For AES-256-GCM-SIV, the data-volume term couples total processed blocks across all keys and nonces to the maximum encryption blocks at any one (key, nonce) pair ().

Write Limits by Instantiation Once a named instantiation () fixes the segment size, the nonce mode, and the epoch_length, the classes above determine how a deployment computes its write limits. The table below gives per-key random-nonce illustrations; an aggregate target can bind sooner. Epoch rotation leaves the structural ceiling at 2^63 segments (about 2^79 octets at segment_max 65536, 2^77 at 16384), but does not guarantee that the aggregate security budget permits reaching it. Initial writes and rewrites both consume that budget (). For a random-nonce suite the epoch key holds one shared nonce-collision pool of about 2^32 segment encryptions (). Rewriting a single hot segment while the rest stay put can spend most of that pool on the one segment, so its ceiling is about 2^32. When the 2^epoch_length segments under the key are rewritten evenly the pool divides among them, so each takes about 2^(32 - epoch_length) on average: this is the bound in force when the epoch key, not a single segment, is the limiting factor. These are per-key nonce-collision figures: K equally busy epoch keys divide the same aggregate allocation by K, reducing both rewrite figures by sqrt(K). For AES-256-GCM-SIV the hot and average limits depend on the full workload (). For the data-volume term alone, H equally busy (key, nonce) pairs reduce the per-pair count by sqrt(H) relative to one isolated hot pair. Rewriting every non-terminal segment in a full epoch uses about 2^epoch_length pairs, so at epoch_length 16 this scaling reduces the average by about 2^8. Other epochs, objects, and initial writes also enter the aggregate bound. Qualified segment rewrite limits

Instantiation	Segment size	Rewrites per hot segment	Avg rewrites per segment
SEAL-simple	64 KiB	write-once	write-once
SEAL-attachment	64 KiB	write-once	write-once
SEAL-attachment-small	64 KiB	write-once	write-once
SEAL-editable	64 KiB	~2^32	~2^16
SEAL-memory	16 KiB	~2^32	~2^16
SEAL-disk	16 KiB	~2^32	~2^16
SEAL-compact	16 KiB	workload-dependent	workload-dependent
SEAL-log	16 KiB	one re-mark	one re-mark

The figures are for the 96-bit-nonce suites (AES-GCM, ChaCha20-Poly1305) at the epoch_length 16 these instantiations fix; a smaller epoch_length raises the average. They follow from the 12-octet random nonce, not from the AEAD's key, tag, or block size: at these segment sizes random-nonce collision binds before the block-size term (), so any 96-bit-nonce suite gives the same figures. For AES-GCM its specification cap () gives the same figures as ceilings. Two cases depart from them. An AEGIS suite binds on the forgery bound, which counts verification attempts rather than rewrites. A derived-nonce MRAE suite (AES-256-GCM-SIV, as SEAL-compact takes) uses the coupled multi-user bound, and absent an allocation the per-object rule of sets its limit. SEAL-log rewrites a segment only by its one re-mark, under a new nonce, since SEAL-AO-v1 derives a fresh nonce for each index and finality bit. In random nonce mode a repeated nonce under AES-GCM or ChaCha20-Poly1305 also exposes an authentication key (), so for those suites the collision term counts against integrity as well. The per-query forgery term counts verification attempts. Its limits come from for the GCM and ChaCha20-Poly1305 suites and for AES-256-GCM-SIV, and run from about 2^59 to 2^83 forgery attempts at a single-key, forgery-term 2^-32 target. Under AES-256-GCM-SIV an attempt's blocks also enter the coupled data-volume term, which charges each attempt about C * B / 2^128 for every block it processes, with B the largest encryption load at any one pair (). The AEGIS analysis states at least 128-bit forgery security with no per-query formula, so the AEGIS rows take the AES-GCM figure of about 2^83 as a conservative floor. Aggregate integrity accounting counts all attempts across keys and includes the AEAD's further terms ().

Streaming with Prefix Verification This section is informative. A live publisher that holds the CEK streams segments to many subscribers that also hold it, through relays that do not. No layout of holds an epoch digest tree object while it is open: the append-log layout admits no snapshot authenticator, and the others need the final count to size the header. The consuming protocol therefore frames the object's payload_info and commitment, the segments, each as its ciphertext, metadata entry, and any A_i, and the values. That framing, the signing key, and the cadence belong to the consuming protocol. The configuration is the epoch digest tree (), in either nonce mode, with epoch_length chosen so that 2^r segments span the interval at which a subscriber may join. The consuming protocol sets the playback window, the delay a reader accepts between playing a segment and verifying it. The publisher follows the writer discipline of . At each epoch boundary, and at the count k that ends each playback window, it publishes, in the consuming protocol's framing, the keyed value snapshot(k) for subscribers and pub_snapshot(k), in the signed statement of , for relays and for subscribers that need its origin, and it keeps the full heads available to late joiners. A subscriber plays the segments of the current window on per-segment authenticity alone, treats that content as not yet verified, and checks snapshot(k) at each published count as the in-order reader of does. On rejection it stops and reports, and it cannot recall what it has already played. A subscriber that joins late continues from the latest boundary as describes for a reader that joins at k. A relay holds no CEK. It verifies the signed statement and recomputes pub_snapshot(k) from the leaves of the segments it forwards and their A_i (). Beyond the limits states, the values establish neither of the following, and a consuming protocol that needs either provides it itself:

• Withholding or delay of segments or values. The reader cannot tell one from the other. The consuming protocol sets cadence and timeouts.
• Content played before a check that later fails.

Security Considerations The security analysis of SEAL is in the companion (): the ra-ROR joint confidentiality and authenticity target, the ra-CMT commitment target, the reduction to the underlying AEAD and KDF, and the concrete bounds and budgets. This document adds the per-authenticator forgery analysis () and the profiled limits (). With the ciphertext digest set and an externally authenticated snapshot, the strict authenticators give per-index binding in both nonce modes for every suite, for any A_i (, ). The leaf carries the stored nonce in random nonce mode, the counter in derived nonce mode, and the segment AAD in both. This does not establish ra-CMT-p. Public snapshots (, ) authenticate nothing on their own. A verifier accepts one only under the signed statement requires, parses under the payload_info parameters it carries, and enforces the witness length. Public acceptance binds ciphertext through the ciphertext digest that requires wherever a public snapshot is relied on, and establishes neither decryption nor any link between the commitment and a CEK. Keyed and public acceptance are independent, so a key holder that claims the signer's origin checks both. Public binding rests on collision and second-preimage resistance alone (), with the accounting aggregated over objects, epochs, intermediate snapshots, and internal digests (), and a public snapshot is not hiding. An intermediate snapshot authenticates a prefix only: completion needs a signed statement marking the value final and, for a decryptor, the terminal segment verifying as final. A signature prevents neither replay nor withholding nor equivocation, and a consuming protocol states the freshness and consistency it claims. The masked multiset hash defines no public snapshot and no intermediate snapshot. The salt is public object metadata. Confidentiality and integrity in the single-owner regime assume secrecy of the CEK and derived keys, not secrecy of the salt. The companion's KDF assumptions () instantiate on the named suites as follows. For the HKDF-based suites, the PRF assumptions are placed on HKDF keyed by the CEK, payload_key, snap_key, or, under hedged randomness, sk and hedge_key, and the collision-resistance assumption on the commit derivation reduces to the collision resistance of the underlying SHA-2 hash. Because every SEAL KDF output is at most Nh octets, HKDF-Expand makes a single HMAC call per derivation, and Section 5 of refers to the published analysis of HKDF. For TurboSHAKE-256 (), the same assumptions are placed on the XOF as instantiated by its HPKE KDF registry entry, which fixes the primitive and its parameters but carries no security assumptions of its own. A private-use snap_id carries a specific hazard. snap_id is a payload_info member (), so two deployments that assign the same private value to different authenticators agree on payload_info and derive the same commitment, payload_key, and snap_key. The commitment catches a wrong parameter context () and precedes a reader's SnapVerify, so the check that would have caught the mismatch passes, and whatever rejects the object later reports some other reason rather than the collision.

Resource Exhaustion The resource-exhaustion considerations of apply. The layouts add to them: the per-segment metadata and aux regions grow with segment or epoch counts, so consuming protocols MUST also limit metadata and aux sizes, and the leaf lists and witness heads they carry for public verification (). The overflow and bounds checks the companion requires cover, in these layouts, multiplication by segment_max or metadata entry sizes and addition of header and aux lengths. Append-log ciphertext lengths MUST be checked against segment_max, and the ciphertext plus metadata MUST fit within the available input before reading a record.

IANA Considerations The aead_id and kdf_id code points that SEAL cipher suites use are existing entries in the IANA AEAD Algorithms registry () and the HPKE KDF registry (). This document does not modify either registry. This document requests two new registries. Both use uint16 code points, and both apply Specification Required () to 0x0000 through 0xFEFF, reserving 0xFF00 through 0xFFFF for private and experimental use. The reservation carries different weight in each. A private-use snap_id reaches the key schedule, so it needs the rule stated below. A private-use instantiation_id reaches nothing this document defines, and is reserved so that a protocol which does put one on its own wire has a range that no future registration will collide with. The first is "SEAL Named Instantiations". An entry fixes a profile, a maximum segment size, a nonce mode, an epoch length, a snapshot authenticator, a serialization layout, and a ciphertext-digest setting, and leaves the cipher suite to the referencing protocol (). The registry has the columns of , namely instantiation_id, Name, Profile, segment_max, nonce_mode, epoch, snap_id, layout, and ciphertext digest, plus a Reference column. Its initial contents are the entries of , each referencing this document. The second is "SEAL Snapshot Authenticators", which assigns the snap_id values named in . Its columns are snap_id, Name, Na, ordering, summary, and Reference, so it records more than that table does. Na is the authenticator's keyed snapshot length. A summary is any state an authenticator derives from the per-segment inputs and keeps so that an update reads fewer of them, and it enables no function that recomputing from the inputs would not. The ordering column records whether a party holding snap_key can find a second segment set with the same keyed snapshot below the cost of a collision: linear if the construction offers a route below that cost, for example by linear algebra or by a generalized birthday search, strict if finding one is a collision problem, and n/a for an authenticator that produces no keyed snapshot. The analysis behind each value is in . The ordering also decides whether the authenticator has a public snapshot and intermediate snapshots (). The value a registrant chooses here settles the ciphertext-digest prohibition of , without this document naming the authenticator. Where Na or summary holds a size rather than a constant, it holds it as an expression: Nh is fixed by the cipher suite the referencing protocol picks, and n_ep varies per object. The authenticator's construction fixes the form, which is what the registry records. Each authenticator's summary, when it has one, is stored in the aux region of the layouts (), so Na is Nh under every authenticator here that produces a keyed snapshot. The initial contents are: Initial SEAL Snapshot Authenticators registry

snap_id	Name	Na	ordering	summary	Reference
0x0000	none	0	n/a	none	This document
0x0001	masked multiset hash	Nh	linear	accumulator, masked	This document
0x0002	digest transcript	Nh	strict	none	This document
0x0003	epoch digest tree	Nh	strict	n_ep * Nh epoch heads	This document

The ordering column is unrelated to the linear serialization layout of , which names a way of arranging bytes rather than a way of combining inputs. A private-use snap_id is not interoperable and MUST NOT appear in an object intended for exchange (). The following code points are drawn from IANA registries. AEGIS-256 (0x0021) and AEGIS-256X2 (0x0024) are already registered in the AEAD Algorithms registry per . TurboSHAKE-256 (0x0013) is registered in the HPKE KDF registry with as its reference, which becomes an RFC reference when that draft publishes. The SEAL normative reference to is a reference to a work in progress, so publication of this document waits on it. Registered Code Points

Registry	Code point	Algorithm	Status
AEAD Algorithms	0x0021	AEGIS-256	assigned
AEAD Algorithms	0x0024	AEGIS-256X2	assigned
HPKE KDF	0x0013	TurboSHAKE-256	assigned, draft reference

Future SEAL profiles MAY consume additional entries from the AEAD Algorithms and HPKE KDF registries without revising this document.

Designated Expert Review For both registries, designated experts review new registrations and changes to existing entries under the Specification Required policy of . Experts MUST require a stable, publicly available specification that defines every registry field unambiguously and is sufficient for independent interoperable implementations. A changed definition is a new registration under a new code point and, for an instantiation, a new name. For named instantiations, experts MUST check that the profile, segment size, nonce mode, epoch length, snap_id, layout, and ciphertext digest form a valid combination. For snapshot authenticators, the specification MUST define:

• the complete input encoding,
• snapshot computation and verification,
• supported update operations, each with the witness it takes, how the writer checks that witness, and any removed input that may be used without a check;
• any subset verification or summary state; and,
• where its ordering is strict, it MUST define its public snapshot and its intermediate snapshots ().

Experts MUST independently assess the requested ordering classification using the ordering definition of and . The analysis MUST consider an adversary holding snap_key and choosing both segment sets. Experts MUST reject a requested strict classification whose analysis does not justify it, and MUST check the resulting ciphertext-digest restrictions in .

References Normative References 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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide. This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption with associated data (AEAD) algorithms designed for high-performance applications. It also specifies their use as stream ciphers and message authentication codes (MACs). The document is a product of the Crypto Forum Research Group (CFRG). Cisco Selkie Cryptography Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. 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. Informative References 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. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

SEAL-simple Implementation Sketch This appendix is informative. It specializes for SEAL-simple (). Fixed parameters for SEAL-simple(HKDF-SHA-256, AES-256-GCM)

Field	Value
protocol_id	"SEAL-RO-v1"
aead_id	0x0002 (AES-256-GCM)
kdf_id	0x0001 (HKDF-SHA-256)
snap_id	0x0000 (no snapshot authenticator)
nonce_mode	0x01 (derived)
epoch_length	32
segment_max	65536
Nk	32
Nn	12
Nt	16
Nh	32
commitment_length	32
layout	linear, immutable reduction ()

Per-segment associated data A_i is empty throughout this sketch, and a caller that needs a non-empty A_i follows the general segment-AAD form defined in . Three separate quantities bound how large an object under this profile can grow. At an aggregate 2^-32 target the confidentiality term binds first, at no more than about 2^57 octets.

• Integrity: 512 ZiB (2^79 octets) of ciphertext has total forgery probability at most ~2^-52, from the AES-256-GCM tag-forgery formula 2 x v x (n_blk + 1) / 2^128 at v = 2^63 segments and n_blk = 2^12 blocks per segment ().
• Confidentiality: with epoch_length 32, each full epoch encrypts 2^32 segments of 2^12 blocks. The companion's block-size bound gives about 2^-41 per epoch key. Summing over all 2^31 keys at the structural ceiling gives about 2^-10 for this term, exceeding an aggregate 2^-32 target. Allocating 2^-32 to this term alone permits about 2^41 segments (2^57 octets) at this epoch_length; the full target also reserves advantage for the other terms ().
• Structural: 512 ZiB (2^79 octets) is the object ceiling, from derived-nonce framing capping the segment index at 2^63 across up to 2^31 epoch keys ().

The two blocks below use the linear layout () and apply to either suite: aead_id, kdf_id, commitment_length, Nk, Nn, and the AEAD are read from the chosen suite's parameter table, and the rest is common to both. Each KDF(...) call is that suite's KDF combiner of (two-step for HKDF, one-step for the XOF), evaluated at protocol_id = "SEAL-RO-v1" with the derivation label as its leading argument. The salt draw, nonce derivation, and finality check follow the companion's procedures (). Encryption derives the message schedule once, then seals each segment under its epoch key and derived nonce:

SEAL-simple encryption > 32 ;; epoch_length = 32 segment_key = KDF("epoch_key", [payload_key], [uint64(epoch_index)], Nk) counter = uint64((i << 1) | is_final) nonce(i) = nonce_base[0:Nn-8] || (nonce_base[Nn-8:Nn] XOR counter) (ct_i || tag_i) = AEAD.Seal(segment_key, nonce(i), "", P_i) stored_object = salt || commitment || (ct_0 || tag_0) || (ct_1 || tag_1) || ... || (ct_{n-1} || tag_{n-1}) ]]>

Decryption recomputes the same schedule, checks the commitment to reject a wrong key early, then opens each segment. Every non-final ct_i is exactly 65536 octets and only the final ct_i may be shorter.

SEAL-simple decryption

The reader must reject the object if segment n-1 did not open under is_final = 1. The general algorithm's snap_key derivation is not used at snap_id = 0x0000 and an implementer of this profile omits it. See for the corresponding byte-level test vector. A conforming implementation reproduces its commitment, payload_key, and nonce_base, and the per-segment nonce, ciphertext, and tag, from the fixed inputs.

A Modern CFRG Suite The same instantiation admits SEAL-simple(TurboSHAKE-256, AEGIS-256), reusing existing code points (aead_id = 0x0021, kdf_id = 0x0013) with no new registrations. Fixed parameters for SEAL-simple(TurboSHAKE-256, AEGIS-256)

Field	Value
protocol_id	"SEAL-RO-v1"
aead_id	0x0021 (AEGIS-256)
kdf_id	0x0013 (TurboSHAKE-256)
snap_id	0x0000 (no snapshot authenticator)
nonce_mode	0x01 (derived)
epoch_length	32
segment_max	65536
Nk	32
Nn	32
Nt	16
Nh	64
commitment_length	64
layout	linear, immutable reduction ()

The encrypt and decrypt blocks above instantiate from this table. A 256-bit nonce under derived mode is sound because SEAL-RO-v1 never re-encrypts a position, so the non-MRAE AEAD carries no fixed-nonce reuse. The integrity budget is the AEGIS-256 row of , in place of the AES-256-GCM tag-forgery formula: about 2^83 forgery attempts in total across the object's epoch keys at a 2^-32 forgery term, independent of nonce mode. The one-step TurboSHAKE-256 derivations are exercised by the component vectors in .

Snapshot Authenticator Reduction SEAL's masked multiset hash is the MSet-XOR-Hash of Clarke et al. () with a deterministic mask this document adds. Each segment contributes a keyed KDF evaluation of its index and tag, the contributions XOR into an accumulator, and the published value masks that accumulator under snap_key. A different authenticator that meets the requirement of carries its own argument. The adversary has full read and write access to the stored segments, their metadata, the aux region, and the snapshot, and wins when SnapVerify accepts presented segments whose (index, input) set or count differs from the state the writer recorded under the presented snapshot. A segment's bytes outside its input, such as its stored nonce in random nonce mode under the masked multiset hash, are bound by its AEAD tag instead: a set that changes only those bytes passes SnapVerify and fails AEAD decryption. Whole-object rollback to an earlier honest state is excluded and is the application's freshness responsibility (). The game has no writer oracle. A writer's check passes on altered input with probability about 2^-(8*Nh) per check (). A game with a writer oracle and a win condition over the writer's intended state is deferred to . Publishing the accumulator in the clear would be insecure. That is the MSet-XOR-Hash with its mask removed, which is only set-collision resistant. A write adversary reads the accumulator across honest rewrites, collects the contribution differences old_contrib XOR new_contrib, and after more than 8*Nh of them solves a GF(2) system for a subset of segments it can revert without changing the accumulator. The current snapshot still verifies, so a non-historical mixture of versions is accepted with no MAC forgery. The deterministic mask defeats this attack. Here wrapped_acc = acc XOR acc_mask(n_seg, snapshot) hides the accumulator behind a one-time pad keyed by snap_key and seeded by the snapshot, the synthetic-IV derandomization of deterministic authenticated encryption (). Two published states that collide on (n_seg, acc), or on the snapshot at equal count, would expose a raw accumulator difference. Over q_s published states that costs a birthday term q_s^2 / 2^m, with m = 8*Nh. Off that event the masks are independent one-time pads, the published transcript is independent of every accumulator, and the recombination above has no linear system left to solve. Security reduces to the PRF security of the KDF. The mask protects the accumulator only against a verifier that returns one bit, which is why neither SnapVerify nor the writer surfaces an unmasked accumulator (). A forgery is then one of two events. Either a fresh snapshot-tag input is guessed, a MAC forgery bounded by q_v / 2^m over q_v verifications, or a different segment set is made to hit a published accumulator by chance, a mix-and-match bounded by q_s * q_v / 2^m against q_s published states. The mix-and-match term is a set collision on the keyed contribution function and relies on the set-collision resistance of the MSet-XOR-Hash-style construction (). The formal bound for this term is discharged in . Collecting the terms, the snapshot forgery advantage Adv_snap of is with m = 8*Nh and dominant terms q_s^2 / 2^m and q_s * q_v / 2^m, both negligible at Nh of 32, 48, or 64. The mu-PRF cost of the snap_key derivations is not part of Adv_snap: the master bound charges it in its Level B PRF hop (). The argument relies on segment AEAD authenticity, already charged as Adv_muROR$ (), and adds no term beyond Adv_snap. That charge holds within the master bound's scope, which does not yet cover re-encrypting a position in either nonce mode. The SEAL-RW-v1 rows of re-encrypt positions on a rewrite, and their length changes do when they revisit a pair. Per-object separation comes from the salt-bound snap_key, and the authenticator needs no assumption beyond the multi-user PRF the key schedule already uses. It does not need the commitment's collision resistance. Integrating this reduction into the combined ra-ROR proof is in preparation ().

Snapshot Authenticator Design Rationale Three shapes were considered for whole-object integrity over an updatable segment set. A MAC over the concatenated tag list is the simplest, but a rewrite changes one tag in the middle of the input, so the writer recomputes over all n_seg tags on every update. A Merkle tree over the tags updates in O(log n) and can offer per-segment inclusion proofs, but it either stores interior nodes that grow with the object or re-reads segment tags to rebuild paths, and it rests on collision resistance of a hash. The masked multiset hash updates in O(1) per rewrite where the old tag needs no check or comes from trusted state, stores Nh octets of keyed snapshot plus an Nh-octet aux summary regardless of object size, needs no per-segment proofs, and needs only the multi-user PRF assumption the key schedule already carries. Its costs are the ones this document states explicitly: the accumulator stays masked, the verifier returns a single bit (), and the deterministic mask adds the q_s^2 birthday term to the bound (). A profile that needs per-segment inclusion proofs or third-party verifiability needs a strict authenticator, such as the epoch digest tree with its public snapshot (), rather than the masked multiset hash. The masked accumulator is stored in the aux region so a writer that holds a verified snapshot from locally trusted storage or from authentication outside the construction that carries external freshness, but not the accumulator, can resume the O(1) update from it after the check of , rather than holding the accumulator in trusted state or re-reading every tag. Outside the two exempt cases of a removed tag still needs trusted state or that re-read: under a derived nonce, except in a SEAL-AO-v1 re-mark, and once the random nonce source can repeat. Storing the accumulator is why the mask and the one-bit verifier are needed: an exposed accumulator would let a write adversary recombine observed values (). The digest transcript verifies one segment only by recomputing over every leaf, so a reader of one segment in a large object still reads the whole leaf list. In random nonce mode the list includes Np additional octets per segment for the stored nonces. The epoch digest tree () folds the leaves into per-epoch heads and the heads into the snapshot, so a reader verifies one segment from two aligned metadata reads: the target epoch's leaf run and the list of epoch heads. Each fits one segment_max read within the parameter-dependent ceiling of . That is the cost it saves the digest transcript on large content read at random. The epoch digest tree has two levels but is not a Merkle tree. Verification reconstructs an inclusion proof for a segment, recomputing its leaf, then its epoch head from the epoch's leaves, then the root from the epoch heads, rather than transmitting a compact authentication path. Recomputing an epoch head reads the epoch's leaf run as one contiguous aligned read, while a Merkle authentication path would read a logarithmic set of scattered sibling nodes. On the aligned layout, where a reader seeks in segment-sized units, one contiguous aligned read beats a scattered logarithmic path whenever the run fits one read. The same holds one level up for the list of epoch heads. The two random-access reads trade off against epoch_length. The epoch leaf run, 2^r * meta_len, grows with r and by Np octets per segment in random nonce mode, while the epoch-heads region, ceil(n_seg / 2^r) * Nh, shrinks with r as the epochs get fewer and larger. The largest r that keeps the leaf run within one aligned read therefore also makes the epoch-heads region as small as it can be, which pushes the content-size ceiling as high as it goes. At that point the two reads are each about one aligned read, so neither dominates. The rule in selects that balance point. The list of epoch heads is n_ep * Nh octets and stays one aligned read up to a content-size ceiling: about 2 GiB at segment_max 16384 and about 128 GiB at 65536 for derived nonce mode with Nh = 32 and the recommended epoch_length. In random nonce mode the larger leaf run may require a smaller epoch_length and reduce that ceiling. The ceiling is a read-efficiency threshold, not a size limit. Past it the head list spans a few aligned reads and grows slowly, and the ceiling scales about cubically with segment_max, so a larger segment size moves it far out at the cost of coarser random-access granularity. A tree over the epoch heads would keep a single bounded read at any size but is out of scope. The two-read regime already covers the write-once content this authenticator targets.

Test Vectors This appendix is informative. All vectors printed in this appendix use protocol_id = "SEAL-RW-v1" except , and , which use "SEAL-RO-v1". Every object-schedule vector uses CEK = 32 octets of 0xAA and salt = 32 octets of 0x04. The combiner vectors specify their own inputs. Each end-to-end block opens with its parameter set, grouped into three buckets: the cipher suite (aead_id, kdf_id), the geometry (segment_max), and the operational parameters (epoch_length, nonce_mode, snap_id). aead_id and kdf_id are the 2-octet IANA code points from and . Then come the payload_info elements as encoded on the wire, the payload schedule outputs, the per-segment values, and the snapshot fields. Hexadecimal values wrap at 16 octets per line. The snapshot fields shown are the accumulator acc and the keyed snapshot snap_acc. The stored aux summary wrapped_acc = acc XOR acc_mask(n_seg, snap_acc) follows from acc and is not shown per block (). acc is an intermediate value, not on the wire, and the count is recovered from the segment set. Single-segment plaintexts are "Hello, SEAL!" (12 octets). Two-segment messages append "Two segments of SEAL" (20 octets) as the final segment. Most vectors use nonce_mode "random" with stored nonces repeated to the AEAD nonce length: 0x03 and 0x07 for the 12-octet suites, 0x05 and 0x09 for AEGIS-256, and 0x0b for the rewrite's new nonce. The derived-nonce vector in instead recomputes each nonce from nonce_base, and the cross-epoch vector in sets epoch_length 0. Every end-to-end vector exposes the intermediate epoch_key and segment_key per segment. gives the full KDF trace for one commitment. The other end-to-end blocks list schedule outputs only. raae-v1-vectors.json in the draft repository holds 22 entries: the eighteen end-to-end vectors and the SEAL-simple vector of this appendix, the negative SnapVerify vector of , and two append-only vectors that this appendix does not print. Where this appendix prints an entry of that file, the values match byte for byte. The combiner vectors () exercise encode() injectivity in isolation, including the empty-sequence and same-octets-different-grouping cases, and the 38 of them are published as raae-v1-combiner-kdf-vectors.json. The AEGIS-256 blocks exercise the flat key at epoch_length = 63, the opposite endpoint to . No end-to-end vector reaches the plaintext-bound nonce construction, whose component values exposes. Every printed vector uses an empty A_i except . The SEAL-AO-v1.append.aad entry of raae-v1-vectors.json, which this appendix does not print, uses a non-empty A_i on its re-marked segment, and an empty A_i is omitted from the encoding rather than encoded as a zero-length element (). is a negative vector: it tampers a stored segment tag without recomputing the snapshot, and SnapVerify rejects it.

Single Segment, AES-256-GCM, HKDF-SHA-256, 16384

Commitment with Global Associated Data These vectors pin the G input () against the schedule of : the same CEK, salt, and payload_info with G at its empty default and at a nonempty value. The default case equals the commitment, since every commitment includes the G element. These values are printed here only and are not part of the end-to-end corpus.

KDF Combiner Vectors These vectors exercise the KDF combiner () in isolation. They demonstrate that encode() is injective over (protocol_id, label, ikm, info, L): distinct inputs, including inputs whose octets concatenate to the same string under a different grouping, have distinct framed inputs, subject to the digest-collision qualification for over-large fields in the raAE draft. KDF output pseudorandomness is a separate property; distinct framed inputs can produce colliding outputs. The full set of 38 combiner vectors, covering both KDF classes and seven of the SEAL labels, is published byte-for-byte as raae-v1-combiner-kdf-vectors.json in the draft repository. All blocks below use ikm equal to a single 32-octet element of 0xAA. Hexadecimal values wrap at 16 octets per line. The first pair frames the same five info octets 01 02 03 04 05 two ways. The two expand_info values differ because encode length-prefixes each element; the vector outputs also differ. The second pair shows that the empty sequence and a one-element sequence whose element is the empty octet string are distinct. The third pair repeats the distinction in the one-step form, where encode(...ikm) and encode(...info) are each a single nested element of the message.

Single Segment, AES-256-GCM, HKDF-SHA-256, 65536

Single Segment, ChaCha20-Poly1305, HKDF-SHA-256, 16384

Single Segment, ChaCha20-Poly1305, HKDF-SHA-256, 65536

Single Segment, AEGIS-256, HKDF-SHA-256, 16384

Single Segment, AEGIS-256, HKDF-SHA-256, 65536

Two Segment, AES-256-GCM, HKDF-SHA-256, 16384

Two Segment, AES-256-GCM, HKDF-SHA-256, 65536

Two Segment, ChaCha20-Poly1305, HKDF-SHA-256, 16384

Two Segment, ChaCha20-Poly1305, HKDF-SHA-256, 65536

Two Segment, AEGIS-256, HKDF-SHA-256, 16384

Two Segment, AEGIS-256, HKDF-SHA-256, 65536

TurboSHAKE-256 Cipher Suite Vectors These two vectors exercise the one-step TurboSHAKE-256 cipher suite (), for which Nh = 64. The commitment, snap_key, contrib, the accumulator, and snapshot are therefore 64 octets, while payload_key (Nk) and the nonces (Nn) are unchanged.

Single Segment, AES-256-GCM, TurboSHAKE-256, 65536

Two Segment, AES-256-GCM, TurboSHAKE-256, 65536

Segment Rewrite Vector This vector applies RewriteSegment () to segment 0 of a two-segment AES-256-GCM message, replacing its plaintext under a fresh nonce. The replacement plaintext is the 22-octet ASCII string "Rewritten SEAL segment". acc_delta = old_contrib XOR new_contrib, the new accumulator is the old accumulator XOR acc_delta, and snapshot is recomputed over the count and the new accumulator.

Two Segment, AES-256-GCM, HKDF-SHA-256, 65536 (Rewrite)

Derived-Nonce Cipher Suite Vector This vector exercises AES-256-GCM-SIV (), the MRAE cipher suite that uses derived nonce mode. There is no stored per-segment nonce: each nonce is recomputed from nonce_base by the formula in , which XORs uint64((i << 1) | is_final), the segment index and finality bit, into the low 8 octets of nonce_base (here Nn = 12). The block applies RewriteSegment to segment 0. The replacement plaintext is the 22-octet ASCII string "Rewritten SEAL segment". Because the nonce is recomputed deterministically, the rewrite reuses the same nonce as the original segment 0. AES-256-GCM-SIV is misuse-resistant, so the reuse leaks only equality of identical plaintext-and-context pairs, not plaintext.

Two Segment, AES-256-GCM-SIV, HKDF-SHA-256, 65536 (Rewrite)

Cross-Epoch Key Vector This vector sets epoch_length = 0, the finest epoch partition, so the epoch index equals the segment index and each segment is sealed under a distinct epoch key (). The block exposes the intermediate epoch_key(i) and segment_key(i) for each segment. At epoch_length = 0 the shift is the identity, so segment_key(i) equals epoch_key(i), and epoch_key(0) and epoch_key(1) differ.

Two Segment, AES-256-GCM, HKDF-SHA-256, 65536, epoch_length 0

Plaintext-Bound Nonce Component Vectors These vectors exercise the optional plaintext-bound nonce construction () component by component: the plaintext digest pt_digest, the bound digest pt_hash, the framed nonce_ctx, and the final nonce. The construction is encryptor-only and its output is indistinguishable from random mode on the wire, so no end-to-end vector exercises it. Component values are how this appendix checks an implementation byte for byte. The labels are those of , and nonce_ctx enters the final derivation as a single framed info element after the payload_info elements. Each block reuses the payload_key, payload_info, and salt of a published cipher-suite block, so the values chain into the payload schedules above. The random_input value stands in for the fresh Random(Nn) draw of the construction, and every block binds the plaintext "Hello, SEAL!". These component vectors are printed in this appendix only and are not part of the end-to-end corpus.

AES-256-GCM, HKDF-SHA-256, 16384, Segment 0 The payload schedule is that of , and the segment_aad is that of its Segment 0.

AES-256-GCM, TurboSHAKE-256, 65536, Segment 1 The payload schedule is that of the two-segment TurboSHAKE-256 block (), and the segment_aad is that of its final Segment 1. The segment index is 1, visible in the second framed element of nonce_ctx. The plaintext is the one printed below, not that block's Segment 1 plaintext.

AES-256-GCM, HKDF-SHA-256, 16384, Non-Final Segment 0 with A_i The payload schedule is that of the two-segment AES-256-GCM, HKDF-SHA-256, 16384 block, which equals that of . The segment is that block's Segment 0. A_i is the 16-octet ASCII string "segment metadata", so the segment_aad in nonce_ctx is that block's Segment 0 segment_aad followed by the framed A_i. Among the inputs, only is_final and A_i differ from the first block, so pt_digest and pt_hash repeat its values.

Digest Transcript Component Vectors These vectors exercise the digest transcript () component by component: the schedule values of a SEAL-RO-v1 digest transcript (snap_id 0x0002) context, two segment leaves over specified segment bytes and tags, and the transcript over them. The segment bytes are specified component inputs, not the AEAD output of a full object. The leaf and transcript derivation is what an implementation checks byte for byte. These component vectors are printed in this appendix only and are not part of the end-to-end corpus. The context is a SEAL-RO-v1 object using the digest transcript (snap_id 0x0002), with AES-256-GCM and HKDF-SHA-256, the demo CEK (0xAA repeated) and salt (0x04 repeated) of , and the default empty G. payload_info is [aead_id 0x0002, segment_max_be 65536, kdf_id 0x0001, snap_id 0x0002, segment_commitment 0x01, nonce_mode 0x01 (derived), epoch_length_u8 0x20, salt].

Leaves and Transcript, n_seg = 2 Segment 0 is non-final with 16 specified ciphertext octets, segment 1 is final with 8. In this derived-nonce example A_i is empty, so the segment AAD is empty and each leaf is the ciphertext digest LH(ct_i), the segment's AEAD tag, and the counter uint64((i << 1) | is_final), 56 octets in all. Here the tag is a specified component input. The counter is 0 in leaf(0) and 3 in leaf(1), whose finality bit is set. The transcript's ikm is [snap_key] and its info elements are [...payload_info, commitment, uint64(2), LH(encode(leaf(0), leaf(1)))], with the payload_info elements above. The encode framing binds each leaf's position, and the count element binds the count. The stored keyed snapshot is the transcript. The public snapshot () takes the same info elements under an empty ikm and the label "snap_transcript_pub". It differs from the transcript:

Epoch Digest Tree Component Vectors These vectors exercise the epoch digest tree () with four segments in two epochs. The context is a SEAL-RO-v1 object using the epoch digest tree (snap_id 0x0003) with epoch_length 1 (epoch_length_u8 0x01), chosen small so the example has two epochs of two segments. Changing snap_id and epoch_length changes payload_info, so the commitment and snap_key differ from . The segment bytes and tags are specified component inputs. The context uses the same CEK (0xAA repeated) and salt (0x04 repeated) as , AES-256-GCM, HKDF-SHA-256, segment_max 65536, derived nonce, and the default empty G. The four derived-mode leaves, with the same component inputs as at indices 0 and 1, carry the counters 0, 2, 4, and 7, since only segment 3 is final, so leaf(1) differs from the digest transcript's: Epoch 0 is segments 0 and 1, epoch 1 is segments 2 and 3. Each epoch head is d_e = KDF(protocol_id, "snap_epoch", [snap_key], [...payload_info, commitment, uint64(2), LH(epoch_run(e))], 32), the count being 2, the epoch's leaf count, and epoch_run(e) the encode of its leaves: The snapshot is KDF(protocol_id, "snap_epoch_root", [snap_key], [...payload_info, commitment, uint64(4), LH(d_0 || d_1)], 32): The public heads pd_e = KDF(protocol_id, "snap_epoch_pub", [], [...payload_info, commitment, uint64(2), LH(epoch_run(e))], 32) are taken over the same runs, and the public snapshot is KDF(protocol_id, "snap_epoch_root_pub", [], [...payload_info, commitment, uint64(4), LH(pd_0 || pd_1)], 32) (). Each differs from the keyed value over the same inputs: At the epoch boundary k = 2, with segments 0 and 1 written non-final and the object open, the intermediate snapshots are snapshot(2) = KDF(protocol_id, "snap_epoch_root", [snap_key], [...payload_info, commitment, uint64(2), LH(d_0)], 32) and pub_snapshot(2), the public snapshot at count 2 over LH(pd_0) (). They take leaf(0) and leaf(1) as printed, which carry is_final = 0 in the open prefix as in the complete object. The heads run at count 4 begins with d_0, so snapshot(4) extends snapshot(2): In an object whose segments 0 and 1 were encrypted non-final, the two-segment prefix presented as complete fails the terminal check of with either value, and SnapVerify rejects it declared complete, because leaf(1) would then carry the counter 3.

Negative SnapVerify Vector This vector demonstrates the snapshot integrity check. It takes the honest state of the two-segment AES-256-GCM, HKDF-SHA-256, 65536 vector and flips the first octet of segment 0's stored tag (tag_0), leaving the stored keyed snapshot unchanged. SnapVerify recomputes the accumulator from the two present segment tags (): the tampered tag_0 changes contrib(0), so the recomputed accumulator differs from the honest one and the snapshot recomputed over the observed count no longer equals the stored keyed snapshot. The single constant-time comparison of the recomputed snapshot against the stored value therefore fails, and SnapVerify returns reject. A consumer must treat this entry as expect-reject and must not accept it as a valid snapshot.

Tampered Segment Tag, snapshot Not Recomputed SnapVerify recomputes the accumulator from the present segment tags, recomputes the snapshot over the observed count, and compares it against the stored keyed snapshot in constant time. The tampered tag_0 changes contrib(0), so the recomputed snapshot differs from the stored value and the comparison fails. The tampered tag_0 and the honest keyed snapshot are regenerated with the rest of the corpus.

SEAL-simple(HKDF-SHA-256, AES-256-GCM) This vector realizes the named instantiation of at cipher suite (aead_id 0x0002, kdf_id 0x0001) and matches the implementation sketch of byte-for-byte. It uses SEAL-RO-v1, snap_id 0x0000 (no snapshot authenticator), derived nonce mode, epoch_length 32, segment_max 65536, and the linear immutable reduction layout.

Changes Since -00

• The strict authenticators' leaf is [LH(ct_i)] || tag_i || nonce_field(i) || segment_aad(i, is_final, A_i): the stored nonce in random nonce mode or the counter (i << 1) | is_final in derived nonce mode, then the segment AAD. Metadata entries hold its leading fields in leaf order, and epoch runs frame each leaf. The per-suite nonce-injectivity analysis is withdrawn. The ct_i and tag_i split is stated beside the leaf definition.
• The epoch digest tree's outsider forgery bound is stated as a closed list of three events; the key-holder bounds name the ideal-hash, sponge and long-message cases.
• Binding limits and budgets use the aggregate accounting of the companion; the AES-GCM random-nonce cap and the departure from RFC 8439 for random ChaCha20-Poly1305 nonces are stated.
• The masked multiset hash's writer check and the SEAL-AO-v1 current-count rule is stated.
• The layouts leave no interior segment shorter than the length they fix for its position. Under a mutable profile a writer meets this by rewriting a short terminal segment before an append, and a truncation to a nonempty prefix re-marks the new last segment as final. SEAL-AO-v1 forbids truncation rather than a reduced count.
• The split layout places the aux region after the commitment.
• An authenticator with a strict ordering has snapshots at every count while the object is open, and the epoch digest tree's late joiner adopts heads at an epoch boundary.
• The digest transcript and the epoch digest tree define public snapshots. Every value of the two authenticators, keyed or public, is one KDF over the payload_info elements, the commitment, a count, and the LH digest of a run of leaves or heads, under snap_key or an empty ikm. An epoch head is the digest transcript's formula over its epoch. A new section describes streaming with prefix verification.
• RFC 10032 (AEGIS) and RFC 8126 are normative; the designated expert review criteria are stated.
• The vector files are regenerated for this revision; the plaintext-bound component vectors are regenerated over the framed segment AAD and one at a non-final segment with A_i is added.
• Terms: keyed snapshot, public snapshot, intermediate snapshot, prefix verification, and ciphertext digest.

Acknowledgments The author thanks Andrés Fábrega, Thomas Ristenpart, Gregory Rubin, Richard Barnes, Brendan McMillion, Thibault Meunier, Kenny Paterson, Christopher Patton, Martin Thomson, Stanislav V. Smyshlyaev, and Christopher A. Wood for their reviews, comments, and discussions.