]> Random-Access Authenticated Encryption Cryptography Consulting LLC
nicholas.sullivan+ietf@gmail.com
IRTF Crypto Forum This document defines random-access authenticated encryption (raAE), a primitive that partitions a message into an indexed sequence of segments that can be encrypted and decrypted independently and in any order. It also specifies SEAL (Segmented Encryption and Authentication Layer), a parameterized construction that defines a family of concrete raAE instantiations, one for each valid choice of an Authenticated Encryption with Associated Data (AEAD) algorithm, a key derivation function (KDF), and associated parameters. SEAL provides two profiles, immutable (write-once) and mutable (in-place ciphertext rewrite), each with per-segment authentication. A separately configured snapshot authenticator can additionally authenticate the complete, indexed segment set. The document also defines the security notions of raAE, specifies the requirements for conforming constructions, analyzes SEAL against those requirements, and provides example cipher suites and test vectors. Discussion Venues Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .
Introduction Large encrypted content is often stored as a sequence of fixed-size segments, so that an application can read or modify any part of it without processing the whole. Encrypted backups, encrypted file formats, object stores with partial updates, and full-disk encryption over fixed-size blocks all work this way. Such a system needs to encrypt, decrypt, or re-encrypt any individual segment on its own and in arbitrary order, and to verify that the stored object as a whole is authentic and complete, without re-encrypting the segments that did not change. This document specifies the raAE primitive (), whose base interface and security notions come from Fábrega et al. (), and defines SEAL (Segmented Encryption and Authentication Layer), a parameterized construction of raAE. The base algorithms encrypt and decrypt segments in arbitrary order, so a caller can read or replace any segment on its own. On top of that base, the extended raAE interface adds in-place rewrite and a snapshot, a stored value that authenticates the segment set as the writer last recorded it. A rewrite re-encrypts only the changed segment and updates the snapshot, leaving every other segment untouched. Appending to the end, or truncating from the end, composes the same per-segment operations, so the snapshot stays consistent without a separate algorithm. SEAL builds the primitive from a chosen AEAD algorithm, a key derivation function (KDF), and configuration parameters. Under a snapshot authenticator, it binds every segment tag and the count into a public snapshot value that an adversary cannot forge without the content-derived key.
The raAE primitive and the SEAL construction raAE primitive abstract interface SEAL construction parameterized by a cipher suite (AEAD + KDF), a maximum segment size, and an epoch length mutability: snapshot: immutable | mutable none | present provides per-segment authenticity snapshot integrity (always present) (when present)
raAE separates the two authentication scopes that applications often conflate:
Per-segment authenticity:
One AEAD tag verifies under the segment index, a finality bit marking the last segment, and any caller-supplied associated data. It does not establish that the segment belongs to the current snapshot.
Snapshot integrity:
When a snapshot authenticator is configured, snapshot verification checks that the present segment tags and the count are exactly the set the writer last recorded, under a content-derived key. It does not establish freshness against whole-object rollback, which a consuming protocol must supply.
raAE and SEAL are deliberately distinct layers. A consuming protocol supplies serialization, storage transactions, key management, and rollback protection, which are out of scope here. The remainder of this document presents raAE first and SEAL second. situates raAE against prior segmented authenticated-encryption (AE) constructions. fixes terminology and notation. specifies the raAE primitive and its extended snapshot operations. defines SEAL. states the target security properties an raAE construction must meet, the assumptions SEAL's components must satisfy, and the operational limits on its use, and defines the security notions. Cipher suites, serialization layouts, and named instantiations are in , , and , and the appendices provide the test vectors.
Related Work CHAIN () is a segmented authenticated-encryption construction that chains state from one segment to the next. It is sequential by construction and supports neither independent random-access reads nor in-place segment rewrites. STREAM () turns a nonce-based AEAD into a segmented construction using induced nonces that encode a message nonce, the segment index, and a final-segment bit. STREAM supports random-access decryption and encryption of individual segments, but defines neither authenticated snapshots nor authenticated rewrites. SEAL's derived nonce mode () follows STREAM's counter-plus-final-bit structure and adds those operations. Tink Streaming AEAD () and OpenPGP v2 Symmetrically Encrypted and Integrity Protected Data (SEIPD) packets () are deployed STREAM-family formats. Both derive a message key and nonce prefix from a key and a salt, encrypt each chunk under an AEAD nonce carrying the chunk index, and detect truncation with a final tag over the empty string. Tink derives an AES-GCM key with the HMAC-based Key Derivation Function (HKDF) (), while v2 SEIPD selects its cipher and AEAD from packet identifiers. Each chunk is independently authenticated and can be verified locally at its boundary. Neither format defines an in-place rewrite operation or a snapshot authenticator over an updatable set of segment tags. SEAL's snapshot authenticator is a keyed multiset hash over the segment tags, the MSet-XOR-Hash of Clarke, Devadas, van Dijk, Gassend, and Suh (), published behind a deterministic mask this document adds (). Each segment contributes a keyed KDF evaluation of its index and AEAD tag, the contributions XOR into an accumulator that any rewrite updates in O(1), and a domain-separated snapshot tag binds the segment count and the accumulator. Fábrega et al. () formalized random-access AEAD security over a raAE primitive syntax in which segment encryption and decryption may be invoked in arbitrary order, and gave a construction, FLOE (Fast Lightweight Online Encryption), proved to meet it. FLOE realizes the base interface: segments are written once, and there is no snapshot. SEAL realizes that primitive with the extension of this document, and defines the security notions used in its analysis. Each precedent covers part of the random-access AE design space. raAE is the abstract interface that generalizes the family with three capabilities none of them combines: arbitrary-order encryption, in-place authenticated rewrite, and an O(1) updatable snapshot over the whole segment set. SEAL realizes all three in one construction.
Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. A message segment is a unit of plaintext that is individually encrypted and authenticated. Segments need not be uniform in length. A construction MAY set a maximum segment size, and any segment MAY be shorter than that maximum. A message is the content that one CEK and salt pair protects, the unit the primitive encrypts. An object is that message in stored form: the ciphertext segments, their metadata, and any snapshot that a storage layer holds. Each object carries one message, whose content may change through rewrite and length-changing operations. A ciphertext core is the AEAD encryption output corresponding to one message segment, excluding file-level headers and external segment metadata. An AEAD-specific split divides this output into ct_i, the encrypted segment body, and tag_i, the authentication tag. A ciphertext segment is the stored representation of one encrypted message segment. Depending on nonce_mode, it contains the ciphertext core and MAY also contain a stored nonce or other per-segment metadata. Segment metadata is per-segment information needed to decrypt or verify a ciphertext segment, such as a stored nonce, tag, finality status, or profile-defined values. This document writes AEAD.Encrypt and AEAD.Decrypt for the authenticated encryption and decryption operations defined in . A subscript denotes a per-segment value: X_i is the value X for the segment at index i, as in A_i, P_i, ct_i, and tag_i. A value written f(i), as in segment_key(i) or nonce(i), is computed from the index by the named derivation. X[a:b] is the octet range of X from offset a inclusive to offset b exclusive. The remaining terms (ikm, label, info, L, salt, CEK, protocol_id, nonce_mode, epoch, epoch_key, payload_key, segment_key, snap_key, and the commitment) are defined in where they first appear.
Taxonomy This document uses the following terms to keep the raAE primitive, the SEAL construction, profiles, and consuming protocols distinct.
raAE primitive:
The abstract random-access AE interface and security target.
Extended raAE interface:
The base interface plus snapshot maintenance and verification.
SEAL construction:
The concrete construction specified in .
Cipher suite:
The AEAD and KDF algorithms and their sizes.
Profile:
A named set of fixed parameter choices, identified by a protocol_id, needed for interoperability ().
Parameter set:
The per-object values that affect derivation and verification.
Consuming protocol:
The protocol or format that stores objects and manages keys.
Serialization:
The consuming protocol's wire or storage encoding.
Segment:
A zero-based independently encrypted plaintext unit.
Epoch:
A group of 2^epoch_length segment indices sharing one epoch key.
Snapshot value:
The public value that, when a snapshot authenticator is configured, authenticates one segment set.
Per-segment authenticity:
AEAD verification for one segment only.
Snapshot integrity:
Verification of the complete segment tag set and snapshot.
External freshness:
Rollback protection supplied outside raAE.
Notation
I2OSP(n, w):
The w-octet big-endian encoding of the non-negative integer n, as defined in .
uint8(n), uint16(n), uint32(n), uint64(n):
Shorthand for I2OSP(n, 1), I2OSP(n, 2), I2OSP(n, 4), and I2OSP(n, 8) respectively.
||:
Octet string concatenation.
XOR:
Bitwise exclusive-or of two octet strings of equal length.
x[a:b]:
Octets a through b-1 inclusive of x (zero-based, half-open interval).
[x, y, ...]:
An ordered list of octet strings. A single-element list is written [x]. The brackets denote a list, not an optional parameter.
frame, encode:
The length-prefixed injective encoding used by SEAL, defined in . frame is total over all field lengths. The construction requires an injective framing () but does not mandate this encoding. Another profile MAY use any injective encoding that meets .
Nk:
Key size in octets for the chosen AEAD algorithm.
Nn:
Nonce size in octets for the chosen AEAD algorithm.
Np:
Presented nonce size in octets: the per-segment nonce stored in metadata. Np = Nn in random nonce mode and Np = 0 in derived nonce mode, where the nonce is recomputed from the key schedule.
Nh:
Hash or pseudorandom function (PRF) output size in octets for the chosen KDF.
Nt:
Authentication tag size in octets for the chosen AEAD algorithm.
Na:
The snapshot value length in octets, the output size of the configured snapshot authenticator. It MAY depend on the segment count n_seg, and is 0 when none ().
n_seg:
The number of ciphertext segments in a stored message. Written n_seg (lowercase) to distinguish it from the per-message nonce N in the raAE interface ().
The raAE Primitive
Overview Random-access authenticated encryption (raAE) partitions a message into segments, each encrypted and decrypted on its own and in any order. A reader can open one segment without the rest of the message, and a writer can encrypt one without holding the others. In the base interface , each segment is written once and thereafter only read. The extended raAE interface keeps that base and adds one capability: a segment already written may be replaced in place, without disturbing the rest. Rewriting changes the threat model. A storage layer holding the ciphertext can roll a segment back to an older valid copy, substitute one valid same-index segment for another, or drop one, and per-segment authentication still passes on each segment it is shown. An optional snapshot authenticates the segment set as the writer last recorded it, so a reader can detect these changes. The extension () defines the snapshot and the operations that maintain it. The security notions follow the interface. raAE and its rewrites target ra-ROR (random-access real-or-random) and ra-CMT (random-access context commitment) (). Rewriting leaves both untouched, since replacing a segment is an encryption the read-only adversary could already ask for. Snapshot authentication adds the one notion of its own, snapshot integrity ().
Interface The base raAE interface, from , is a tuple of five algorithms: KeyGen, StartEnc, EncSeg, StartDec, and DecSeg.
KeyGen:
Randomized key generation. Takes no input. Outputs a secret key K.
StartEnc(K, N, G):
Deterministic. Takes a secret key K, nonce N, and global associated data G. Outputs a ciphertext header T_g and an initial per-message encryption state S.
EncSeg(S, p, A_i, M_i):
Randomized. Takes the encryption state S, a position identifier p, per-segment associated data A_i, and message segment M_i. Outputs a ciphertext segment C_i. S is not modified. EncSeg may be called with the same S at any position, in any order, or concurrently.
StartDec(K, N, G, T_g):
Deterministic. Takes key K, nonce N, global associated data G, and ciphertext header T_g. Outputs a per-message decryption state S or an error.
DecSeg(S, p, A_i, C_i):
Deterministic. Takes the decryption state S, position identifier p, per-segment associated data A_i, and ciphertext segment C_i. Outputs message segment M_i or an error.
The position identifier p = (i, b) consists of a segment number i and a terminal bit b in {0, 1}. They impose a total ordering on segments and carry a truncation defense: a ciphertext lacking a segment with b = 1 is incomplete. The encryption state S is immutable. That immutability is what makes arbitrary-order and fully parallel operation possible. The ciphertext header T_g commits to K, the nonce N, and global associated data G. A headerless scheme emits T_g = empty.
Extended Interface Replacing a segment already written, without re-encrypting the others, requires no new operation: re-encrypting a position is an ordinary EncSeg call over the immutable state, and it leaves ra-ROR and ra-CMT untouched. Rewriting gives a storage layer something to attack: it can roll a segment back to an older valid copy, substitute one valid same-index segment for another, or drop one while per-segment authentication still passes on what it presents. A scheme that supports rewriting MAY carry a snapshot, a value over the current set of segments that a reader checks to detect these changes. Two operations, added by this document, maintain and check the snapshot. RewriteSeg replaces a segment and updates the snapshot in the same step. SnapVerify decides whether a given set of segments is the one the writer last recorded.
RewriteSeg(S, p, A_i, M'_i, C_i, snapshot):
Randomized. Takes the encryption state S and position identifier p, per-segment associated data A_i, the new message segment M'_i, the existing ciphertext C_i at position p, and the current snapshot. Outputs replacement ciphertext C'_i and an updated snapshot value, snapshot'.
SnapVerify(S, segments, snapshot):
Deterministic. Takes the encryption state S, the present segments (the (position, ciphertext segment) pairs of the current object state), and the snapshot. Outputs accept or reject.
The extension also changes two base signatures. In the extended interface:
StartEnc(K, N, G):
Deterministic. As in , and additionally outputs the initial snapshot value, the snapshot over the empty segment set.
EncSeg(S, p, A_i, M_i):
Randomized. As in , and additionally outputs the snapshot value over the segment set that results from adding C_i at position p.
The snapshot is an authenticator over the set of segments belonging to the current object state. When the scheme supports incremental update, an update can run in time independent of the total segment count. This is an implementation goal, not a syntactic requirement of the interface. The base primitive has no snapshot value. The snapshot, the two signature changes above, RewriteSeg, and SnapVerify are defined by this document. These additions define the extended raAE interface of this document: the tuple (KeyGen, StartEnc, EncSeg, StartDec, DecSeg, RewriteSeg, SnapVerify) over the auxiliary snapshot value. The first five algorithms are those of , with the snapshot outputs of StartEnc and EncSeg defined above. The snapshot value, RewriteSeg, and SnapVerify are the extension. A scheme can realize the base interface alone, as FLOE () does. SEAL () realizes the full extended interface. Length change adds no further algorithm, as the next paragraph describes. Changing a message's length is a composition of these operations, not a separate algorithm in either direction. Position-addressed encryption over immutable state already permits re-encrypting a position or encrypting at a higher index (see ). A holder appends by encrypting the new segments and re-marking the old final segment with RewriteSeg to clear its terminal bit. It truncates by re-marking the new final segment with RewriteSeg, dropping the trailing segments, and updating the snapshot over the surviving set. Appending to an empty object skips the re-mark, since there is no old final segment, and truncating away every segment yields the empty object, with no new final segment to re-mark. Length changes occur only at the end of the message: a holder may append segments or drop a suffix, but cannot remove or renumber front or interior segments, because positions are index-addressed. Each step updates the snapshot, and gives the construction for both directions.
SEAL: A Concrete raAE Construction SEAL is a parameterized construction for realizing the raAE primitive defined in . A SEAL instantiation combines an AEAD, a KDF, a key schedule, a nonce-generation method, a commitment mechanism, and an optional snapshot authenticator to produce an raAE scheme for segmented stored content. The raAE interface defines what operations and security properties a scheme provides. SEAL defines how those operations are realized from standard cryptographic components. Different SEAL instantiations MAY select different AEADs, KDFs, nonce modes, commitment mechanisms, or snapshot authenticators, provided they satisfy the requirements of this section. The remainder of this section specifies the common SEAL construction. analyzes its security, and concrete parameter choices and interoperable suites are in . The key hierarchy is shown below. A CEK and per-content salt feed the payload schedule, which derives four values. The payload key feeds per-segment keys (optionally through epoch keys), and each segment produces an AEAD tag. When a snapshot authenticator is configured, every tag feeds it to produce the snapshot.
SEAL Key Hierarchy CEK salt Payload Schedule commit payload nonce snap key base key cmt seg nonce key(i) (i) AEAD Seal(i) ct_i tag_i Snapshot Authenticator snapshot
Construction Overview A commitment lets a reader reject a wrong key or parameter set before decrypting anything. An optional snapshot authenticates the current set of segments. SEAL realizes the raAE operations of as follows: raAE operations and their SEAL realizations
raAE operation SEAL realization
StartEnc Derive the payload schedule from the CEK and salt, committing G ()
StartDec Re-derive the schedule and verify the stored commitment ()
EncSeg, DecSeg EncryptSegment and DecryptSegment ()
RewriteSeg RewriteSegment, then update the snapshot authenticator for the changed segment ()
SnapVerify Check the present indices and finality, then verify the snapshot via the authenticator ()
SEAL's salt, payload_info, and G carry the raAE per-message inputs, and the commitment stands in for the header ().
Component Suite and Parameters This section names every parameter, input, and derived symbol the construction uses. summarizes them, grouped by what sets each one. The entries that follow define the suite choices, the profile-level constants, the algorithm-determined sizes, and the per-message inputs. Derived values are defined where they are computed, in the sections the table cites. Parameters, inputs, and derived values
Parameter Type or range Set by Defined in
AEAD RFC 5116 algorithm suite
KDF kdf_id from suite
segment_max power of two, at least 4096 suite
epoch_length integer r in 0 to 63 suite
protocol_id octet string application
nonce_mode "random" or "derived" message, within the profile
aad_label ASCII string ("SEAL-DATA" in SEAL) profile
commitment_length integer, at least 16, default Nh profile
Nk, Nn, Nt sizes in octets AEAD
Nh size in octets KDF
CEK 32 uniform random octets message input
salt 32 uniform random octets message input
payload_info ordered element list message input
G octet string, empty by default message input
commitment commitment_length octets derived per message
payload_key Nk octets derived per message
snap_key Nh octets derived per message
nonce_base Nn octets, derived mode only derived per message
epoch_key(i) Nk octets derived per segment
segment_key(i) Nk octets derived per segment
nonce(i) Nn octets derived per segment
segment_aad(i, is_final, A_i) octet string derived per segment
tag(i) Nt octets derived per segment
SEAL fixes the segment additional authenticated data (AAD) encoding, the commitment derivation, and the snapshot value for every suite. They are specified in , , and respectively, and are encoded identically across all SEAL cipher suites. The resulting octet lengths still vary by suite, because Nh and Nt are suite-dependent.
Suite Choices A suite is assembled from the following choices.
AEAD:
An authenticated encryption with associated data algorithm satisfying the interface of , with Nk-octet keys, Nn-octet nonces, and Nt-octet authentication tags.
KDF:
A key derivation function supporting the abstract interface defined in . See for the permitted KDFs.
segment_max:
A positive integer, a power of two and at least 4096 octets. Each segment carries at most this many plaintext octets. The length-dependent limits of are computed at this size.
epoch_length:
A non-negative integer r in 0 to 63. Each epoch covers 2^r consecutive segments aligned to a multiple of 2^r (). Profiles MAY restrict r further per AEAD (). The value sets a rotation granularity, not an on/off switch: r = 0 selects the finest rotation, a fresh epoch key for every segment, and no value of r disables epoch-key derivation. A flat key, one epoch key covering all segments, is r = 63.
protocol_id:
An application-chosen octet string that binds all derived values to a specific protocol version. Selection guidance is in .
nonce_mode:
A payload_info element selecting one of two nonce constructions, "random" or "derived". The constructions are defined in , the default mode each SEAL suite uses in the mutable profile (), and the valid (nonce_mode, snap_id) tuples for each profile in .
Profile-Level Constants One constant is fixed by the profile rather than carried per message.
aad_label:
A profile-level ASCII string bound as the first element of the segment AAD encoding (). Consuming protocols MAY define their own profiles with a distinct aad_label.
Algorithm-Determined Sizes The sizes Nk, Nn, Nt, and Nh are fixed by the chosen AEAD and KDF rather than by the parameter set directly. They are defined in , with concrete values in and . One configurable length defaults from Nh.
commitment_length:
A positive integer of at least 16, defaulting to Nh, the length in octets of the key commitment prefix. The collision bounds for each length are given in .
Per-Message Inputs An encrypted message is built from four input values.
CEK:
A 32-octet uniform random Content Encryption Key generated fresh for each message. The CEK is input keying material for the key schedule, not an AEAD key.
salt:
A per-content value of 32 uniformly random octets. The salt separates payload schedule outputs across messages even when the CEK is reused. and give the rules for generating and reusing it, and analyzes the consequences of reuse.
payload_info:
The committed record of the object's configuration: an ordered list of parameter set context elements covering key derivation, AEAD operations, AAD construction, and nonce construction, which the commitment () binds. The profile fixes the concrete element set and their encodings. SEAL's payload_info is specified in .
G:
An octet string of global associated data, the G input of StartEnc in the raAE primitive (), binding whole-message application context such as a name, version, or policy. G defaults to the empty octet string and is never stored: a decryptor supplies it from application context, and the commitment binds it ().
The remaining symbols in are derived values. The payload schedule () computes the per-message values commitment, payload_key, snap_key, and nonce_base once from the CEK and payload_info (the commitment also binds G, ), and they are fixed for the message's lifetime. The per-segment values epoch_key(i), segment_key(i), nonce(i), segment_aad(i, is_final, A_i), and tag(i) are defined where they are computed: , , , and .
The KDF Combiner The KDF combiner uses a length-prefixed encoding for all of its inputs. frame is total over every field length. A field of at most 0xFFFE octets is emitted literally behind its 2-octet length, identical to a plain length prefix. The reserved length 0xFFFF is a typed prefix meaning that an Nh-octet digest LH(x) of an over-large field follows in place of the field itself. LH(x), the over-large-field digest, runs the cipher suite's native KDF primitive directly on x, invoking neither encode nor frame, and returns Nh octets. The two-step and one-step classes are HPKE's: a two-step KDF () uses its extract step, and a one-step KDF () its XOF, with x carried under the label "raAE-LP-v1": Routing LH through the KDF would encode-frame x and recurse, because frame of an over-large x would re-enter LH. LH therefore runs the native primitive directly on x. The injectivity of encode and the domain-separation and collision properties of LH are established in . Key material is derived through a KDF with the interface
  • protocol_id: binds the output to a specific protocol version and application context.
  • label: a unique ASCII string identifying the derivation role.
  • ikm: input keying material, provided as a single octet string or an ordered list of octet strings.
  • info: context information, provided as a single octet string or an ordered list of octet strings.
  • L: the requested output length in octets.
This KDF binds protocol_id, a label, and inputs of any size into a derived value; frame reduces any over-large input to a fixed-size digest before the KDF sees it. Any protocol instantiates the combiner by supplying its own protocol_id, which domain-separates its derivations from those of every other protocol. SEAL's two profiles instantiate the combiner at protocol_id SEAL-RW-v1 and SEAL-RO-v1 (). The KDF is built from the cipher suite's hash in one of two forms. The cipher suite's kdf_id () selects which one.
Two-Step KDF The notation ...x means each element of the sequence x, whether ikm or info, is a separate argument to encode. A single octet string is the one-element sequence containing it. An absent value is the empty sequence and contributes no arguments. The empty sequence and the one-element sequence whose element is the empty octet string are distinct: the first adds nothing to the encode, the second adds one zero-length field. A derivation with no info MUST use the empty sequence, not the empty octet string, so that every implementation encodes a given (protocol_id, label, ikm, info, L) tuple to the same octets. The protocol_id appears in both the Extract salt and the extract_input as a defensive measure, and binding in either position suffices for domain separation. The label appears in both Extract and Expand so that label binding is preserved even if one phase is weak in isolation. Implementations MAY amortize the Extract computation internally when deriving multiple outputs from the same protocol_id, label, and ikm.
One-Step KDF The XOF-based form frames ikm and info each as a single element of one length-prefixed encode and squeezes L octets of output. protocol_id binding is via the message-side encode prefix only. In both forms the encoded input ends with uint16(L): the two-step form places it last in expand_info and the one-step form places it last in M. Within a fixed kdf_id, distinct (protocol_id, label, ikm, info, L) tuples yield distinct outputs, by the injectivity of encode (established in and demonstrated in ). The two forms are not mutually injective: a cipher suite's kdf_id () selects one form for that suite, and payload_info commits to the kdf_id (), so no derivation ever compares outputs across forms. The two-step form binds ikm in Extract and info in Expand. A multi-value ikm or info is the encode of its elements, so any number of elements is admitted. The following example expands M for combiner vector KDF.33 (): TurboSHAKE-256, label "commit", ikm a single 32-octet element of repeated 0xAA, info the two elements 010203 and 0405, and L = 64. Each frame is a 2-octet length followed by the element, and the ikm and info lists are each one nested encode: With info = [], the empty sequence, the fourth frame is the two octets 0000: encode() of no elements is the empty octet string, and its frame is a zero length with no content. With info = [""], one zero-length element, the inner encode is 0000 and the fourth frame is 0002 0000. KDF.8 and KDF.28 () exercise the same distinction in the two-step form.
SEAL Encodings and Labels SEAL fixes the concrete encodings the combiner and the AEAD consume: the payload_info tuple, the segment AAD, and the derivation labels.
Payload Info Construction Element encodings for SEAL:
  • aead_id: 2 octets, uint16(id), the unsigned 16-bit AEAD identifier from (for example, 0x0002 for AES-256-GCM).
  • segment_max_be: 4 octets, uint32(segment_max). SEAL's segment sizes are given in .
  • kdf_id: 2 octets, uint16(id), the unsigned 16-bit KDF identifier from (0x0001 for HKDF-SHA-256 per Section 7.2; 0x0013 for TurboSHAKE-256 per ).
  • snap_id: 2 octets, uint16(id), the snapshot authenticator identifier from (0x0000 for none, 0x0001 for the masked multiset hash).
  • nonce_mode: 1 octet, the nonce construction (): 0x00 for random, 0x01 for derived. gives the default mode each SEAL suite uses in the mutable profile. A profile MAY select another valid (nonce_mode, snap_id) tuple.
  • epoch_length_u8: 1 octet, uint8(epoch_length). Valid values per . Implementations MUST reject epoch_length >= 64 on both encode and decode.
  • salt: 32 raw octets, the per-message salt.
The aad_label is a profile-level constant for SEAL (see ) and is not carried in payload_info. It is bound transitively via protocol_id. The KDF () applies frame to each element of the list.
Segment AAD The segment AAD binds each segment to its context. What it must carry depends on the nonce mode: a random nonce binds neither the segment index nor the finality bit, so the AAD must, whereas a derived nonce binds both (). Segment AAD by nonce mode
  Random nonce mode Derived nonce mode
Index i and is_final bound in the AAD bound in the nonce
A_i, when present appended as a fourth encode element the sole variable element
A_i, when empty omitted, not a zero-length element segment_aad is empty, with no associated-data pass
aad_label is the profile-chosen label from the parameter set, the index i is a big-endian 8-octet integer, and is_final is 1 for the last segment and 0 for all others. Because encode length-prefixes every element, omitting an empty A_i stays injective, so the index and finality bit remain authenticated. Any profile that defines a random-mode segment_aad MUST preserve injectivity and MUST authenticate the segment index and finality bit. aad_label is bound transitively through protocol_id (), so segment_aad need not repeat it for cross-profile separation. More generally, the binding of the triple (i, is_final, A_i) MUST be unambiguous under one segment key, so that no two distinct triples present the same inputs to the AEAD. In random nonce mode segment_aad alone MUST injectively bind the triple, because the nonce is an independent random draw. In derived nonce mode i and is_final are bound in the nonce and A_i, when present, in segment_aad, and the (nonce, segment_aad) pair MUST jointly determine the triple (). A_i is the caller-supplied per-segment associated data of EncSeg and DecSeg (), passed to the segment algorithms (). It MAY be empty and MAY differ per segment. Unlike a global associated data value G, which the commitment fixes at creation (), A_i rides the per-segment AEAD associated data and is rewritable: a rewrite can change a segment's A_i. The example test vectors use an empty A_i, so the random-mode vectors keep the three-element encoding and the derived-mode vector has an empty segment_aad. The salt is not included in the AAD because it is already bound into segment_key via the payload schedule. Different messages produce different segment keys even at the same index. Transposing two segments within a message fails because the AAD at each position encodes the expected index. Unauthorized truncation is detectable, and requires a decryptor to reject it. A reader that sees the highest-indexed present segment carry is_final = 0 knows more data must follow. Authorized truncation by the CEK holder instead re-marks the new final segment and updates the snapshot (). Extension is also caught: appending after a segment marked is_final = 1 either invalidates the original final segment on re-read or produces a ciphertext that cannot verify. Each segment binds both its index and its finality bit, through the AAD in random nonce mode and through the nonce in derived nonce mode. This per-segment binding, rather than reliance on the snapshot alone, catches these attacks. A reader can check them without holding all tags before decrypting any one segment. The per-segment AEAD binds a segment's index and finality, not its length (through the AAD in random nonce mode and through the nonce in derived nonce mode). A segment's ciphertext length is authenticated implicitly by the AEAD tag over the ciphertext: altering, truncating, or splicing a segment ciphertext is an AEAD forgery, not a parsing ambiguity. Because segments MAY be shorter than segment_max, the consuming format MUST convey each segment's ciphertext length to the decoder. A wrong length yields an AEAD rejection, never a silent accept.
Labels SEAL core KDF labels by role
Derivation role Label variable Value
Commitment commit_label "commit"
Payload key payload_key_label "payload_key"
Snapshot authenticator key snap_key_label "acc_key"
Nonce base nonce_base_label "nonce_base"
Epoch key epoch_key_label "epoch_key"
SEAL fixes each label to the value above. The construction formulas reference labels by variable name, so the labels are SEAL parameters rather than constants of the raAE construction. Each value is an ASCII string and is distinct from all others. These label strings are frozen for wire compatibility. In particular the snapshot authenticator key snap_key uses the label string "acc_key", retained from an earlier name. These are the always-present key-schedule labels. The masked multiset hash (), the plaintext-bound nonce construction (), and hedged randomness () each define their own labels.
Key Schedule and Nonce Generation A message's entire key hierarchy grows from two random values: the 32-octet CEK and the per-content salt. All other keys are derived deterministically through the KDF of .
Payload Schedule Four values are derived from the CEK and per-content salt. The commitment allows early rejection of a wrong key and additionally binds the global associated data G (). The payload key encrypts segments through epoch keys. The snapshot authenticator key is used by the configured snapshot authenticator. The nonce base (derived-mode only) seeds deterministic per-segment nonces. G is the global associated data of , always the last element of the commitment info. It defaults to the empty octet string, one zero-length element, so every commitment derivation includes it. The other three derivations never take G.
Epoch Key Derivation AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305 use a 96-bit nonce. At a 2^(-32) collision-probability target, the random-nonce budget is about 2^32 encryptions per key. For rewritable content, this limit can be reached through repeated modifications to the same segments. Epoch keys partition the nonce space: each epoch key covers at most 2^r segment positions (initial writes plus rewrites), so the per-key invocation count is bounded regardless of the content's total size. When epoch_length = r is specified, the segment key for segment i is an epoch key derived from the payload key: > epoch_length return KDF(protocol_id, epoch_key_label, [payload_key], [uint64(epoch_index)], Nk) ]]> At epoch_length = 0 the shift is the identity, so each segment has its own epoch key. At a large epoch_length every segment shares one epoch key. Implementations MUST apply this derivation at every epoch_length, including 0, and MUST NOT use payload_key directly as a segment key. Epoch keys implement the parallel external rekeying pattern of , adapted for random-access patterns.
Nonce Generation Two nonce modes, random and derived, trade off AEAD flexibility, storage cost, and trust in a cryptographically secure pseudorandom number generator (CSPRNG). Derived mode needs misuse-resistant authenticated encryption (MRAE) unless the profile is write-once (). The chosen mode is part of the parameter set and MUST be consistent across all segments of a message.
The Two Nonce Modes Random: Derived: nonce_base Random(Nn) - | XOR ((i<<1)|is_final) | nonce_i nonce_i
The two modes differ as follows: Random and derived nonce modes
Property Random nonce mode Derived nonce mode
Per-segment nonce stored yes, in segment metadata no
CSPRNG required yes no
AEAD requirement any AEAD MRAE, or any in a write-once profile
Rewrite fresh nonce each write nonce fixed by index, reused on rewrite
Per-segment AAD binds index and finality empty when no A_i (index/finality in nonce)
Minimum nonce size Nn no added constraint at least 8 octets
Random Nonce Mode In random nonce mode (nonce_mode = "random"), each segment gets an independent random nonce: Each segment's nonce is stored in per-segment metadata and MUST be accessible to any reader that decrypts individual segments. This mode requires a functioning CSPRNG. The nonce collision probability across independently generated per-segment nonces follows the standard birthday bound. See . Two optional encryptor-side hedges harden this mode against different threats. Hedged randomness () mixes in a long-term key and defends against a weak or predictable CSPRNG. It does not defend against CSPRNG state duplication, since identical CSPRNG output still yields identical hedged output. Only the plaintext-bound construction (), which mixes in plaintext content, defends against state duplication. Both are implementation-local, leave the wire format unchanged, and are not separate nonce modes.
Derived Nonce Mode Derived nonce mode is intended for profiles that do not store a per-segment nonce. Nonces are derived deterministically from the payload schedule. Derived nonce mode is defined only for AEADs whose nonce size Nn is at least 8 octets. The segment index occupies the high bits of an 8-octet counter and the finality bit occupies the low bit, so the per-segment AAD need not carry either one. The XOR is applied to the last 8 octets of nonce_base, with the remaining octets unchanged: No per-segment nonce storage is required. The encoded value (i << 1) | is_final MUST fit in the low 8 octets of nonce_base, so the segment index i MUST be less than 2^63. This caps an object at 2^63 segments, far beyond any reachable object. See for the resulting size limit. A derived nonce is fixed by the segment index, so re-encrypting a segment reuses its nonce. An MRAE AEAD such as AES-256-GCM-SIV () tolerates that reuse, degrading to equality leakage rather than plaintext recovery, within the per-segment rewrite limit given in . A non-MRAE AEAD does not: reusing its nonce leaks plaintext, so with a non-MRAE AEAD, derived nonce mode MUST be confined to a write-once profile, in which each segment is encrypted exactly once. A write-once profile rewrites nothing and performs no length change. A rewrite would repeat a derived nonce, and a length change re-marks the terminal segment under a fresh nonce (is_final flips the low bit). The write-once discipline is the simplest rule that keeps every derived nonce unique. It MUST draw a fresh salt for every object, so the nonce base differs, and MUST NOT re-encrypt under that salt after a crash (). Folding is_final into the nonce also removes a per-segment cost. The nonce binds the index and finality, so the per-segment associated data need not carry them: segment_aad is empty when the caller supplies no A_i, and is encode(aad_label, A_i) otherwise (). When A_i is empty the AEAD processes no associated data, removing the per-segment associated-data pass that random nonce mode incurs. This is the structural reason an immutable, write-once profile in derived nonce mode coincides with STREAM () at the nonce-and-AEAD layer: a key-derived counter-plus-final-bit nonce over a per-segment AEAD with no associated data.
Commitment Per-segment AEAD authenticates the ciphertext core together with the segment index and finality bit (through the segment AAD in random nonce mode and through the nonce in derived nonce mode) so position binding for the segment being opened is already provided. Two further properties remain: context commitment, provided here, and snapshot membership, provided by the snapshot authenticator (). The commitment lets a reader reject an incorrect CEK or parameter context before attempting any segment decryption, providing ra-CMT-style context commitment () for the construction. The commitment is a commitment_length-octet value the payload schedule derives from the CEK, payload_info, and the global associated data G (). Before decrypting any segment, a reader derives the expected commitment from the CEK, payload_info, and G, and compares it octet-for-octet with the stored value. A reader MUST verify the commitment before decrypting any segment and MUST treat a mismatch as an authentication failure for the object. A mismatch indicates a wrong key, a wrong parameter set, a wrong G, or a corrupted header. This check provides ra-CMT context commitment. The reduction outline and bound are in . G is the global associated data input of StartEnc in the raAE primitive (), binding whole-message application context such as a name, version, or policy. The key schedule commits G by appending it as one length-prefixed element after payload_info in the commitment info input (), so the commitment covers G just as the primitive's ciphertext header T_g does (). G is bound through the commitment, which is fixed when the content is created, so G is immutable: changing it invalidates the stored commitment. Segment contents remain rewritable through the snapshot authenticator (). G defaults to the empty octet string, so a message whose application supplies no context commits over an empty final element. G is never stored. A decryptor supplies it from application context, and a wrong G fails the commitment check () the same way a wrong CEK does ().
Snapshot Authenticator The snapshot authenticator binds the current set of segment tags into the public snapshot value. A SEAL profile selects one with snap_id ().
Interface and Requirements A snapshot authenticator provides the following operations:
add(i, tag):
Fold one segment's tag into the running value.
remove(i, tag):
Take one segment's tag back out. An updatable authenticator provides this operation, so a single segment can be rewritten or dropped without rebuilding. An add-only authenticator omits it and rebuilds the value by re-adding the surviving segments.
set_length(n):
Set the segment count to n.
snapshot():
Bind the current state into the snapshot value, which authenticates the (index, tag) set and the count n_seg.
verify(snapshot):
Recompute the snapshot value over the current (index, tag) set and accept only if it matches the stored snapshot, in constant time.
The scheme's RewriteSeg and SnapVerify () are realized from these operations. SnapVerify(S, segments, snapshot) checks a stored snapshot:
  1. Let n_seg be the number of present segments.
  2. Verify that the present segments occupy exactly the indices 0..n_seg-1, each once. Finality is not checked here: is_final is authenticated by the segment AEAD at decryption, and rejects a present set whose highest-indexed segment does not carry is_final = 1.
  3. Call verify(snapshot) over the present (index, tag) set and the count n_seg.
A duplicate or missing index is caught only by step 2, because an authenticator's verify MAY accept a malformed index multiset. An implementation MUST NOT skip the index-set check. SEAL's masked multiset hash realizes verify in . SnapVerify above checks the whole-object target. An authenticator MAY also support a single-segment target that verifies one (index, tag) against the recorded set. The masked multiset hash reads all tags and supports the whole-object target only. The snapshot value stays a single target-independent value of length Na, with no per-segment proof stored. A conforming authenticator's snapshot() MUST bind both the (index, tag) set and the count n_seg, so a verifier detects any added, dropped, reordered, re-marked, or otherwise altered segment, and the snapshot value MUST be unforgeable by a party without the authenticator's key, under that authenticator's security assumption. How the value is computed, and whether a single-segment change updates it in place or rebuilds it, is the authenticator's choice. The masked multiset hash () updates in place in O(1). The snapshot value length is written Na and MAY depend on n_seg, with Na = 0 meaning no value. A fixed-length authenticator suits any layout, while a count-dependent one is supported only by the split layout of a mutable object (). A segment's finality is a function of its index and the count: It is carried by that segment's tag. Because finality follows the count, changing n_seg re-marks the boundary segment on its own, so rewrite, extend, and truncate are one update over the segments whose tag changes:
  1. Under the current count, remove each changed segment's current tag (remove(i, tag)). The current n_seg fixes which segment is terminal, so each removal carries that segment's current finality.
  2. Set the length to the new count (set_length(n)).
  3. Under the new count, re-encrypt each surviving changed segment under its new finality and add its new tag (add(i, tag)). New segments are added here. Discarded segments are not added back.
  4. Call snapshot(), which recomputes the snapshot value over the new count and segment set.
Each operation is an instance of that shape over different segments: Rewrite, extend, and truncate
Operation Count Tags removed Tags added Terminal re-mark
Rewrite unchanged the changed segment the changed segment none
Extend by k n_seg to n_seg+k old terminal old terminal and k new old final, 1 to 0 (none if empty)
Truncate to m n_seg to m the tail and old terminal new terminal new final, 0 to 1 (none if m=0)
Each operation re-encrypts only the segments whose tag changes, so a caller that cannot recover a re-encrypted segment's plaintext cannot perform it. This sequence uses remove, so it is the updatable-authenticator path. An add-only authenticator instead resets and re-adds the surviving segments to rebuild the snapshot value.
Selecting an Authenticator A SEAL profile selects its snapshot authenticator with snap_id (): 0x0000 for none, or 0x0001 for the masked multiset hash.
None With snap_id = 0x0000 there is no snapshot authenticator: no snapshot value is produced (Na = 0), snapshot() and verify() are no-ops, and a mutable object rests on per-segment authentication alone. Such a profile MUST NOT produce the empty object (n_seg = 0). With no snapshot value to bind the zero count, a truncation that removed every segment would be indistinguishable from a legitimate empty object, so a valid object always has at least one segment ().
Masked Multiset Hash With snap_id = 0x0001 the 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_tag_label = "snapshot_tag", and snapshot_mask_label = "snapshot_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. An object with n_seg = 0 is a valid empty object. It holds the salt, the commitment, and the snapshot value, 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 is not a fixed constant but a masked authenticator over zero segments: An empty object is distinct from a zero-length plaintext, which is one final segment (n_seg = 1) whose plaintext has length 0. To rewrite segment i without re-reading the other tags, the writer first recovers the accumulator from the stored snapshot by removing the mask, acc = wrapped_acc XOR snapmask(n_seg, snapshot_tag). 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 value over the unchanged count. The wrapped_acc and snapshot_tag MUST come from locally trusted snapshot 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 with the snapshot tag, a message authentication code (MAC) under snap_key with its own label: Write snapshot_tag = snaptag(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 synthetic tag rather than by a fresh nonce, and XORs it into the accumulator to form the masked accumulator wrapped_acc: Seeding the mask with the synthetic tag 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 published accumulator is hidden behind a one-time pad (). The count n_seg is not stored in the snapshot value. The verifier supplies it as the number of segments present, and snaptag binds it under the MAC. The masked multiset hash stores wrapped_acc and snapshot_tag, each Nh octets, so Na = 2*Nh. defines Na in general. As a function of the count and accumulator, the snapshot value is The snapshot tag binds n_seg and the accumulator under snap_key, and the mask hides the accumulator behind a tag-derived one-time pad. The forgery bound and the masking argument are in and . SnapVerify runs only after the verifier has re-derived and checked the commitment as part 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 or any value derived from it, and MUST NOT signal through an error code or timing whether the snapshot tag matched while the masked accumulator did not. The mask hides the accumulator only against a one-bit verifier: exposing it, or distinguishing a tag-valid accumulator-mismatch from a plain reject, reinstates the recombination attack of . A modified tag or count changes the recomputed snapshot, and a different key or parameter context fails the commitment check that precedes SnapVerify (). The forgery bound is in and the rollback limitation in .
Segment Algorithms The construction defines the per-segment subroutines EncryptSegment, DecryptSegment, and RewriteSegment. In this random-access construction, is_final is an explicit input to each subroutine. Full-message encryption derives it from the total segment count n_seg, while random-access decryption and rewrite callers supply it directly. The full-message procedures (, , ) and the rewrite procedure () compose them. Each subroutine is the cryptographic core of one operation of the base or extended raAE interface (, ), refining the operation-level mapping of to the signature level. The primitive's position identifier p = (i, b) appears here as the explicit arguments i and is_final. Its immutable state S is realized by the payload schedule: the segment_key(i), nonce(i), and segment_aad calls below read the schedule from context rather than taking S as an argument. Its message segment M_i is the plaintext P_i, and its opaque ciphertext segment C_i is stored as the field triple (nonce_metadata(i), ct_i, tag_i). Segment subroutines and the primitive operations they realize
Subroutine Realizes Composed by
EncryptSegment EncSeg ,
DecryptSegment DecSeg
RewriteSegment the encryption core of RewriteSeg and , which add the snapshot bookkeeping
These subroutines emit ct_i and tag_i as separate fields, and ct_i has length len(P_i), which can be shorter than segment_max. The consuming format conveys each segment's ciphertext length to the decoder so DecryptSegment can recover the two fields, as required by . In every subroutine, i is the segment index (a non-negative integer), is_final is 1 for the last segment and 0 for all others, A_i is the caller-supplied associated data for segment i, and P_i is the segment plaintext. The subroutines call segment_key(i) and nonce(i) as defined in , with nonce(i) following the chosen nonce_mode, and segment_aad(i, is_final, A_i) as defined in . nonce_metadata(i) denotes the stored nonce metadata for segment i: nonce(i) when nonce_mode is "random", and empty when it is "derived". In random mode DecryptSegment reads its nonce from nonce_metadata_i, and in derived mode it recomputes nonce(i).
EncryptSegment AEAD.Encrypt and AEAD.Decrypt are the interfaces of Sections 2.1 and 2.2. For the AEADs in the tag is the final Nt octets of C_i, so ct_i is the first len(P_i) octets and C_i = ct_i || tag_i. EncryptSegment splits C_i at that boundary, and DecryptSegment reassembles it. The caller folds tag_i into the snapshot authenticator with add(i, tag_i) (). EncryptSegment itself does no snapshot work.
DecryptSegment DecryptSegment returns the segment plaintext, or a decryption error:
RewriteSegment RewriteSegment assumes the caller has already verified the commitment or otherwise confirmed it holds the correct CEK. A rewrite under the wrong key produces unreadable ciphertext and corrupts the snapshot authenticator's state. The error is detectable only on a subsequent read. RewriteSegment(i, is_final, A_i, new_P_i) is defined as EncryptSegment(i, is_final, A_i, new_P_i): a rewrite is a fresh encryption of the new plaintext new_P_i. The output (new_nonce_metadata_i, new_ct_i, new_tag_i) replaces the stored nonce metadata, ciphertext, and tag for segment i. RewriteSegment produces the replacement ciphertext and tag only. The caller updates the snapshot authenticator by reading the stored old tag and calling remove(i, old_tag_i) then add(i, new_tag_i) ().
Top-level Algorithms The top-level algorithms compose the segment subroutines () over complete messages. They call the snapshot-authenticator operations of (add(i, tag), remove(i, tag), set_length(n), snapshot(), and verify()) without referring to how any is computed. The authenticator selected by snap_id () realizes those operations. For the masked multiset hash they reduce to the accumulator, snapshot-tag, and mask formulas of . These procedures do not expose per-segment associated data, so they pass an empty A_i to each subroutine. An application that needs per-segment A_i calls the subroutines directly.
Read-Only Operations Encryption and decryption are available in every SEAL profile. They write a message once and read individual segments. Neither rewrites a stored segment. When the profile configures no snapshot authenticator (snap_id = 0x0000, ), the snapshot steps below are omitted, and a reader relies on per-segment authentication alone.
Encryption Encryption runs in two phases. The first phase derives the per-message schedule and writes the commitment. The second encrypts each segment independently and, under a snapshot authenticator, adds its tag with add(i, tag). Then snapshot() binds the whole set into the stored snapshot value. Because the segments are independent, the second phase may run in any order or in parallel.
Key Schedule and Segment Encryption CEK, salt payload schedule v v commitment payload_key snap_key EncryptSegment(i, P_i) using payload_key (one per segment) ct_i, tag_i
The per-segment tags then feed the snapshot authenticator, which adds each one and binds them into the snapshot value (). An application that writes a new message MUST generate a fresh, uniformly random salt. Given a CEK, that salt, a parameter set, G, and a plaintext P split into segments P_0 through P_{n_seg-1}: A zero-length plaintext produces a single segment of length 0 with is_final = 1.
Decryption of Segment i Opening a segment is a local operation: check the commitment to reject a wrong key early, then AEAD-decrypt the one segment. This yields per-segment authenticity over the ciphertext core, the segment index, and the finality bit. Under a snapshot authenticator (snap_id != 0x0000), whole-set authenticity is a separate and stronger check that requires every tag. It detects any added, dropped, reordered, or re-marked segment, and same-index rollback to an older sibling. A reader holding only one segment gets per-segment authenticity but MUST NOT claim snapshot integrity until it runs SnapVerify (). A profile with no snapshot authenticator (snap_id = 0x0000) defines no snapshot, so per-segment authenticity is the whole integrity guarantee. Given the CEK, salt, parameter set, G, segment index i, finality status, and the stored ciphertext segment for index i: Here SnapVerify is the three-argument SnapVerify(S, segments, snapshot) of , with S the derived schedule and segments the present (index, tag) pairs. SnapVerify needs every tag, so a reader that streams segments in order cannot gate their release on snapshot integrity without first buffering all tags or using a layout that carries the tags in a header. Delivering on per-segment authenticity alone forgoes snapshot freshness for that segment (). A streaming reader likewise cannot rule out truncation before the end of the stream: plaintext delivered before the highest-indexed segment verifies under is_final = 1, and before SnapVerify passes where a snapshot authenticator is configured, MUST be treated as unverified with respect to completeness. A decryptor MUST reject a truncated object, one whose highest-indexed segment does not carry is_final = 1. A run of segments 0 through k-1 whose last segment (index k-1) carries is_final = 0 is incomplete, and the decryptor MUST fail rather than return the partial plaintext. The check works because the application supplies the segment count n_seg, from which the decryptor derives the finality each segment must carry (). It then verifies the final segment under is_final = 1. A truncated object, whose last surviving segment was written as non-final, fails that verification. The finality bit is bound per segment and is unforgeable without the CEK: in derived nonce mode it occupies the low bit of the segment nonce (), and in random nonce mode it is bound through segment_aad (). An adversary therefore cannot re-mark a non-final segment as final and can only drop trailing segments, which this check detects. Authorized truncation by the CEK holder re-encrypts the new final segment under is_final = 1 with a fresh nonce (), so a legitimately truncated object still ends with is_final = 1 and verifies. This check needs no snapshot authenticator. Truncation to an empty object is covered too. A profile with no snapshot authenticator forbids the zero-segment object, so a valid object always has at least one segment, and a decryptor MUST reject one that has none. Under a snapshot authenticator the snapshot binds the count, so the empty object (n_seg = 0) is a distinct authenticated state (). On a commitment mismatch the implementation MUST NOT proceed with decryption, SHOULD zeroize derived key material, and MUST return an error. Under a snapshot authenticator, when all segment tags are available (for example, a full read or an integrity audit), the reader MUST run SnapVerify () on the stored snapshot before delivering any plaintext, and MUST return an error if SnapVerify fails. With no snapshot authenticator there is no such check, and per-segment authentication stands alone. Decryption can fail in up to three distinguishable ways: Decryption failure conditions
Failure Cause
Commitment mismatch wrong key or parameters
AEAD verification failure corrupted or tampered segment
Snapshot mismatch segment set or count modified (snapshot authenticator only)
Implementations SHOULD report these as distinct error conditions for local diagnosis, but SHOULD return a single opaque error to untrusted callers to avoid leaking an oracle (for example, distinguishing "wrong key" from "tampered segment" over a network).
Rewritable Operations Rewriting and length change are available only in a mutable profile, which configures a snapshot authenticator (snap_id = 0x0001). Each re-encrypts only the segments whose tag changes and updates the snapshot over the new segment set. A caller that cannot recover a re-encrypted segment's plaintext cannot perform them.
Rewriting Segment i A rewrite touches exactly one segment and never reads another. Replacing a segment removes its old tag from the snapshot authenticator and adds the new one, then updates the snapshot over the unchanged count with snapshot(). The update trusts, rather than re-verifies, the stored snapshot state. The old tag is already stored alongside the old ciphertext, so no other segment is read or decrypted (). This single-segment update and the trust in stored snapshot state are properties of an updatable authenticator like the masked multiset hash, which folds the change in O(1). An add-only authenticator re-reads the surviving tags to rebuild on rewrite. The procedure is: In derived nonce mode the nonce for segment i is deterministic, so a rewrite reuses the same nonce under a key whose derivation context is identical. This is safe because a mutable profile that selects derived nonce mode requires an MRAE AEAD (AES-256-GCM-SIV). MRAE AEADs are designed to tolerate nonce reuse, degrading to equality leakage rather than plaintext recovery, within the per-segment rewrite limit in . The snapshot update proceeds identically. The stored snapshot cannot be validated during an in-place rewrite. Validation is SnapVerify (), which recomputes the authenticator from every segment's tag and so requires reading all tags. During a rewrite the application trusts the stored snapshot state, applies remove and add for the one changed segment, and produces the new value with snapshot(). Because it trusts that state, the writer MUST take it from locally trusted storage or run SnapVerify first. Otherwise a storage adversary can roll the stored snapshot back and have the writer rebuild on it, laundering the rollback into a snapshot that verifies going forward (). Full validation is a separate operation that an application performs when it has access to all tags (for example, on a full read or an integrity audit).
Changing Message Length An application that holds the CEK MAY change a stored message's length in either direction: appending new segments, or truncating to a prefix. The two directions share one shape. Exactly one retained segment, the old or the new terminal one, is re-encrypted to move the finality bit, with none re-encrypted when appending from the empty object or truncating to it. Every other changed segment is removed or added by tag without re-encryption, and the snapshot is updated over the new count (). Both reuse the existing salt: an application extending an existing message MUST reuse the salt from the object it extends. A fresh salt would change every payload schedule output and force re-encryption of the retained segments.
Append and Truncate Both directions share one shape (no terminal re-mark for the empty object): 1. re-mark the single terminal segment remove + add (new count) 2. update the boundary segments by tag remove or add (each) 3. update the snapshot snapshot() append (n_seg' = n_seg + k): terminal = old final n_seg-1 (is_final 1 -> 0); none if n_seg = 0 add IN the new segments n_seg..n_seg+k-1 truncate (n_seg' = m): terminal = new final m-1 (is_final 0 -> 1); none if m = 0 remove the discarded segments m..n_seg-1 0); none if n_seg = 0 add IN the new segments n_seg..n_seg+k-1 truncate (n_seg' = m): terminal = new final m-1 (is_final 0 -> 1); none if m = 0 remove the discarded segments m..n_seg-1 ]]>
0 truncate: t = m - 1 is_final: 0 -> 1 if a terminal segment t exists (n_seg >= 1 for append, m >= 1 for truncate): read salt, payload schedule, snapshot value, segment t (truncate also reads old_tag_j for discarded j in m..n_seg-1) P_t = plaintext of segment t (decrypt, or use if held) meta, ct, new_tag_t = RewriteSegment(t, is_final_t, empty, P_t) under the old count: remove(t, old_tag_t) else: (append from empty: no old terminal; the appended loop below marks the last new segment is_final = 1. truncate to m = 0: no segment remains, so nothing is re-marked.) truncate: for j in m .. n_seg-1: remove(j, old_tag_j) n_seg' = n_seg+k (append) or m (truncate) set_length(n_seg') if a terminal segment t exists: add(t, new_tag_t) append: for j in n_seg .. n_seg+k-1: meta_j, ct_j, tag_j = EncryptSegment(j, is_final_j, empty, P_j) add(j, tag_j) (is_final_j = 1 only for the last segment) snapshot = snapshot() store segment t and snapshot; append adds the new segments, truncate drops segments m..n_seg-1 ]]> Changing message length re-encrypts the terminal segment, except when truncating to the empty object (m = 0), where no segment remains. A caller that cannot recover that segment's plaintext cannot do it. Each add and remove takes the segment's stored tag, which already encodes that segment's is_final bit, so an implementation never tracks finality separately. A botched incremental update corrupts the snapshot authenticator's state silently, surfacing only at a later SnapVerify. An implementation MAY run SnapVerify over the new segment set immediately after a length change to catch this. A botched update yields a value that the from-scratch recomputation will not match, turning a silent corruption into a caught error. Both operations count against the same per-CEK AEAD usage budget as initial encryption (). Each re-encrypts one terminal segment, except a truncate to the empty object (m = 0), which re-encrypts none. In derived nonce mode the nonce for the re-marked segment is fixed by its index and finality bit. Re-marking flips the finality bit, so this nonce differs from the segment's previous one, but repeated length changes can make the same (index, finality bit) pair recur, and only an MRAE AEAD tolerates the resulting nonce reuse (). Applications that do not need length changes MAY simply forbid them. The salt-reuse requirement applies only when a length change is performed. An application that re-encrypts the entire content can generate a fresh salt and is not bound by the constraints in this section. Test vectors for the SEAL profile are provided in , and the serialization layouts are in .
SEAL Suites This section lists example algorithm suites for the SEAL construction. SEAL's concrete framing and procedures are defined in .
Algorithms SEAL defines the following AEAD algorithms. Each has a code point, a key size, a nonce size, a default nonce mode, and an epoch_length range. The key size Nk is 16 octets for AES-128-GCM and 32 octets for the other suites. All use a 16-octet authentication tag (Nt = 16). SEAL AEAD algorithms
Algorithm aead_id Nk Nn default mode epoch_length
AES-128-GCM 0x0001 16 12 random 0 to 63 (default 0)
AES-256-GCM 0x0002 32 12 random 0 to 63 (default 0)
ChaCha20-Poly1305 0x001D 32 12 random 0 to 63 (default 0)
AES-256-GCM-SIV 0x001F 32 12 derived 0 to 63 (default 0)
AEGIS-256 0x0021 32 32 random 63
AEGIS-256X2 0x0024 32 32 random 63
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 early allocations that firm up when that I-D is published as an RFC. The 96-bit-nonce AEADs (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305) and the MRAE AES-256-GCM-SIV (in derived nonce mode) rotate the segment key and may set epoch_length anywhere in 0 to 63. The 256-bit-nonce AEADs (AEGIS-256, AEGIS-256X2) use a flat key (epoch_length = 63, one epoch key covering every segment). gives the per-suite budgets that fix these ranges. The default nonce_mode column gives each AEAD's mode in the mutable profile, SEAL-RW-v1. The immutable profile, SEAL-RO-v1, instead pairs a derived nonce with any of these AEADs, because its write-once rule keeps every derived nonce unique and needs no MRAE AEAD (). 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 SHA-3 family selected by . 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 Snapshot value
0x0000 none none produced
0x0001 masked multiset hash snapshot, per
snap_id = 0x0000 selects no snapshot authenticator: no snapshot value is produced and a reader relies on per-segment authentication alone. An immutable (write-once) profile enforces snap_id = 0x0000. A profile that supports rewrite requires snap_id = 0x0001, so every rewritable object carries whole-object integrity (). 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". Under snap_id = 0x0001 the snapshot authenticator is the masked multiset hash (), with wrapped_acc and the snapshot tag each an Nh-octet value, so Na = 2*Nh.
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 two named profiles, SEAL-RW-v1 and SEAL-RO-v1. 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 snap_id 0x0001 (the masked multiset hash), so every rewritable object carries whole-object integrity, and permits a random nonce or a derived nonce with an MRAE AEAD. It supports rewrite, extend, and truncate, and carries SEAL's snapshot machinery: the accumulator, its mask, the snapshot value, and SnapVerify. Unauthorized truncation surfaces at two points: the terminal finality check of , and SnapVerify over the complete segment set, which also binds the segment count. SEAL-RO-v1 is the immutable profile (read-only). Here "immutable" names the writer's write-once discipline, not a tamper-evidence guarantee. It selects a derived nonce and sets snap_id to 0x0000, so that no snapshot authenticator runs, and it is write-once: an encryptor MUST NOT rewrite a segment once it has been written. The rule is load-bearing: a rewrite would repeat the segment's derived nonce, with the consequences given in . Because each derived nonce is then used only once, the profile works with any AEAD, including a non-MRAE one. See . SEAL-RO-v1 provides per-segment confidentiality and integrity, binding the segment index and the finality bit, and key commitment through the commitment field, but not snapshot or whole-object integrity. Whole-object integrity, when needed, comes from the snapshot in the mutable profile or a layer above SEAL. Truncation detection 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 0x0001 rewrite/extend/truncate
SEAL-RO-v1 derived 0x0000 write-once
An encryptor MUST set payload_info to a (nonce_mode, snap_id) tuple that is valid for its protocol_id, and a decryptor MUST reject any object whose tuple is not. A derived nonce under SEAL-RW-v1 requires an MRAE AEAD; SEAL-RO-v1 admits any AEAD because the write-once rule keeps 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. It carries snap_id 0x0001, so a reader detects tampering with the current segment set as a whole: any added, dropped, reordered, or re-marked segment, a same-index rollback, or a count change (). Whole-object freshness beyond replay still comes from a layer above SEAL (). A derived nonce under this profile requires an MRAE AEAD, while a random nonce works with any of the suites. SEAL-RO-v1 (immutable) fits write-once content: archives, backups, content-addressed blobs, and write-once media. It stores no per-segment nonce and works with any AEAD, so it is the smaller and simpler choice when content is never rewritten. Whole-object integrity, if needed, comes from a layer above SEAL. covers epoch_length selection, and covers the per-AEAD trade-offs that further narrow the suite.
Serialization Layouts This section describes three serialization layouts a consuming protocol can use to store raAE output: linear, aligned, and split. 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.
Linear Layout In a linear layout the salt, commitment, snapshot value, 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 snapshot value (Na octets), the configured authenticator's output, precedes the segment data so a streaming reader has it before the segments and can check it 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 zero segments, so no segment is final.
Linear Layout salt commitment snapshot segment ... segment (32) (Nh) (Na) 0 data n_seg-1 [nonce] [nonce] ct + tag ct + tag
Brackets mark the nonce, which precedes the ciphertext and tag for a segment and is stored only in random nonce mode. In derived nonce mode (AES-256-GCM-SIV) the nonce is recomputed from the key schedule, so no nonce is stored. 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. A writer emits the salt, commitment, and a placeholder for the snapshot value, then streams segments. After all segments are written the writer seeks back to the snapshot position and writes the final value in place.
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; the ciphertext follows the header.
Aligned Layout prefix (consuming protocol machinery arbitrary length; not specified here) header: salt, commitment, snapshot, per-segment metadata (broken out below) leading slot: either the first ciphertext segment (< B), or zero padding to a multiple of B ciphertext segment (= B) ... final ciphertext segment (<= B)
Offsets are measured from index 0, the start of the prefix. Let B = segment_max and let H be the offset at which the ciphertext begins (the prefix length plus the header length). The leading slot, from H up to the first segment boundary M * B, is filled in one of two ways, chosen before writing:
  • No padding: the first ciphertext segment occupies the slot, with M = ceil(H / B). It is shorter than B and ends on the boundary M * B.
  • Padding: the slot is zero-padded to a multiple of B, with M >= ceil(H / B) (the next boundary, or a larger multiple to reserve whole segment slots for append headroom).
From M * B onward every ciphertext segment begins at a multiple of B and is a full B octets, with the final segment at most B. H, M, 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 snapshot value, and one metadata entry per segment:
Aligned Layout Header salt commitment snapshot per-segment metadata (32) (Nh) (Na) (n_seg * meta_len)
Each metadata entry holds the segment's stored nonce and its AEAD tag:
Metadata Entry [nonce(i)] tag(i) (Nn) (Nt = 16)
The bracketed nonce is present only in random nonce mode. The tag is always present, Nt = 16 octets in every SEAL suite (). Each metadata entry holds the Np-octet presented nonce and the Nt-octet tag, so meta_len = Np + Nt octets. A random-nonce entry sets Np = Nn and is Nn + Nt octets. A derived-nonce entry recomputes the nonce from the key schedule, so Np = 0 and the entry is Nt octets. The per-suite values 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 is 32 + commitment_length + Na + n_seg * meta_len octets. With the default commitment_length = Nh and the masked multiset hash's Na = 2 * Nh, the header is 32 + 3 * Nh + n_seg * meta_len octets. A reader verifies the commitment and the snapshot value from the header alone, then seeks to any segment using these offsets. Because the snapshot is computed from the per-segment tags alone (the snapshot authenticator takes the segment tag, not the ciphertext), and the header holds every tag in its metadata entries, a reader authenticates the whole object's snapshot from the header without reading or streaming any ciphertext. This supports efficient random-access reads.
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 * B. The metadata stream holds the salt, the commitment, the n_seg per-segment metadata entries (each meta_len octets, broken out in ), and the snapshot value last. Because the snapshot is computed from the per-segment tags alone () and every tag lives in the metadata stream, a reader authenticates the snapshot by reading only the metadata stream, never the data stream that holds the ciphertext.
Split Layout data stream: seg 0 ct (= B) seg 1 ct (= B) ... seg n_seg-1 (<= B) metadata stream: salt commitment meta_0 ... meta_last snapshot (32) (Nh) (meta_len) (meta_len) (Na)
Because neither stream embeds the other, both grow by appending. Extending a message appends one ciphertext segment to the data stream, appends one metadata entry to the metadata stream, and rewrites the trailing snapshot value. Truncating drops the tail of each stream and rewrites the snapshot value. Neither operation shifts an existing ciphertext segment, which the in-place aligned layout cannot avoid once the header grows.
Immutable-Profile Layouts Under an immutable profile (SEAL-RO-v1: snap_id = 0x0000 with a derived nonce), two fields drop out of the layouts above. No snapshot authenticator runs, so there is no snapshot value, and each nonce is recomputed from the key schedule, so Np = 0 and no nonce is stored. A metadata entry is then 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 headers reduce to 32 + commitment_length + Nt * n_seg octets, the salt and commitment followed by one tag per segment. 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, with no shared snapshot to read or maintain.
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
Name Profile segment_max nonce_mode epoch layout
SEAL-attachment SEAL-RO-v1 65536 derived 32 linear
SEAL-simple SEAL-RW-v1 65536 random 16 linear
SEAL-memory SEAL-RW-v1 16384 random 16 aligned
SEAL-disk SEAL-RW-v1 16384 random 16 split
SEAL-compact SEAL-RW-v1 16384 derived 16 aligned
Each instantiation is named for its primary use case, described below. The snapshot authenticator follows the profile: SEAL-RO-v1 sets snap_id 0x0000 and SEAL-RW-v1 sets snap_id 0x0001 (). Every instantiation uses commitment_length = Nh and a fresh 32-octet salt per object (). The epoch_length is the value in the table. The write-once SEAL-attachment performs no rewrites, so it takes a larger epoch (32), while the four mutable schemes take a conservative 16 that leaves the per-epoch-key budget headroom for rewrites, which reuse the epoch key (). A 256-bit-nonce suite (AEGIS-256, AEGIS-256X2) uses a flat key (epoch_length 63) regardless of the row (), and a referencing protocol MAY override the epoch. Each instantiation binds the layout named in its row (). The layout fixes field order and placement, and the consuming protocol pins the remaining serialization details, such as the aligned layout's prefix and leading slot, for byte-level interoperability. SEAL-compact is mutable with a derived nonce, so an in-place rewrite reuses that nonce, which requires an MRAE AEAD (). The write-once SEAL-attachment and the random-nonce SEAL-simple, SEAL-memory, and SEAL-disk admit any AEAD. SEAL-attachment is for write-once content read whole. It carries no snapshot authenticator, because under the immutable profile per-segment authentication and the finality bit detect truncation, reordering, and tampering on a whole-object read, and write-once leaves no earlier version to roll a segment back to (). Its linear layout takes the reduced immutable form (). SEAL-simple 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 the aligned layout with a derived nonce. Like SEAL-memory it stores each segment at a fixed offset for random access, but the derived nonce is recomputed rather than stored, so each per-segment metadata entry is Nt octets instead of Nn + Nt (). Because that region scales with the object, removing the stored nonce saves Nn octets per segment, a substantial part of the metadata for the large random-access objects the aligned layout targets. It reuses the derived nonce on an in-place rewrite, so it requires an MRAE AEAD and the rewrite is deterministic.
Security Analysis This section states the construction's target security properties, the assumptions its components must satisfy, and the operational limits on its use, but does not reproduce the formal proofs. The division of labor is deliberate. The ra-ROR and ra-CMT notions are taken unchanged from , whose proofs apply to SEAL's realization of the base interface. Snapshot integrity is the one notion this document defines. argues its bound, and integrating that argument into a combined proof is deferred to , the companion formal write-up, in preparation, that this document cites for every deferred proof. The limits of are operational deployment bounds, not proof obligations. The security notions are defined in .
Operational Summary The construction provides the following properties against an adversary that observes ciphertexts, tampers with stored segments or their order, and attempts decryption with chosen keys, but does not know the CEK or per-content salt:
Confidentiality:
The construction targets ra-ROR (): the adversary learns nothing about the plaintext beyond what the underlying AEAD already permits. The adversary observes the message's segment count and the per-segment lengths from the wire format. Segment boundary metadata is not confidential.
Integrity:
A reader that runs snapshot verification, including its index-set check over the correct segment count n_seg (), detects any added, dropped, reordered, or re-marked segment, including same-index rollback to an older valid segment. Per-segment AEAD verification alone detects modification of individual segments and relocation of a segment to a different index, but reverting a segment to a previous version at the same index is not detected. Snapshot verification realizes the snapshot integrity notion of . Replacement of the entire message with a previous valid version under the same CEK is not detected, even when performing snapshot verification. Rollback resistance at the message level is the application's responsibility ().
Context commitment:
A reader that verifies the commitment () rejects a wrong CEK, parameter context, or global associated data before decrypting any segment, per the ra-CMT notion (). Commitment to segment positions is out of scope. See for that gap and its non-normative mitigations.
Rewrite safety:
An individual segment can be rewritten in place under the same CEK without re-derivation of other keys, provided the per-key AEAD usage budget () is not exceeded. A rewrite reuses the segment's derived nonce, so in derived nonce mode it MUST use an MRAE AEAD (). Rewrite safety is otherwise a corollary of ra-ROR and snapshot integrity ().
Out of scope:
Atomicity of writes (the application MUST use write-ahead logging or copy-on-write); confidentiality of segment count or layout; traffic-analysis resistance; side channels in the application's storage layer; protection of the CEK before encryption or after decryption.
Security Notions raAE has two security tiers. The base tier comprises the two notions inherited from , ra-ROR and ra-CMT, summarized here. The extension tier adds one notion, snapshot integrity, defined by this document. A construction MAY provide the base tier only. Advantage definitions and proofs for ra-ROR and ra-CMT are in .
ra-ROR ra-ROR (random-access real-or-random) is the joint confidentiality and authenticity notion for raAE in a multi-user, nonce-respecting setting. An adversary with adaptive encryption and decryption access across many key instances, sessions, and arbitrary positions cannot distinguish real ciphertexts and headers from random, and cannot make an out-of-context ciphertext segment decrypt. The game is defined in . The encryption core of the extension operations is ordinary EncSeg. A RewriteSeg produces its replacement ciphertext as a repeated EncSeg at the same position, and appending is EncSeg at fresh positions plus one RewriteSeg of the old final segment. In random nonce mode these draw fresh nonces and stay within the nonce-respecting ra-ROR game. In derived nonce mode a rewrite reuses the position's derived nonce. This is a deliberate nonce-repeating query. The underlying MRAE AEAD handles it under the equality-leakage relaxation that derived nonce mode documents (), not the unmodified nonce-respecting game. These operations also maintain a snapshot value. That value is outside the syntax. It is governed not by ra-ROR but by the snapshot integrity notion of .
ra-CMT ra-CMT (random-access context commitment) is the segment-level commitment notion: no single ciphertext segment decrypts successfully under two different decryption contexts (key, nonce, global associated data, and per-segment associated data). In the position-respecting variant ra-CMT the two contexts share a position. The ra-CMT-p variant lets the adversary choose the positions freely. Because the scheme is random access, committing one segment's context commits the full ciphertext's context. Both game variants are defined in . ra-CMT is distinct from the per-AEAD notions CMT-1 and CMT-4 of : a scheme can achieve ra-CMT through an external commitment mechanism even when its underlying AEAD commits to nothing. The Invisible Salamanders attacks () show what a non-committing AEAD permits, and frames it as a key-commitment failure with fixes.
Snapshot Authentication Per-segment AEAD authenticates a segment at its position, but it does not authenticate the current object snapshot: which set of segments belongs to the current stored object state. An adversary with write access to stored segments can silently substitute an old valid same-index segment or delete a segment, and per-segment AEAD verification at each presented segment still passes. (A segment moved to a different index fails its AEAD check through the index binding of .) Snapshot authentication covers that set. The resulting notion, snapshot integrity, is the one this document adds. The construction that realizes it is in , its bound is in , and the supporting reduction is in . A combined formal treatment with the ra-ROR framework is in preparation (). A construction MAY omit snapshot integrity, providing only the per-segment guarantees and ra-CMT. SEAL provides it under a snapshot authenticator (snap_id != 0x0000) and omits it otherwise ().
Relations to Other Notions
AEAD ():
raAE generalizes AEAD to multi-segment content with arbitrary-order encryption. A single-segment raAE is an AEAD.
nOAE2 ():
nOAE2 is the nonce-based online authenticated encryption notion for schemes that encrypt in order and support random-access decryption. Hoang and Shen introduced nOAE2 in their analysis of Tink Streaming AEAD (), where they also show STREAM satisfies it. ra-ROR is strictly stronger: every ra-ROR-secure scheme is nOAE2-secure when used in order, but nOAE2-secure schemes can fail when encryption order is arbitrary ().
Commitment ():
CMT-1 and CMT-4 () are per-AEAD commitment notions. ra-CMT is the corresponding notion for segmented random-access schemes. See .
Rewrite safety and extension safety are corollaries of the notions above, not additional notions. Replacing a segment in place is an EncSeg at an already-used position together with a snapshot update. In random nonce mode it adds no adversary capability beyond ra-ROR () and snapshot integrity (). In derived nonce mode the rewrite repeats the segment nonce, so it MUST use an MRAE AEAD (), and it adds the equality-leakage relaxation that derived nonce mode already documents (). Each rewrite also counts against the per-key AEAD usage budget (). Appending and truncating likewise add no algorithm () and no notion. An adversary's ability to add, drop, reorder, or re-mark a terminal segment is exactly the snapshot integrity adversary of , and detection follows from the index and finality binding of together with snapshot verification. Rollback of the whole object to an earlier honest (state, snapshot) after truncation is the freshness case that snapshot integrity excludes (). The application supplies it.
Adversary Model and Assumptions The adversary model is that of the ra-ROR game (, ). In the construction's terms: the adversary can observe all ciphertexts and content metadata, tamper with individual segments or their ordering, replace the snapshot value, and attempt decryption with chosen keys. The adversary does not know the CEK, any derived key, or the per-content salt. Every bound in this section assumes the CEK is secret and uniform: an application MUST supply a CEK that is either generated uniformly at random or derived so that it is computationally indistinguishable from uniform, such as the output of a KDF keyed by a secret. When multiple messages share a CEK, the per-content salt separates payload schedule outputs across messages under the PRF assumption. The multi-message advantage grows linearly in the number of messages. The construction claims the properties below against this adversary. The persistent state of an raAE object, and the party that owns each item, is:
CEK:
Secret key-management state. It is the root secret for the object.
salt:
Stored object metadata. It separates objects under one CEK.
parameter set:
Profile or object metadata. It fixes suite, maximum segment size, and epoch policy.
commitment:
Stored object metadata. It rejects wrong key or parameter context before decryption.
segment metadata:
Storage-format state. It holds AEAD tags and, in random nonce mode, per-segment nonces.
snapshot:
Stored object metadata. It authenticates the segment tag set and segment count.
external freshness state:
Consuming-protocol state. It detects whole-object rollback.
The security argument relies on three distinct assumptions about the KDF. For derivations whose input keying material is secret and uniformly random, including payload_key, snap_key, nonce_base, epoch_key, and the snapshot authenticator's keyed derivations, the KDF is assumed to be a multi-user PRF with domain separation by protocol_id and label. For commitment, the function is additionally assumed to be collision resistant over adversarially chosen tuples (CEK, payload_info, G), with G empty by default. PRF security alone is not sufficient for this property, because the commitment adversary may choose the CEK and context values. For the plaintext-bound nonce construction, the plaintext digest step targets collision resistance, not PRF security. For the HKDF cipher suites (HKDF-SHA-256, HKDF-SHA-384, and HKDF-SHA-512), the PRF assumptions are placed on HKDF keyed by the CEK or payload_key, and the collision-resistance assumption on the commit derivation reduces to the collision resistance of the underlying SHA-2 variant (SHA-256, SHA-384, or SHA-512). Because every SEAL KDF output is at most Nh octets, HKDF-Expand makes a single HMAC call per derivation. The extractor-then-PRF analysis of HKDF is in . For TurboSHAKE-256 (the one-step XOF cipher suite defined in ), the same PRF and collision-resistance assumptions are placed on the XOF as instantiated by that HPKE KDF registry entry, which fixes the primitive and its parameters but carries no security assumptions of its own.
raAE Construction Requirements The bounds below rely on properties of the construction's components, namely the KDF framing and the snapshot authenticator. The requirements those components MUST satisfy are obligations on the raAE construction, not part of the raAE primitive of . A profile selects the concrete framing for every derivation surface: the KDF input assembly (), the payload_info construction (), the segment AAD (), and the snapshot authenticator's keyed inputs (). The requirements below are the contract that any such framing MUST meet. SEAL is one such framing (, ). The per-component requirements any raAE construction must satisfy are as follows.
Pseudorandomness:
KDF outputs MUST be computationally indistinguishable from random to an adversary that does not know the ikm, assuming the underlying hash or PRF is a secure pseudorandom function.
Injectivity:
The construction MUST define the encoding of the tuple (protocol_id, label, ikm, info, L) into the underlying primitive input, and that encoding MUST be injective: distinct tuples MUST map to distinct primitive inputs. This is a requirement on the encoding, not on the KDF. The KDF need not itself be injective, because injectivity is supplied by the encoding placed in front of it. ikm and info MUST be unambiguously separable in the encoded input, whatever the number of elements each contains. The two-step form binds ikm and info in its separate Extract and Expand inputs. The one-step form frames ikm and info each as a single encode element. Where the encoding admits inputs too large to encode literally, it MAY substitute a fixed-length digest of the over-large field. The encoding is then injective only up to the collision resistance of that digest, which the construction MUST justify and domain-separate from the literal encoding ().
Label uniqueness:
Each derivation role, including commitment, payload key, snapshot authenticator key, nonce base, epoch key, segment nonce, hedged key, and the authenticator's internal roles, MUST use a distinct label string within each protocol version.
Protocol binding:
The protocol_id MUST appear as a distinct component of the KDF primitive input. Different application protocols using the same AEAD and KDF MUST use different protocol_id values to ensure that derived values from one protocol cannot be confused with those from another.
Output length commitment:
The requested output length L MUST be part of the KDF primitive input. This prevents attacks in which an adversary attempts to use a truncated version of a longer derived output as a valid shorter one.
Cross-role isolation:
A KDF output for one derivation role, such as payload_key, MUST be computationally independent of the output for any other role, such as snap_key, even when derived from the same CEK and payload_info. This property follows from label uniqueness and PRF security of the underlying primitive.
Snapshot authenticator:
The construction MUST bind the current set of segment tags and the segment count into a public snapshot value that an adversary without the authenticator's secret key cannot forge for a modified set of tags or count, even after observing snapshot values and their deltas across rewrites. How the value is computed, and whether a single-segment change updates it in place or rebuilds it, is the authenticator's choice. SEAL's snapshot authenticators are in .
SEAL's construction () satisfies these requirements. Its KDF (), any of the cipher suites in keyed by the CEK, is modeled as a pseudorandom function. Its encode framing () is injective and places protocol_id and the output length L in the primitive input, so injectivity, protocol binding, and output-length commitment hold. SEAL's labels (, the masked multiset hash's labels in , the plaintext-bound construction's labels in , and the hedged-randomness label in ) are distinct, giving label uniqueness and, with PRF security, cross-role isolation. SEAL's masked multiset hash () satisfies the snapshot authenticator requirement, with its forgery argument in . encode is injective. Among fields of at most 0xFFFE octets each frame entry is self-delimiting, so the concatenation parses uniquely regardless of the number of arguments, and distinct input tuples produce distinct output strings. For over-large fields the encoding is injective only up to the collision resistance of LH, not unconditionally: a literal entry carries a length prefix in the range 0x0000 through 0xFFFE while a digest entry carries the reserved prefix 0xFFFF, so a literal entry and a digest entry never collide, and a collision between two digest entries reduces to a collision in LH. A 0xFFFF entry is bind-only: it commits to the field but does not carry it, so a protocol that must recover a field from the encoding MUST keep that field at most 0xFFFE octets. No SEAL input approaches 0xFFFE octets, so for SEAL frame is byte-identical to a plain 2-octet length prefix and LH is never invoked. The "raAE-LP-v1" prefix (the HKDF-Extract salt in the two-step class, a fixed input prefix in the one-step class) is distinct from every protocol_id and label, so LH inputs are domain-separated from encode inputs. LH is a shared collision-resistant digest rather than a per-protocol separator: the same over-large field yields the same LH value in every protocol that reuses this combiner. Cross-protocol separation comes from protocol_id in the KDF inputs and from aad_label in the segment AAD, not from LH. A concrete SEAL suite specifies the following.
AEAD:
One of the algorithms from , with associated Nk, Nn, and Nt values.
KDF:
One of the KDF cipher suites from .
nonce_mode:
A per-object payload_info field constrained by the profile, not a suite-fixed lock. gives the default mode each suite uses in the mutable profile. A profile MAY select any valid (nonce_mode, snap_id) tuple (): in the mutable profile an MRAE AEAD MAY use either mode, and the immutable profile SEAL-RO-v1 pairs a derived nonce with any AEAD because write-once keeps every derived nonce unique.
epoch_length:
The key-rotation granularity, with range given by . Per , a 96-bit-nonce AEAD rotates the segment key to bound per-key nonce-collision risk and an MRAE AEAD rotates to bound its per-key encryption count, so both take epoch_length in 0 to 63. A 256-bit-nonce AEAD makes both negligible and uses a flat key.
segment_max:
One of the sizes from : 16384 or 65536 octets.
Fábrega et al. () proved ra-ROR and ra-CMT security for a construction that instantiates the same component contracts enumerated above, and SEAL's analysis of those notions follows the same structure. SEAL's additional components (the epoch keys and the snapshot maintained across rewrite and length change) are analyzed in and .
Segment Confidentiality and Integrity The construction targets ra-ROR security (). The ra-ROR advantage bound, its adversary parameters, and the per-term analysis are in , with the full proof in preparation (). This section states the property and the operational quantities a deployment needs. Ciphertext cores are indistinguishable from random under the ra-ROR definition, up to the public length leakage, the equality leakage allowed by derived nonce mode, and public metadata exposed by the consuming format (file-level headers, stored nonces in random mode, the salt, and the commitment). Each segment AEAD ciphertext binds the segment to its own index and finality bit (through segment_aad in random nonce mode and through the nonce in derived nonce mode) so an adversary cannot modify or substitute a segment under a given index, or flip its finality bit, without causing an AEAD verification failure on that segment. Same-index rollback to an older valid segment within the same message is not detected by per-segment AEAD alone. This requires the snapshot verification of . The multi-message advantage grows linearly in the number of messages. In derived nonce mode the salt-collision term q_m^2/2^256 is the only quadratic floor for the 256-bit-key suites. For AES-128-GCM the epoch-key collision floor E^2/2^128 () is an additional quadratic term that dominates. In random nonce mode, with or without the plaintext-bound hedge, the nonce-collision term is also quadratic: where q is the number of segment encryptions under one key and Nn is the nonce length in octets. The block-size birthday term is derived in . Segment size enters the analysis only through the forgery and block-size terms, both bounded in . It does not affect the confidentiality or commitment terms. A segment's length is authenticated implicitly by its AEAD tag, not through segment_aad or the nonce, so the analysis assumes the consuming format conveys each segment's true ciphertext length. Segments shorter than segment_max consume no more than their share of the per-key budget and need no separate accounting.
Commitment Security The ra-CMT notion is defined in . raAE's commitment target is ra-CMT (random-access context commitment), not the per-AEAD notion CMT-1 (). CMT-1 is key commitment defined for AEADs, but raAE is a higher-level construction whose commitment binds the CEK and the full payload_info, which together carry the full parameter context that affects encryption, decryption, AAD construction, nonce construction, and key derivation. ra-CMT relies on the collision resistance of the commitment derivation map over the tuple (protocol_id, "commit", CEK, payload_info, G, commitment_length), with G empty by default. PRF security alone does not suffice, because the commitment adversary may choose the CEK and the context values (). SEAL sets commitment_length = Nh, so the commitment offers about 2^128 collision-search work with HKDF-SHA-256 and about 2^256 with TurboSHAKE-256. The reduction outline for this assumption and the collision quantities for a general commitment_length are in . The commitment bounds the ra-CMT variant in which the positions match (). It does not bind the segment position. Position binding for the ra-CMT-p variant is inherited from the underlying AEAD's commitment level. Because the SEAL AEADs are not natively key-committing, position confusion under an adversarially chosen key is out of scope, consistent with . A malicious encryptor that controls the CEK can craft a single ciphertext segment that opens at two positions, and the per-segment AEAD tag does not prevent it. The per-segment associated data A_i is likewise outside the commitment: SEAL binds A_i through segment_aad and the AEAD tag for that segment. Contexts that differ only in A_i are therefore not commitment collisions. Their separation relies on AEAD commitment for the segment AAD. A_i is also rewritable across rewrites and is not bound at the snapshot level. An application that needs it bound there MUST bind it externally. The exact accounting of this term in the ra-CMT reduction is deferred to . A deployment that must defend against a malicious encryptor who controls the CEK can close the adversarial-key position gap by one of two changes. These are non-normative. SEAL adds none of them to the construction.
  • A context-committing AEAD, so that each segment ciphertext commits to its full decryption context rather than relying on the external commitment over (CEK, payload_info, G).
  • A per-segment collision-resistant position commitment, on the order of 16 to 64 octets per segment, bound alongside the segment so that no segment opens at two positions.
Several AEADs including AES-GCM () and ChaCha20-Poly1305 () lack strong native key or context commitment. CMT-4 () is full commitment to key, nonce, associated data, and plaintext. None of the SEAL AEADs is relied upon to provide CMT-1 or CMT-4. In particular, AES-256-GCM-SIV is not a key-committing AEAD, and key-commitment attacks against it are known (for example partitioning oracles). raAE obtains ra-CMT context commitment from the external commitment over (CEK, payload_info, G) regardless of the AEAD's own committing or non-committing properties, provided that the commitment check is not bypassed and that payload_info contains the full parameter context that influences any later derivation or AEAD operation. With commitment_length = Nh and Nt = 16, ra-CMT is bounded by the commitment collision resistance, and ra-CMT-p adds the per-segment AEAD commitment term. The ra-CMT collision bound is derived in , and the ra-CMT-p bound is stated there as a sum. The two key regimes differ. Under honestly generated keys the idealized per-pair tag-forgery floor is 2^(-128) because Nt = 16, and concrete per-AEAD authenticity bounds degrade with segment length (). Under an adversarially chosen CEK the position term is the AEAD's commitment level, which the SEAL AEADs are not relied upon to provide. The global associated data G () enters the committed map as an additional input, empty by default, and the collision-resistance argument above applies unchanged with G in the committed context. This matches the ra-CMT treatment of global associated data in . The ra-CMT and ra-CMT-p notions are defined in . SEAL realizes ra-CMT through the external commitment over (CEK, payload_info, G), independent of the underlying AEAD's own commitment level. Position binding for ra-CMT-p is inherited from the underlying AEAD's commitment level, as described above. This document states these properties and their component bounds. The exact accounting of the per-segment associated data and position terms in the ra-CMT-p reduction is the open item deferred to the proof in preparation ().
Snapshot Authenticator Security Snapshot authentication is an extension this document adds to the raAE framework. The raAE primitive and its ra-ROR and ra-CMT notions are taken unchanged from , whose proofs apply to SEAL's realization of the base interface. The snapshot authenticator adds two operations (RewriteSeg, SnapVerify) over an auxiliary snapshot value and one new security property, snapshot integrity (). Integrating its reduction into a single combined proof with the ra-ROR framework is in preparation and will be published separately (). Snapshot integrity is keyed by snap_key and protects the writer's current segment set against a storage or write adversary that does not hold snap_key. A verifier who holds snap_key, hence the CEK from which it is derived, detects any added, dropped, reordered, re-marked, or otherwise altered segment. It gives no protection among parties that share the CEK, because any CEK-holder can recompute snap_key, and it is not a third-party-verifiable commitment to a segment set. An application that needs sender attribution or third-party verifiability MUST add a signing layer over the snapshot context. Per-segment AEAD binds each segment's index and finality bit. The snapshot authenticator adds authentication of the full set of segment tags and the count n_seg as a single unit, which detects same-index rollback, segment-set modification, and count changes. The index-set check in SnapVerify () is mandatory: an authenticator's verify MAY accept a malformed index multiset, so without the check a duplicated or dropped index could pass. A profile MUST keep each of an authenticator's KDF labels inside the injective encode frame () so distinct roles cannot collide on the primitive input. Whole-object rollback to a previously valid snapshot is out of scope and is treated in . snap_key is not exposed through any public API. It is derived internally per message from the CEK and salt, so snap_key exposure is not a threat surface in the construction itself.
Masked Multiset Hash SEAL's masked multiset hash (snap_id 0x0001) publishes snapshot = wrapped_acc || snapshot_tag. The snapshot tag is a MAC over the count and accumulator under snap_key, and wrapped_acc is that accumulator hidden behind a deterministic, tag-derived one-time pad. The mask is what stops a write adversary from recombining the differences between published accumulators into a non-historical segment set. Its three labels, contrib_label, snapshot_tag_label, and snapshot_mask_label, are distinct under the encode frame. Its forgery advantage Adv_acc 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. states the bound and derives it.
Capacity and Usage Limits These usage limits are organized around independent limit classes, not around named suites. The accounting unit is one segment encryption under one segment-encryption key (an epoch key). For random-nonce AEADs that budget is a single per-epoch-key pool. For a derived-nonce MRAE AEAD (AES-256-GCM-SIV in SEAL) there are two separate budgets: a per-epoch-key budget for distinct derived nonces, and a per-derived-nonce budget for repeated encryption of one segment. Such an AEAD therefore does not follow a simple "divide the per-key budget by 2^epoch_length" model. The length-dependent limits in this section are computed at the suite's segment_max, the largest plaintext one segment encryption carries. Independent of these per-key budgets, a segment-encryption procedure MUST respect each underlying AEAD's per-invocation input limits.
Accounting Model One segment encryption consumes one write from a segment-encryption key's budget. Initial writes and rewrites are both segment encryptions. The budget belongs to the epoch key, not the CEK.
epoch-key budget:
the segment encryptions allowed under one epoch key.
write (initial write):
the first encryption of a segment.
rewrite:
a later encryption of the same segment.
epoch_length (r):
the base-2 log of the number of segments that share one epoch key.
For a random-nonce AEAD an epoch key has one budget, shared by the segments under it. For a derived-nonce MRAE AEAD an epoch key has two: how many distinct segment nonces it may cover, and how many times any one segment may be re-encrypted at its fixed nonce.
Limit Classes Six phenomena bound how much may be encrypted. Each is set by one property of the AEAD or the segment size, and each bounds confidentiality or integrity. Usage-limit classes
Limit class Applies to Depends on Failure mode
Random-nonce collision random nonce modes nonce size confidentiality
Forgery bound all AEADs MAC strength, segment size integrity
Block-size birthday block-cipher AEADs total blocks confidentiality
MRAE distinct-nonce derived-nonce MRAE across segments derived-nonce count confidentiality and integrity
Fixed-nonce data volume derived-nonce hot rewrites segment size, rewrites confidentiality
Epoch-key collision 128-bit-key AEADs key size confidentiality
Random-nonce collision and the block-size birthday bound the confidentiality of fresh-nonce encryption, and forgery bounds integrity for every decryption. Two further classes apply only in derived-nonce MRAE mode: a derived-key collision across the distinct segment nonces under an epoch key, and a data-volume limit on repeated encryption of a single hot segment, one rewritten many times at its one derived nonce. A sixth class applies only to 128-bit-key AEADs: a collision across the distinct epoch keys that holds the number of epoch keys per payload_key below about 2^48 ().
Binding Limits for Profiled Suites For each profiled suite the binding limit is the smallest applicable class. At 65536-octet (64 KiB) segments and a 2^-32 advantage target: Binding limits for profiled suites at 64 KiB
Suite / mode Binding limit Budget Failure mode
AES-128-GCM, random random-nonce collision ~2^32 per epoch key confidentiality
AES-256-GCM, random random-nonce collision ~2^32 per epoch key confidentiality
ChaCha20-Poly1305, random random-nonce collision ~2^32 per epoch key confidentiality
AES-256-GCM-SIV, derived, distinct segments MRAE distinct-nonce ~2^48 per epoch key confidentiality and integrity
AES-256-GCM-SIV, derived, hot segment fixed-nonce data volume ~2^36 per segment at 64 KiB confidentiality
AEGIS-256, random forgery bound ~2^83 per key integrity
AEGIS-256X2, random forgery bound ~2^83 per key integrity
The 96-bit-nonce suites bind on random-nonce collision. AEGIS makes nonce collision negligible with a 256-bit nonce (~2^112) and binds on forgery. A derived-nonce MRAE AEAD has the two limits above, the distinct-derived-nonce ceiling and the fixed-nonce data-volume cap, not a single shared pool.
Maximum Write-Once Object Size Two limits bound a write-once object: each epoch key's AEAD write budget, and the 2^63 segment index ceiling. Under a flat key (one epoch key for the whole object), the AEAD budget sets the size: Flat-key write-once size limit
Suite Flat-key write-once limit
AES-128-GCM, AES-256-GCM ~2^36 segments
AES-256-GCM-SIV ~2^48 segments
ChaCha20-Poly1305, AEGIS-256, AEGIS-256X2 2^63 segments
For the block ciphers this limit is a confidentiality bound. The AES-GCM suites (AES-128-GCM and AES-256-GCM) bind on the block-size birthday and AES-256-GCM-SIV on the distinct-derived-nonce budget. ChaCha20-Poly1305 and AEGIS have no write-count confidentiality bound below the index ceiling. The AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305 figures assume derived nonce mode, which these non-MRAE suites may use only in a write-once profile. In the default random nonce mode they bind earlier, at the random-nonce-collision budget of about 2^32 per epoch key (). With epoch rotation each epoch key carries a fresh budget, so any suite can reach the 2^63-segment ceiling, about 2^79 octets at 64 KiB segments. For AES-128-GCM this requires a sufficiently large epoch_length. At epoch_length 0 its epoch-key collision floor caps the object near 2^48 segments (). Reaching 2^63 needs epoch_length at least 15, so the distinct epoch keys stay near 2^48. A rotating profile MUST keep each epoch key's 2^epoch_length initial writes within its per-key budget. For a derived-nonce MRAE AEAD that means 2^epoch_length below the distinct-derived-nonce budget of about 2^48. Rewrite capacity is a separate condition ().
Rewrite Capacity A rewrite consumes the same budget as an initial write. How that budget is shared depends on the nonce mode. For the random-nonce AEADs, epoch_length divides one per-epoch-key pool among the 2^epoch_length segments that share the key. If rewrites are spread evenly, the count each segment can take falls as epoch_length rises: Rewrite share by epoch_length
Suite / mode epoch_length Segments per epoch key Rewrites per segment
AES-128-GCM, AES-256-GCM, random 0 1 ~2^32
AES-128-GCM, AES-256-GCM, random 6 64 ~2^26
AES-128-GCM, AES-256-GCM, random 10 1024 ~2^22
ChaCha20-Poly1305, random 0 1 ~2^32
ChaCha20-Poly1305, random 6 64 ~2^26
ChaCha20-Poly1305, random 10 1024 ~2^22
For a derived-nonce MRAE AEAD the hot-segment rewrite cap is not divided by 2^epoch_length, because a rewrite reuses the segment's one derived nonce: GCM-SIV rewrite cap by epoch_length
Suite / mode epoch_length Segments per epoch key Hot-segment rewrite cap
AES-256-GCM-SIV, derived 0 1 ~2^36 at 64 KiB
AES-256-GCM-SIV, derived 6 64 ~2^36 at 64 KiB
AES-256-GCM-SIV, derived 10 1024 ~2^36 at 64 KiB
The hot-segment cap is length-dependent: about 2^36 at 64 KiB segments and about 2^38 at 16 KiB. The distinct-derived-nonce budget stays about 2^48 per epoch key. A derived-nonce MRAE AEAD thus has two separate constraints, the distinct derived nonces per epoch key and the repeated encryptions at one derived nonce. AEGIS uses a flat key, and its forgery budget, about 2^83 per key from , exceeds any reachable rewrite workload. Applications MUST track segment encryptions per key and freeze the object before a budget is exceeded. The CEK is fixed per object and cannot be rotated in place, so continued writing requires a new object under a fresh CEK.
Choosing epoch_length epoch_length means different things by mode. For the random-nonce AEADs, a smaller epoch_length puts fewer segments under each key, so each segment keeps a larger share of the random-nonce collision pool, at the cost of more epoch keys to derive and hold. For a derived-nonce MRAE AEAD, a smaller epoch_length reduces the distinct derived nonces under an epoch key but does not raise the hot-segment rewrite cap, which is per derived nonce and length-dependent. AEGIS has a 256-bit nonce and a high forgery floor, so a flat key (epoch_length 63) is the natural choice. The cipher suite's default epoch_length, used when a referencing protocol does not choose one, is 0 for the suites with an epoch_length range and 63 for the AEGIS suites. epoch_length 0 derives a fresh epoch key per segment, the finest rotation, giving each segment the largest share of the random-nonce collision pool. The AEGIS 256-bit nonce makes a flat key safe. The named instantiations () do not take this default: each pins an epoch_length tuned to its profile and object size, trading some rotation for fewer epoch keys while staying within budget. The epoch keys are independent under the PRF security of the KDF (), so no epoch key is weaker than another. The epoch_length parameter controls budget distribution, not key strength. For AES-128-GCM the 128-bit AEAD key adds one further constraint. The epoch-key collision term () is about E^2/2^128 over the E distinct epoch keys, so an AES-128-GCM profile SHOULD keep distinct epoch keys per payload_key below about 2^48, which holds that term within the 2^-32 target. At epoch_length 0 this caps an AES-128-GCM object at about 2^48 segments, far below the 2^63 index ceiling, so it constrains only extreme object sizes.
Derivations The per-suite figures come from the bounds below.
Confidentiality (Nonce Collision) For random nonce mode with Nn-octet nonces and q segment encryptions under one key, the collision probability follows the birthday bound: When epoch_length = r is specified, q counts encryptions per epoch key (initial writes plus rewrites within that epoch), not across the whole content. Each epoch key has an independent budget. For derived nonce mode, nonces are deterministic and distinct across segment indices, so this collision term does not apply. The limits on reusing a derived nonce are in .
Confidentiality (Block-Size Birthday Bound) Nonce collisions alone do not exhaust the confidentiality bound. Following the AEAD usage-limits analysis ( Section 5), block-cipher AEADs have a distinguishing bound that grows with the total number of cipher blocks processed under a key. For the AES-GCM suites (AES-128-GCM and AES-256-GCM), if s is the total number of AAD-plus-plaintext 128-bit blocks and q is the number of encryption queries under a key, the confidentiality advantage is at most: For 65536-octet segments (L = 4096 blocks per segment), s = L * q in the worst case, so CA scales as q^2 * L^2 / 2^129. In random nonce mode the nonce-collision bound q^2 / 2^97 dominates for typical deployments because L^2 / 2^32 is small. In derived nonce mode the nonce-collision term vanishes and the block-size term is the binding confidentiality constraint. For ChaCha20-Poly1305 there is no comparable block-size bound because ChaCha20 is a stream cipher, leaving nonce collision and forgery as the only relevant terms. gives the derived-nonce block-size limits. No analogous block-size confidentiality bound has been published for AEGIS-256 or AEGIS-256X2. Nonce collision (negligible at a 256-bit nonce) and the per-key margin govern AEGIS confidentiality. The per-query forgery bound governs integrity. SEAL implementations MUST compute usage budgets from the AEAD-specific confidentiality and integrity bounds, not from nonce-collision probability alone. gives the binding limit per suite.
Integrity (Forgery) Each AEAD decryption query gives the adversary a chance to forge a valid ciphertext. The forgery advantage per query depends on the AEAD and segment_max. For the AES-GCM suites (AES-128-GCM and AES-256-GCM) ( Section 5.1): where v is the number of forgery attempts and L = 4096 blocks per segment. For ChaCha20-Poly1305 ( Section 5.2): Here v is the number of forgery attempts and L' is the segment length in 16-octet Poly1305 blocks (about 4096 at 65536-octet segments), per . The 2^103 denominator (not 2^128) reflects Poly1305's per-query forgery bound. At 65536-octet segments, the integrity limit for ChaCha20-Poly1305 is tighter than for AES-GCM.
Derived-Nonce Bounds A derived-nonce MRAE AEAD has two limits the random-nonce analysis above does not capture. Across the distinct segment nonces under one epoch key, the derived-key analysis of Section 9 () bounds the number of distinct derived nonces at about 2^48 for a 2^-32 advantage. For a single hot segment, every rewrite reuses that segment's one derived nonce, so N rewrites of an L-block segment run AES-CTR under one derived per-record key. The binding term is the keystream block-size birthday over the total blocks, in the form of Section 5 with s = N * L blocks and q = N queries: The N * L term dominates, so this holds while N * L stays below about 2^48, giving N <= about 2^48 / L. That is about 2^36 rewrites of one 64 KiB segment (L = 4096) and about 2^38 at 16 KiB. This per-nonce cap does not divide by 2^epoch_length, because the segment reuses the same derived nonce regardless of epoch_length. Distinct plaintexts under the fixed nonce produce distinct synthetic IVs and hence distinct counter keystreams (the GCM-SIV synthetic-IV construction, ), so confidentiality degrades only by this block-birthday term and not by nonce reuse. Two rewrites with identical plaintext and associated data produce identical ciphertext (deterministic-MRAE equality leakage), independent of this count.
Security Considerations raAE's ra-ROR security target () rests on three assumptions: the AEAD is multi-user real-or-random (mu-ROR) secure, the KDF is a secure multi-user pseudorandom function (mu-PRF), and nonces do not collide. Each subsection below describes a way one of these can fail and what breaks. Integrity across the SEAL suite is bounded by the 16-octet AEAD tag (Nt = 16): no suite member offers more than approximately 128 bits of forgery resistance per query (). The AEGIS algorithms' 256-bit keys raise confidentiality margins, not the tag-length forgery floor.
Detection Summary The table below maps common failure modes to the check that detects them and notes the cases where raAE provides no detection. The rows detected by SnapVerify assume a snapshot authenticator is configured (snap_id != 0x0000). Without one, those modes go undetected. The one exception is a dropped trailing segment: the per-segment finality requirement of detects it in any profile, with no snapshot authenticator. Failure modes and the checks that detect them
Failure mode Detected by
Wrong CEK, salt, or parameter set The commitment, before any segment decryption, provided reader and writer use the same payload_info construction.
Modified ciphertext core or AEAD tag AEAD.Decrypt for the affected segment.
Segment moved to a different index AEAD.Decrypt: the segment index and finality bit are authenticated by segment_aad (random nonce mode) or by the nonce (derived nonce mode).
Segment copied from another object at the same index Detected when the copied segment was encrypted under a different CEK or salt. Reusing a salt with the same CEK breaks this separation ().
Segment copied from another version at the same index Not detected by per-segment AEAD alone; detected by SnapVerify, unless the whole object (including snapshot) is rolled back to that earlier valid version.
Dropped trailing segment(s) (truncation) The finality requirement of , in any profile: the highest-indexed present segment then carries is_final = 0 and the decryptor rejects. Truncation to zero present segments is rejected by the zero-segment prohibition without a snapshot authenticator, and detected by SnapVerify with one ().
Missing interior, duplicated, reordered, or inserted segment SnapVerify, which checks the segment count, finality, and recomputed snapshot value.
Stale snapshot value SnapVerify, unless the stale value is part of a whole-object rollback to a previously valid snapshot.
Whole-object rollback Not detected by raAE alone; the consuming protocol needs authenticated external freshness state.
Concurrent lost update Not a cryptographic forgery; the consuming protocol needs writer serialization or another way to publish object state atomically.
Equality leakage in derived nonce mode Not an authentication failure; rewriting equal plaintext at the same index under derived nonce mode can reveal equality (, ).
Nonce Misuse Nonce reuse under a non-MRAE AEAD leaks plaintext: an adversary who observes two ciphertexts under the same key and nonce recovers the XOR of the plaintexts (for CTR-based AEADs) and can forge new ciphertexts. For AES-GCM and ChaCha20-Poly1305, nonce reuse also recovers the polynomial authentication key, enabling forgery of arbitrary messages. Random nonce mode depends entirely on the CSPRNG. If the CSPRNG returns duplicated state, segments collide. Derived nonce mode removes that dependence, since nonces are deterministic, but the determinism is itself a hazard: re-encrypting a segment with different content under its repeated derived nonce is a two-time pad, catastrophic for a non-MRAE AEAD. A non-MRAE AEAD therefore uses derived nonces only in a write-once profile that draws a fresh salt per object and never re-encrypts under it after a crash (). An MRAE AEAD instead degrades only to equality leakage, not plaintext recovery. The plaintext-bound construction () partially defends against CSPRNG duplication: different plaintexts at the same index produce different nonces because the plaintext digest differs, but equal plaintexts still collide. Implementations that need a full defense against random number generator (RNG) state duplication MUST use derived nonce mode with an MRAE AEAD.
Parameter Set Mismatch The full parameter set that affects encryption, decryption, AAD construction, nonce construction, and key derivation is bound into payload_info (see ) and therefore into the commitment. A reader using a different parameter set than the writer triggers a commitment mismatch before any AEAD operation is attempted. A reader supplying a different G than the encryptor likewise triggers a commitment mismatch (). Consuming protocols MUST still reject unrecognized or unsupported parameter values before decryption, since the commitment check detects mismatch but does not by itself indicate which parameter value the recipient is unable to support. One profile-level constant is bound transitively rather than via payload_info: aad_label is bound through protocol_id (each profile fixes its own aad_label). nonce_mode, by contrast, is carried in payload_info, so the commitment binds it directly. Each SEAL AEAD additionally sets a default nonce mode (see ). Profiles MUST NOT share a protocol_id across distinct aad_label values. Reusing a protocol_id with a changed aad_label produces objects whose commitment matches the wrong reader but whose per-segment AEAD verification fails with no clear error attribution.
Framing and Label Errors Two classes of implementation error break cross-role isolation. A non-injective framing function maps distinct KDF input tuples to the same primitive input, correlating outputs that should be independent. Implementations MUST verify injectivity per . Reusing a label across roles (for example, "commit" for both commitment and payload key) has the same effect. Labels MUST be distinct within a protocol version, and a new version that changes any derivation MUST change the protocol_id.
Parameter Misuse The nonce mode and AEAD choice are coupled, and the table gives the rule for each pairing: Nonce mode by AEAD class
AEAD class random nonce derived nonce
non-MRAE valid mutable: unsafe; write-once: valid
MRAE wasteful valid
Rewrite is where the coupling matters. A derived nonce is fixed by the segment index, so a rewrite reuses it, while a random nonce is drawn fresh every time. A repeat is catastrophic for a non-MRAE AEAD and only equality-leaking for an MRAE one, which is what the table reflects. gives the rules and their consequences. The optional plaintext-bound construction () is an encryptor-side hedge over random nonce mode, not a separate nonce mode. See for SEAL's per-AEAD guidance.
Snapshot Integrity Limitations Snapshot integrity has the following limitations. First, a reader that does not run snapshot verification () does not verify that a segment belongs to the current authenticated snapshot. Such a reader gets per-segment AEAD authenticity only, without the snapshot integrity guarantee of : the ciphertext core is authenticated under the segment index and finality bit, but the reader cannot detect that the segment was substituted from a previous valid version of the same message at the same index, nor that other segments were dropped or rolled back. Such readers MUST still verify the commitment per . Applications that support random-access single-segment reads MUST either run snapshot verification on every read or explicitly document that they accept per-segment authenticity without snapshot freshness. Conversely, snapshot verification over the segment tags authenticates the tag set, its positions, and the count. It does not confirm that a tag is a valid AEAD tag for the ciphertext beside it. Decrypting that segment is what establishes that, so snapshot verification layers set, position, and count binding on top of per-segment AEAD without replacing it. Second, snapshot integrity does not provide freshness against whole-object rollback. A storage adversary that rolls back the entire encrypted object, including the snapshot, to a previously valid version is not detected by raAE alone, because the rolled-back snapshot is itself a valid snapshot for that prior state. This is replay of an intact prior snapshot, not a forgery: it stays out of scope unless the consuming protocol authenticates external freshness into the snapshot context. Applications that require whole-object rollback resistance MUST bind an authenticated version field, timestamp, monotonic counter, or authenticated storage layer into that context. Relatedly, requires a writer to update only trusted snapshot state, so a rewrite cannot launder a rolled-back snapshot into a valid ongoing history. Third, same-index rollback within a snapshot is detected when snapshot verification runs. If an adversary replaces one segment with a previously valid same-index segment but leaves the current snapshot value in place, the recomputed snapshot value no longer matches the stored one, so verification fails except with negligible forgery probability (see ). Detecting these substitutions is a benefit of the design, not a limitation. It is the property that distinguishes raAE's snapshot integrity from per-segment AEAD authenticity. Truncation, including removal of the final segment marked is_final = 1, is detected by snapshot verification. The removed segment is absent from the recomputed snapshot value and the count n_seg no longer matches the segments present, so verification fails. Truncation is not a separate limitation. It is a special case of the first limitation above for readers that skip snapshot verification.
Salt Reuse Reusing a salt with the same CEK across two files produces identical payload schedule outputs: the same payload_key, the same snap_key, and, in derived nonce mode, the same nonce_base. The damage depends on the nonce mode. In every nonce mode, an adversary can silently swap same-index segments between the two files: both per-segment AEAD checks and the snapshot authenticator accept the swap. Salt reuse is therefore an integrity break in every configuration. In derived nonce mode the nonces also repeat across the two files, so an MRAE AEAD degrades to deterministic encryption and leaks plaintext equality between same-index segments. A non-MRAE AEAD under derived nonces, a combination the construction forbids (), would permit plaintext recovery. In random nonce mode (and with the plaintext-bound hedge) fresh nonces keep confidentiality intact, although the per-key nonce-collision budget of then counts encryptions across both files under the single CEK. The integrity break above remains. Applications MUST therefore ensure salt uniqueness per CEK when creating a new message. The freshness requirement in exists for this reason.
Rewrite Hazards Rewriting introduces the following hazards. Applications MUST track total segment encryptions per key and freeze the object before exceeding the budget in . For the 96-bit-nonce AEADs (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305) the binding limit is the per-epoch-key collision pool of roughly 2^32 encryptions, counted across every segment that shares the key. Spread evenly, that pool gives each segment a uniform rewrite share of roughly 2^(32 - epoch_length), as tabulated in . See . Exceeding the per-epoch-key pool risks nonce collisions and plaintext recovery. A mutable profile with derived nonces and an MRAE AEAD (SEAL-RW-v1) reuses a segment's deterministic nonce across non-terminal rewrites, and a crash that replays a write reuses it again. Confidentiality there rests on the per-segment rewrite limit (), not on nonce uniqueness: the AEAD degrades to equality leakage between identical rewrites rather than to plaintext recovery, as long as that budget is respected. For the masked multiset hash, when multiple writers rewrite different segments concurrently, each computes an independent accumulator difference (old_contrib XOR new_contrib). Applying these differences is commutative, but the read-modify-write on the stored accumulator requires coordination. Supplying that coordination, for example a compare-and-swap on the published snapshot value and segment count, is the consuming protocol's responsibility, consistent with the serialization and storage transactions this document places out of scope. The snapshot tag and the mask MUST be recomputed over the final accumulator and segment count inside the same critical section that publishes the snapshot update. Otherwise a storage layer can publish a masked accumulator and a snapshot tag that were computed for different accumulators. As a recovery mechanism, the accumulator can always be rebuilt from scratch by XOR-ing all contrib values and then re-masked. Length changes are a separate concurrency case. Append and truncate change the segment count and re-mark a terminal segment. Those updates do not commute with each other or with a concurrent rewrite of the old or new terminal segment unless the consuming protocol serializes them. Per-segment associated data A_i is rewritable, not fixed at creation. Unlike a global associated data value G, which the commitment fixes when the object is created (), A_i rides the per-segment AEAD associated data (), so a rewrite can replace a segment's A_i, for example to change a policy or version field. A reader therefore cannot treat A_i as context fixed at creation the way it can treat G. An application that needs context fixed at creation places it in G, which the commitment binds, rather than in A_i. raAE also does not guarantee atomic rewrites. A segment rewrite touches the nonce metadata, ciphertext core, AEAD tag, and the snapshot value. A crash between any two of these leaves the content inconsistent. Applications MUST use write-ahead logging, copy-on-write, or an equivalent mechanism to make rewrites recoverable.
Constant-Time Implementation Several raAE operations handle secret data and MUST be implemented in constant time to prevent timing side-channels. The KDF calls in the payload schedule and epoch key derivation take the CEK or payload_key as input keying material. Implementations MUST ensure that HKDF-Extract and HKDF-Expand execute in constant time with respect to their key inputs. In practice this is satisfied by HMAC implementations that do not branch on key octets. Both the commitment comparison () and the snapshot comparison in SnapVerify MUST use a constant-time octet comparison. SnapVerify MUST compare the full recomputed snapshot value, the masked accumulator and the snapshot tag together, in one constant-time comparison, so that no observable difference reveals which half differs (). A variable-time comparison reveals the position of the first differing octet. An adversary who can retry tampered inputs learns the expected value one octet at a time and can then present a matching stored value. This reduces the forgery cost of either check to a linear number of trials (for the snapshot, the bound of ). AEAD.Encrypt and AEAD.Decrypt operations inherit the constant-time requirements of the underlying AEAD. Implementations SHOULD use AEAD libraries that document constant-time guarantees.
Properties Not Provided raAE protects segment content and binds segments together. It deliberately does not address four concerns that belong to the consuming protocol. The CEK must remain available as long as any reader needs access, so there is no forward secrecy. Ciphertexts are not bound to any sender identity. A signing or MAC layer is needed for sender authentication. Key identifiers and structural features of the encrypted format are visible, so unlinkability requires application-layer measures. Finally, snapshot verification covers segments within a message but cannot detect replacement of the message itself. An adversary who swaps one encrypted message for another goes undetected unless the application binds message identity externally. These concerns are not artifacts of raAE's design. Any raAE construction inherits them from the consuming protocol's scope.
Cross-Application Domain Separation Two applications that both reuse the same SEAL profile label () with the same input keying material, the same payload_info, and the same G derive identical commitments, keys, nonces, and AADs. The protocol_id provides cross-application domain separation only when it is distinct per application. Applications whose keying material may be shared across systems SHOULD use an application-specific protocol_id (for example, "myapp-backup-v1") rather than a SEAL profile label. An application adopting a SEAL profile () unchanged MAY use that profile's label.
IANA Considerations This document has no IANA actions. SEAL consumes identifiers from existing IANA registries: the AEAD Algorithms Registry () for aead_id values and the HPKE KDF Registry ( Section 7.2) for kdf_id values. No new raAE-side registries are created. The following code points are early allocations in their respective registries. Each registry reference firms up when the referenced I-D is published as an RFC, and the corresponding SEAL normative reference is a downref under IRTF stream conventions until then. Early-Allocation Code Points
Registry Code point Algorithm Reference
AEAD Algorithms () 0x0021 AEGIS-256
AEAD Algorithms () 0x0024 AEGIS-256X2
HPKE KDF ( Section 7.2) 0x0013 TurboSHAKE-256
Future SEAL profiles MAY consume additional entries from either registry without revising this document.
References Normative References Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. An Interface and Algorithms for Authenticated Encryption 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] HMAC-based Extract-and-Expand Key Derivation Function (HKDF) 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. PKCS #1: RSA Cryptography Specifications Version 2.2 This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. ChaCha20 and Poly1305 for IETF Protocols 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. AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption 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. Hybrid Public Key Encryption 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. Properties of Authenticated Encryption with Associated Data (AEAD) Algorithms Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties and aims to improve consistency in the terminology used in documentation. This document is a product of the Crypto Forum Research Group. The AEGIS Family of Authenticated Encryption Algorithms Fastly Inc. Individual Contributor This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead. Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE 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. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC Informative References The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Re-keying Mechanisms for Symmetric Keys A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Randomness Improvements for Security Protocols Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. OpenPGP This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). Usage Limits on AEAD Algorithms 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. Revisiting AES-GCM-SIV: Multi-user Security, Faster Key Derivation, and Better Bounds Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance Security of Streaming Encryption in Google's Tink Library Fast Message Franking: From Invisible Salamanders to Encryptment How to Abuse and Fix Authenticated Encryption Without Key Commitment Random-Access AEAD for Fast Lightweight Online Encryption Incremental Multiset Hash Functions and Their Application to Memory Integrity Checking A Provable-Security Treatment of the Key-Wrap Problem Security Analysis of the SEAL Construction: raAE, Snapshot Integrity, and Commitment
Optional Plaintext-Bound Nonce Construction This appendix is informative. It describes an optional encryptor-side construction that mixes plaintext content into the per-segment nonce derivation to defend against RNG state duplication. The construction is encryptor-only: the decryptor reads the resulting nonce from the wire (in the same slot used by random mode) and never invokes any of the machinery below. Implementations MAY use this construction in place of a fresh CSPRNG call when generating nonces under nonce_mode "random". The wire format is indistinguishable from random mode and decryption is unaffected. One such construction: This construction fixes two labels: Plaintext-bound construction labels
Derivation role Label variable Value
Plaintext digest binding pt_hash_label "pt-nonce"
Final nonce derivation pt_nonce_label "nonce"
Both labels are distinct from all other SEAL labels. Neither derivation uses nonce_base_label (): the "nonce_base" label belongs to derived nonce mode and does not appear in this construction. In the final derivation nonce_ctx enters the info list as one element after the payload_info elements: its encode output is framed behind a length prefix like any other element, not spliced flat into the list. Component vectors for both KDF classes are in . LH is the over-large-field digest of , which runs the cipher suite's native KDF primitive directly on its input and returns Nh octets. It is collision-resistant per . Decryptors never compute pt_digest. When the encryptor's CSPRNG produces duplicated state (for example, from a virtual machine snapshot or a fork without reseed), two encryptions of distinct plaintexts at the same segment index still produce distinct nonces because pt_hash(i) differs. Two encryptions of identical plaintexts at the same index produce identical nonces, resulting in deterministic encryption: the ciphertexts are identical, revealing only that the plaintexts are equal. No additional information beyond this equality is leaked. For rewrites under this construction, the encryptor recomputes pt_hash(i) with the new plaintext, derives a fresh nonce(i) using the new pt_hash(i) and a new Random(Nn), seals the new plaintext under the new nonce, and updates the snapshot value as in . The construction is observationally equivalent to nonce_mode "random" at the wire format. A decryptor cannot distinguish whether the encryptor used a fresh CSPRNG call or this construction to produce the stored nonce. Implementations that elect to use this construction internally do not need to advertise it.
Optional Hedged Randomness When a long-term symmetric key sk of at least Nh octets is available to the encryptor, implementations SHOULD mix it into random generation using the hedging pattern of . If only an asymmetric private key is available, it MUST first be processed through a KDF to produce a uniform symmetric key. This construction fixes one label, hedge_label = "hedge", distinct from all other SEAL labels. HedgedRandom output depends on both the CSPRNG and sk, so a weak CSPRNG alone cannot predict it. Hedging does not help when the CSPRNG state itself is duplicated (VM snapshots, fork without reseed). Identical CSPRNG output still produces identical HedgedRandom output. An optional encryptor-side construction that mixes plaintext content into the per-segment nonce derivation to defend against state duplication is described in . That construction is orthogonal to hedging and the two MAY be combined.
Proof Status and Security Claim Provenance This appendix is informative. It states what is proven, where, and by whom. Each result below is inherited from , argued in this document, or deferred to a companion proof paper in preparation ().
Inherited from :
The ra-ROR and ra-CMT games, their advantages, and their proofs apply to SEAL's realization of the base interface, summarized in and . The ra-CMT-p notion and its base proof are likewise inherited, but SEAL's realization of its position binding is argued here (see below).
Argued in this document:
The mechanisms this document adds beyond are argued in the subsections below. These are the snapshot authenticator that realizes snapshot integrity, the nonce modes, the per-segment associated data and position binding of ra-CMT-p (bound stated here, formal accounting deferred), and the injectivity and domain separation of the KDF combiner. The combiner argument is structural and proof-complete (). The others state their bounds. Their full proofs are not here.
Referenced from external work:
The capacity, rewrite, and maximum-object-size bounds () are operational ceilings derived from , Section 9, and , not security reductions proven here.
Deferred to :
The formal proof of snapshot integrity as an extension of the ra-ROR framework, the real-or-random treatment of the derived-nonce equality leakage (which relaxes that framework's nonce-respecting hypothesis to deterministic MRAE), and the per-segment associated data and position accounting of ra-CMT-p.
Precedent, not proof:
The derived-nonce unique-nonce transform rests on TLS 1.3 () and STREAM () precedent, treated in . That precedent does not prove SEAL-RO-v1. The KDF hierarchy, the arbitrary-position ra-ROR syntax, the ra-CMT commitment, the epoch accounting, and the object-level semantics remain SEAL-specific proof obligations.
The combiner's input encoding is injective and canonical, so distinct (protocol_id, label, ikm, info, L) tuples map to distinct primitive inputs and a given tuple has one encoding across implementations (, ). Injectivity comes from the length-prefixed encoding, not from the KDF, which need not itself be injective. Collision resistance is assumed only of LH, and only for over-large fields. The commitment derivation carries its own separate collision-resistance assumption (). The capacity and usage limits in , including the maximum write-once object size () and the derived nonce bounds (), are operational ceilings. They are referenced from , Section 9 with , and the 2^63 segment-index ceiling, not proven here.
Provenance of the Security Claims Provenance of the security claims
Property Source Argument Rests on
ra-ROR notion and base proof; SEAL's arbitrary-position ra-ROR syntax is a SEAL-specific obligation , mu-PRF KDF (two keying levels), mu-ROR AEAD, no nonce collision, fresh per-message salt
ra-CMT (commitment, position-respecting) collision resistance of the commitment derivation map over (protocol_id, "commit", CEK, payload_info, G, commitment_length)
ra-CMT-p (per-segment associated-data and position commitment) notion and base proof; SEAL position-binding realization and per-segment associated-data and position accounting argued here, formal write-up in ra-CMT collision bound plus the underlying AEAD's commitment bound for the forged position
KDF combiner injectivity and domain separation this document (structural, proof-complete) , injectivity of the length-prefixed encoding (KDF need not be injective); collision resistance of LH for over-large fields only
Snapshot integrity (masked multiset hash) this document, mu-PRF KDF under snap_key; MAC unforgeability of snapshot_tag over (n_seg, acc); deterministic-masking birthday and mix-and-match terms; per-object separation via salt-bound snap_key
AEAD usage, rewrite, and max-object bounds external work (operational, not proven here) , , , Section 9 with , 2^63 segment-index ceiling
Derived-nonce unique-nonce transform precedent, not proof (TLS 1.3 , STREAM ) , write-once uniqueness discipline reducing to nonce-respecting AEAD security
Derived-nonce equality leakage (MRAE) this document; full proof in MRAE AEAD (); per-segment fixed-nonce data-volume cap
Advantage Notation and Adversary Parameters For a ra-ROR adversary () using at most u distinct CEKs and q_m messages, each encrypted with an independent fresh 32-octet per-content salt (), across E total epochs and making q_e encryption and q_d decryption segment queries with sigma = q_e + q_d, the advantage is bounded by: The terms in the bound are as follows.
Adv_salt_coll
The probability that two messages encrypted under one CEK draw the same salt. Because the salt is a 32-octet value drawn uniformly at random, this term is at most q_m^2 / 2^256. A salt collision is not a PRF-distinguishing event: the KDF deterministically produces identical payload_key, snap_key, and nonce_base outputs whenever (CEK, payload_info) repeats, so the event must be charged separately. Conditioned on no salt collision, distinct messages under one CEK have distinct payload_info values and therefore independent KDF outputs under the mu-PRF assumption. This term holds only under the fresh per-message uniform salt requirement of . A profile that reuses salts or draws them non-uniformly forfeits it and must argue payload-schedule separation by other means ().
Adv_muPRF(KDF, B_KDF)
The multi-user PRF advantage of the KDF, covering two keying levels. Level A is keyed by the CEK and produces payload_key, snap_key, and nonce_base. It has u users, queried once per message. Level B is keyed by payload_key (producing epoch_key per and, in the plaintext-bound construction, per-segment nonces per ) and by snap_key (producing the snapshot authenticator's keyed derivations). It has q_m users. The snap_key subset of Level B feeds the configured snapshot authenticator and is counted under Adv_acc below. It is not counted again here.
Adv_muROR(AEAD, B_AEAD)
The multi-user real-or-random advantage of the AEAD over sigma total segment queries. There is one mu-ROR user per distinct segment key, for E epoch keys total (E = q_m when each message uses a single flat epoch key). This advantage absorbs a key-collision birthday term of about E^2/2^(8*Nk) over the E distinct keys. For the 256-bit-key suites (Nk = 32) that term is about E^2/2^256 and is negligible. For AES-128-GCM (Nk = 16) it is about E^2/2^128 and is the binding epoch-key collision floor. bounds E for that suite.
Adv_nonce_coll
The probability of a nonce collision under any segment key. In derived nonce mode it is zero, conditional on no salt collision (already charged via Adv_salt_coll). In random nonce mode (with or without the plaintext-bound hedge) it is bounded per . The derived-mode statement relies on the deterministic-MRAE analysis in .
Adv_acc
The masked multiset hash's snapshot forgery advantage, present only under snap_id 0x0001 and zero otherwise. SEAL authenticates the XOR accumulator () with a snapshot tag, a MAC under snap_key, and masks the published accumulator with a deterministic tag-derived pad. A different snapshot authenticator contributes its own term in place of Adv_acc.
The Adv_acc term is bounded by: Here Adv_muPRF_acc is the snap_key subset of B_KDF's Level B queries, counted here and not again in Adv_muPRF(KDF, B_KDF). q_s is the number of published snapshot states the adversary observes and q_v the number of SnapVerify queries it makes. The q_s^2 birthday term is the cost of the deterministic masking (). The dominant terms are that birthday and the mix-and-match q_s * q_v / 2^(8*Nh), and for the SEAL suites (8*Nh of 256, 384, or 512) every term is negligible.
ra-ROR Reduction The reduction follows the hybrid over the two-level key schedule (). Condition on no salt collision (Adv_salt_coll). Replace the CEK-keyed KDF outputs, then the payload_key- and snap_key-keyed outputs, with uniformly random values (Adv_muPRF at the two keying levels). Bound the resulting segment AEAD outputs (Adv_muROR). A flat epoch key is the single-epoch case of the same argument. The segment AEAD calls are nonce-respecting only under no nonce collision, the event charged to Adv_nonce_coll (). In derived nonce mode this term is zero conditional on the same no-salt-collision event (). The snapshot authenticator's forgery enters separately as Adv_acc (). The reduction constructs adversaries B_KDF against multi-user PRF security of the KDF and B_AEAD against multi-user real-or-random security of the AEAD, each running in time approximately that of A.
Commitment ra-CMT security reduces to collision resistance of the commitment derivation map over the tuple (protocol_id, "commit", CEK, payload_info, G, commitment_length), with G empty by default. PRF security alone is not sufficient for this reduction, because the commitment adversary may choose the CEK and the context values. The collision-resistance assumption captured in is what makes the reduction sound. For commitment_length = L octets, the relevant quantities are: Thus 16 octets gives about 2^64 collision-search work, 32 octets gives about 2^128 (capped by SHA-256's own 2^128 collision resistance for HKDF-SHA-256), 48 octets gives about 2^192 (capped by SHA-384's 2^192 for HKDF-SHA-384), and 64 octets gives about 2^256 (for HKDF-SHA-512, capped by SHA-512's 2^256, and for TurboSHAKE-256). The fixed-pair collision probabilities at 32, 48, and 64 octets are 2^(-256), 2^(-384), and 2^(-512), respectively. The ra-CMT-p advantage is bounded by the sum of two terms: the commitment collision bound above and the underlying AEAD's commitment bound for the forged position. Position binding for ra-CMT-p is inherited from the underlying AEAD's commitment level (). The notion and base proof are inherited from . The exact per-segment associated data and position accounting is deferred to .
Snapshot Authenticator SEAL's snapshot authenticator (snap_id 0x0001) 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, and the snapshot, and wins by making SnapVerify accept a (segment set, snapshot) pair other than the writer's current state. Whole-object rollback to an earlier honest state is excluded and is the application's freshness responsibility (). 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 tag 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 snapmask(n_seg, snapshot_tag) hides the accumulator behind a one-time pad keyed by snap_key and seeded by the synthetic snapshot tag, the synthetic-IV derandomization of deterministic authenticated encryption (). Two published states that collide on (n_seg, acc), or on the snapshot tag 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 SnapVerify does not surface the recovered 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_acc 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 argument relies on segment AEAD authenticity, already charged as Adv_muROR, and adds no term beyond Adv_acc. 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 ().
Nonce Modes The unique-nonce transform of , which XORs the segment index and finality bit into nonce_base, follows TLS 1.3 () static-IV-XOR-identifier and STREAM () counter-plus-final-bit precedent. Under the write-once uniqueness discipline every derived nonce is distinct, which reduces unique-nonce record protection to nonce-respecting AEAD security. This is precedent, not a SEAL-specific proof. In derived nonce mode the nonce-collision term is zero conditional on no salt collision, because each segment index maps to one derived nonce and a fresh per-message salt makes the segment keys distinct across messages. A rewrite reuses a segment's derived nonce, so the construction relies on the underlying MRAE AEAD: re-encrypting the same plaintext and associated data under the same key and nonce reproduces the same ciphertext, which leaks only equality of those inputs, while distinct inputs remain real-or-random secure (). The formal real-or-random treatment of this equality leakage for derived nonce mode is in preparation (). That treatment builds on the ra-ROR analysis and changes its nonce-respecting hypothesis: a rewrite repeats a segment's derived nonce, so the proof replaces the nonce-respecting AEAD assumption with deterministic-MRAE security, under which nonce reuse leaks only input equality.
Design Rationale This appendix is informative.
Key Schedule Design Rationale The per-content salt makes the payload schedule unique even when a CEK is reused across messages, which matters for applications that derive CEKs from group keys. The encryptor chooses the salt locally at write time. A per-message counter would instead require synchronized state. The CEK is 32 octets regardless of the AEAD key size Nk, so a 128-bit-key AEAD still derives its keys from a 256-bit CEK. Epoch keys bound the number of AEAD invocations under any one segment encryption key. Several considerations motivate this.
AEAD per-key bounds:
The per-key bounds of the underlying AEAD (birthday for 96-bit-nonce schemes, block-size for AES, integrity forgery for all schemes) become the limiting factor on security long before the nonce space is fully exhausted.
Write-once content:
This matters even for content written once: large content with many segments can place many AEAD invocations under a single key.
Rewrites:
Rewrites consume additional invocations and can exhaust the same budget faster than write-once use, but they are not the only reason for epoching. Write-once large content benefits from the same partitioning.
Random access:
Rekeying the entire content would defeat the random-access property, so epoch keys bound the per-key invocation count without requiring a full re-encryption.
Labels separate derivation roles: commitment and payload_key share the same inputs but different labels, making them independent under the PRF assumption. Once CEK and salt are chosen the hierarchy is fixed, with no mutable state to synchronize across writers.
Nonce Mode Design Rationale Random mode is simplest but trusts the CSPRNG completely. Derived mode removes that trust. In a mutable profile it requires an MRAE AEAD, because an in-place rewrite reuses the segment nonce (). In the immutable profile SEAL-RO-v1 the write-once rule keeps every derived nonce unique, so derived mode pairs with any AEAD. gives the default nonce_mode each suite uses in the mutable profile, and a profile MAY select another valid (nonce_mode, snap_id) tuple.
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, stores a single value of 2*Nh octets 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 different authenticator under its own snap_id (). The accumulator is on the wire so a stateless writer can resume the O(1) update from the stored snapshot alone, rather than holding it in trusted state or re-reading every tag. Publishing it is why the mask and the one-bit verifier are needed: an exposed accumulator would let a write adversary recombine observed values ().
Test Vectors This appendix is informative. All vectors use protocol_id = "SEAL-RW-v1", CEK = 32 octets of 0xAA, and salt = 32 octets of 0x04. Each 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 are the internal accumulator acc, the mask snapmask(n_seg, snapshot_tag), the published wrapped_acc = acc XOR mask, and the snapshot tag. The snapshot stored on the wire is wrapped_acc || snapshot_tag (). The accumulator is an intermediate value and is 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 0x03 and 0x07 repeated to the AEAD nonce length. The derived-nonce vector in instead recomputes each nonce from nonce_base, and the cross-epoch vector in sets epoch_length 0 and exposes the intermediate epoch_key and segment_key for each segment. gives the full KDF trace for one commitment. The other blocks list schedule outputs only. The eighteen computed positive vectors, plus the negative SnapVerify vector in , are published byte-for-byte as raae-v1-vectors.json in the draft repository. The vectors are organized by purpose:
Annotated walkthrough:
shows one complete HKDF-SHA-256 trace, including the commitment KDF inputs. Use it to debug framing, payload_info construction, commitment derivation, segment AAD, accumulator contribution, and snapshot_tag computation.
Combiner injectivity coverage:
exercises the KDF combiner in isolation and demonstrates encode() injectivity, including the empty-sequence and same-octets-different-grouping cases. The 38 combiner vectors are published as raae-v1-combiner-kdf-vectors.json.
Cipher-suite coverage:
The single-segment and two-segment vectors exercise the listed AEAD and segment-size combinations with HKDF-SHA-256. Use these to check AEAD code points, segment_max encoding, nonce storage, and finality-bit handling.
KDF coverage:
covers the TurboSHAKE-256 KDF suite and its 64-octet Nh outputs.
Rewrite coverage:
shows a segment rewrite and the corresponding accumulator and snapshot_tag update.
Derived-nonce coverage:
covers AES-256-GCM-SIV in derived nonce mode, where the nonce is recomputed rather than stored.
Epoch coverage:
shows epoch_length = 0, the finest rotation, and exposes per-segment epoch_key and segment_key values. The AEGIS-256 blocks exercise the opposite endpoint, the flat key at epoch_length = 63.
Plaintext-bound nonce coverage:
exposes the component values of the optional plaintext-bound nonce construction, which no end-to-end vector can reach.
Global associated data coverage:
pins the commitment's G input at its empty default, which equals the commitment, and at a nonempty value.
Empty-AAD coverage:
All vectors use empty per-segment A_i. As specified in , an empty A_i is omitted from the encoding rather than encoded as a zero-length fourth element.
Negative coverage:
changes the accumulator without recomputing the snapshot tag; SnapVerify rejects the stored snapshot.
The JSON file is the complete corpus for automated tests. The text below is intended for debugging and review.
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, produce distinct framed inputs and therefore distinct outputs. The full set of 38 combiner vectors, covering both KDF classes and every SEAL label, 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. Because encode length-prefixes each element, the two expand_info values differ, so the outputs 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 the snapshot tag 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. acc_delta = old_contrib XOR new_contrib, the new accumulator is the old accumulator XOR acc_delta, and the snapshot tag 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. 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 the only way to check 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 both blocks bind 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 .
AES-256-GCM, TurboSHAKE-256, 65536, Segment 1 The payload schedule is that of the single-segment TurboSHAKE-256 block (). The segment index is 1, visible in the second framed element of nonce_ctx.
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 the stored masked accumulator, leaving the snapshot tag unchanged. SnapVerify recomputes the snapshot from the two present segment tags (): the recomputed accumulator is the honest one, so the recomputed snapshot tag equals the stored tag, but the recomputed wrapped accumulator differs from the tampered one. The single constant-time comparison of the full recomputed snapshot against the stored value therefore fails, and SnapVerify returns reject without revealing which half differed. A consumer MUST treat this entry as expect-reject and MUST NOT accept it as a valid snapshot.
Tampered Accumulator, Snapshot Tag Not Recomputed
Changes from draft-sullivan-cfrg-raae-00 This appendix is informative. It summarizes the substantive changes from the -00 revision.
  • SEAL: the -00 monolithic raAE-v1 profile became SEAL, a parameterized construction with two named profiles, SEAL-RW-v1 (mutable) and SEAL-RO-v1 (write-once). payload_info gained snap_id (the snapshot authenticator identifier) and dropped aad_label, segment_max is a power of two of at least 4096 octets, and the five named instantiations fix complete parameter sets and a serialization layout ().
  • Structural split: the raAE primitive (), the SEAL construction that realizes it (), and the cipher suites () are now specified separately.
  • Snapshot authenticator (): -00 published the bare XOR accumulator as its whole-object check. That design is superseded for a security reason: a write adversary can recombine observed accumulator differences into a non-historical segment set that still verifies (), so the -00 snapshot offers no whole-object integrity against rewrites. The replacement is the masked multiset hash: a snapshot tag MACs the count and accumulator, and a deterministic, tag-derived mask hides the accumulator, so the published value is wrapped_acc || snapshot_tag.
  • Wire format, code points: aead_id and kdf_id are now 2-octet IANA code points.
  • Wire format, salt: the per-content salt is now a fixed 32 octets.
  • Wire format, KDF output size: TurboSHAKE-256 uses Nh = 64.
  • KDF framing: the KDF framing function is total, and the one-step form frames ikm and info each as one element.
  • Security analysis: reorganized to be property-oriented. The body states properties, assumptions, requirements, and operational limits. The reductions, bounds, and proof symbols are in , and the formal proofs are deferred to a companion paper in preparation.
  • Integrity requirements: unauthorized truncation detection is a normative decryptor requirement, n_seg = 0 is disallowed without a snapshot authenticator, snapshot verification is required when all segment tags are available, commitment_length is at least 16 octets, and the snapshot comparison is constant-time.
  • SEAL-compact named instantiation: added SEAL-compact (SEAL-RW-v1, derived nonce, aligned layout), naming an already-buildable combination that gives large random-access objects compact per-segment metadata. Byte-neutral.
  • The wire-format and snapshot changes above are reflected in a regenerated test-vector corpus ().
  • Normative tightenings from implementation evidence: epoch-key derivation applies at every epoch_length and payload_key is never a segment key (), a SEAL-RO-v1 encryptor MUST NOT rewrite a written segment (), streamed plaintext is unverified for completeness until the terminal finality check (), and the SnapVerify comparison covers the full snapshot value in one constant-time comparison ().
  • Presentation, from the same evidence: the plaintext-bound construction's labels are tabulated adjacent to the construction (), the profiles state where truncation detection surfaces, and the layout size formulas carry Nt symbolically.
  • Test vectors, from the same evidence: component vectors for the plaintext-bound nonce construction (), a worked byte-layout example for the one-step KDF (), and regenerated TurboSHAKE-256 cipher-suite vectors matching the nested one-step framing this document specifies.
  • Terminology: the interface extension is named the extended raAE interface throughout, replacing the earlier "mutable raAE" phrasing, so no text suggests two primitives named raAE. Mutable and immutable now describe only the SEAL profiles' write discipline.
  • Attribution: the introduction credits the base interface and security notions to Fábrega et al., related work names FLOE as the base-interface construction of that work, and the extension section states which interface tier each construction realizes.
  • Global associated data: G is a per-message input, the StartEnc G of the primitive, always the last element of the commitment derivation and empty by default. It is never stored. Every commitment value changes, and the test-vector corpus is regenerated. pins the default and a nonempty G.
Acknowledgments The author thanks Andrés Fábrega, Thomas Ristenpart, Gregory Rubin, Richard Barnes, Thibault Meunier, Kenny Paterson, Christopher Patton, and Christopher A. Wood for their reviews, comments, and discussions.