SAFE: Sealed, Algorithm-Flexible Envelope

SAFE: Sealed, Algorithm-Flexible Envelope Cryptography Consulting LLC

nicholas.sullivan+ietf@gmail.com

SAFE defines an encryption envelope that encrypts a payload once for multiple recipients. Decryption can require multiple credentials in sequence (public keys, passphrases, or other registered methods), so that no single compromise reveals content. The format targets large, writable files: it supports streaming decryption, random-access reads at block granularity, and selective re-encryption of modified blocks without re-keying. Per-block Authenticated Encryption with Associated Data (AEAD) provides confidentiality and integrity and detects reordering, truncation, and extension. SAFE accommodates post-quantum key encapsulation without format changes, provides algorithm agility through IANA registries, supports recipient privacy, and defines application profiles for common deployment scenarios.

Introduction SAFE is an encryption format for files and objects. A SAFE-encoded file contains an encrypted payload and one or more LOCK blocks. Each LOCK wraps a Content-Encryption Key (CEK) for one recipient; multiple LOCKs allow multiple recipients to decrypt the same payload without duplicating ciphertext. A LOCK can require several credentials in sequence (a passphrase AND a private key, for example), so neither factor alone suffices. The payload is split into fixed-size blocks, each encrypted with Authenticated Encryption with Associated Data (AEAD) and a per-block random nonce. Blocks can be decrypted individually or streamed sequentially. An aligned binary layout () places each ciphertext block at a predictable offset, enabling O(1) random reads. Per-block random nonces () allow individual blocks to be re-encrypted without re-wrapping the CEK or touching other blocks. Existing formats address subsets of these capabilities; surveys the differences. SAFE provides algorithm agility through IANA registries () and accommodates post-quantum key encapsulation mechanisms without format changes. Recipient privacy modes () allow Hybrid Public Key Encryption (HPKE) steps to omit key identifiers, preventing passive observers from linking files to recipients. Application profiles () provide baseline algorithm guidance for common deployment scenarios. For example, a deployment might require that documents be decryptable only with both a passphrase AND a recipient private key. The LOCK block for such a recipient would contain two Step lines: Both steps are evaluated with the known passphrase and private key to derive the key that wraps the CEK. Neither factor alone suffices. See for the cryptographic details. The payload layer and LOCK layer serve distinct roles. The LOCK layer manages key encapsulation and multi-factor access control, wrapping the CEK independently for each recipient. The payload layer provides per-block authenticated encryption with support for random-access reads and selective re-encryption of modified blocks. A file-level commitment value precedes independently decryptable fixed-size blocks. Confidentiality and integrity are enforced per block. Block AAD authenticates both the block index and a final-block indicator, so a Decryptor can detect block substitution, reordering, truncation, and extension (). A 32-octet commitment prefix derived from the CEK, the negotiated algorithm parameters, and a per-file salt provides uniform key commitment across all AEAD choices (). formalizes a similar set of properties under the term random-access authenticated encryption (raAE). SAFE's registered AEADs fall into two usage classes. Nonce-Misuse-Resistant (NMR) and non-NMR suites. Non-NMR suites (AES-256-GCM, ChaCha20-Poly1305, AEGIS-256, AEGIS-256X2) use stored per-block random nonces; their security depends on nonce uniqueness and the total number of block encryptions under a given payload key. The NMR suite (AES-256-GCM-SIV, where SIV denotes Synthetic Initialization Vector) uses derived nonces and tolerates nonce reuse, degrading to deterministic encryption rather than permitting plaintext recovery. Because block rewrites consume additional encryptions under the same payload key, the relevant usage budget is not just the current file size but the total lifetime block encryptions, including all rewrites. See for per-AEAD analysis.

Comparison with Related Formats The following table compares SAFE with existing encryption formats on the capabilities most relevant to encrypted file storage. X indicates native support, P indicates that the capability is achievable but is not a design goal of the format, and - indicates no support.

Capability	SAFE	JWE	CMS	OpenPGP	S/MIME	SFrame	Age	AEA	FLOE	Chunked OHTTP
Large-file framing	X	P	P	P	P	-	X	X	X	X
Streaming decrypt	X	P	X	X	X	X	X	X	X	P
Random-access reads	X	-	-	-	-	P	-	X	X	-
Random-access writes	X	-	-	-	-	P	-	-	X	-
Random per-block nonces	X	-	-	-	-	-	-	-	X	-
Multi-recipient (single ciphertext)	X	X	X	X	X	-	P	-	-	-
Multi-factor per recipient	X	P	P	-	P	-	-	-	-	-
Algorithm agility	X	X	X	X	X	X	-	-	P	P
Restricts insecure configurations	X	P	P	P	P	P	X	X	X	-

JWE () encrypts the entire plaintext as a single AEAD operation; its JSON Serialization wraps the Content-Encryption Key per recipient but defines no block structure for streaming or random access. CMS () wraps a content-encryption key per recipient and supports streaming, but defines no fixed-size blocks for random access or selective rewrite. OpenPGP () similarly wraps a session key per recipient via PKESK packets and supports streaming through partial body lengths. Like CMS, it provides no block structure for random access or selective rewrite. Both CMS and OpenPGP provide recipient-level composition (multiple recipients, each with one key), not per-recipient multi-factor. SFrame () targets real-time media: low-latency per-frame AEAD for conferencing, not stored-object encryption. Age streams fixed-size chunks with counter-derived nonces and wraps keys per recipient but deliberately avoids algorithm agility (single cipher suite, no registries). Counter-based nonces prevent selective editing; modifying any block requires re-encrypting the entire payload. Age's payload AEAD (ChaCha20-Poly1305) is not key-committing; demonstrates that a malicious encryptor can craft recipient stanzas that unwrap to different file keys while the same ciphertext decrypts under each, limiting multi-recipient robustness against targeted attacks. AEA encrypts segments (1 MB default, 256 per cluster) using hierarchical HKDF-SHA256 key derivation and AES-256-CTR with HMAC-SHA256 per segment (encrypt-then-MAC). Per-segment keys are derived deterministically from the main key and segment index, enabling parallel decryption and random-access reads without decrypting preceding segments. Key encapsulation uses Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) P-256 for a single recipient or scrypt for passwords; there is no multi-recipient key wrapping and no algorithm agility (the cipher suite is fixed per profile). FLOE defines a rewritable authenticated encryption scheme (raAE) with epoch-based key rotation for segment-level random access. SAFE adapts FLOE's epoch key rotation () but adds multi-recipient key wrapping, multi-factor authentication, and algorithm agility. Chunked OHTTP splits HTTP message bodies into individually encrypted chunks for incremental processing through an oblivious relay. It targets live HTTP streaming, not stored-object encryption, and provides no random access or multi-recipient support. SAFE's block construction builds on the STREAM streaming AEAD pattern (truncation detection via a last-block indicator in ) and extends it with per-block nonces () so that individual blocks can be re-encrypted without re-wrapping the CEK. Non-NMR suites use stored random nonces, which are compatible with AEAD implementations that provide only random IV generation, including FIPS-validated AES-GCM modules per Section 8.2.2. The NMR suite uses deterministic per-block nonces derived from the key schedule and block index, tolerating nonce reuse during rewrites ().

Protocol Overview This section summarizes the encryption and decryption procedures. Normative details appear in the referenced sections. Given a plaintext and a set of recipients (each defined by one or more credentials), an Encryptor produces a SAFE object:

Select AEAD, Block-Size, and Hash (or use defaults).
Generate a random 32-octet CEK using SafeRandom ().
For each recipient, build a LOCK: generate step artifacts (salts, KEM ciphertexts), derive a KEK, and wrap the CEK.
Generate a 32-octet per-file salt: SafeRandom(32, "SAFE-SALT").
Derive payload_key and acc_key from CEK and salt ().
Split plaintext into blocks; encrypt each with a per-block nonce.
Compute the snapshot accumulator from block tags ().
Write the file: optional CONFIG, LOCK blocks, and payload (salt is the first 32 octets of the DATA block).

Given a SAFE object and the appropriate credentials (private keys, passphrases, or other step inputs), a Decryptor recovers the plaintext:

Parse CONFIG, LOCK, and DATA blocks.
Try each LOCK until one succeeds: evaluate its steps with the recipient's credentials to derive a KEK, then unwrap the CEK.
Read the 32-octet salt from the start of the DATA block.
Verify the commitment prefix.
Derive payload_key and acc_key from CEK and salt ().
If all N block nonces and tags are available (i.e., not streaming or partial random-access reads), verify the snapshot accumulator ().
Decrypt requested blocks.

The CEK enables multi-recipient encryption (wrap once per recipient). The KEK binds each recipient's credentials to the CEK. The payload_key is derived from the CEK, the encryption_parameters (the AEAD, Block-Size, and Hash; ), and the per-file salt, providing domain separation: distinct salts produce distinct payload keys even under the same CEK.

Conventions and Notation 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. Header text is UTF-8. Base64 means with padding equals signs and no line wrapping in the source value. When Base64 values appear in SAFE blocks, Encryptors SHOULD wrap lines at 64 characters; Decryptors MUST accept any line length and MUST ignore line breaks within Base64 values. LF denotes the newline U+000A; Encryptors MUST use LF, Decryptors MUST accept LF and MAY accept CRLF. String constants used in Encode AAD labels are ASCII and begin with SAFE- (e.g., SAFE-DATA, SAFE-STEP). SafeDerive labels are ASCII (e.g., commit, kek); the protocol prefix SAFE-v1 is added automatically. ABNF follows . The following common ABNF rule is used throughout this document: This rule is a loose character-class approximation. Implementations MUST validate Base64 encoding per Section 4, including correct padding placement.

Notation This document uses the following notation:

Symbol	Meaning
\|\|	Octet string concatenation
`XOR`	Bitwise exclusive-or of equal-length octet strings
`len(x)`	Length of x in octets
`x[i:j]`	Slice of x from octet i (inclusive) to j (exclusive), zero-indexed
`uint8(n)`	8-bit unsigned integer n (single octet)
`I2OSP(n, w)`	w-octet big-endian encoding of non-negative integer n
`lp16(x)`	I2OSP(len(x), 2) \|\| x — 2-octet length-prefixed encoding
`Encode(x1, ..., xn)`	lp16(x1) \|\| ... \|\| lp16(xn) — multi-value length-prefixed encoding
`...x`	List expansion: if x is a list, each element becomes a separate argument; if x is a single octet string, it is passed as one argument
`uint64(n)`	64-bit unsigned integer n in network byte order (big-endian)
`floor(x)`	Largest integer less than or equal to x
`ceil(x)`	Smallest integer greater than or equal to x

All integers serialized in binary are unsigned and use network byte order (big-endian). Multi-byte integer fields are serialized most-significant byte first.

Text Encoding SAFE header lines (fence markers, field names, field values) MUST contain only ASCII printable characters (0x20-0x7E) plus LF (0x0A). Derive info strings and AEAD AAD prefixes use ASCII. Decryptors MUST reject malformed UTF-8 in text fields. SAFE uses standard Base64 per Section 4 of . Padding is REQUIRED. Base64 values in headers MAY wrap across lines; continuation lines MUST begin with whitespace. Decryptors MUST strip leading whitespace from continuation lines before decoding. In armored encoding, the DATA block's Base64 MAY contain line breaks; Decryptors MUST ignore them. Encryptors MUST use LF (0x0A) line terminators. Decryptors MUST accept LF and MAY accept CRLF. Decryptors MUST strip trailing whitespace from header lines.

Case sensitivity:: All field names, identifiers, and fence markers are case-sensitive.

Terminology

CEK (Content-Encryption Key):: A randomly generated 32-octet key used to derive the payload encryption key. The CEK is wrapped independently for each recipient.
KEK (Key-Encryption Key):: A 32-octet key derived from a LOCK's step sequence. Used to wrap or unwrap the CEK.
Encryptor:: The party that creates a SAFE-encoded file.
Decryptor:: The party that recovers plaintext from a SAFE-encoded file using appropriate credentials.

Algorithms

Default Parameters The following defaults apply whenever a CONFIG block is absent or when a field is omitted from the CONFIG block:

Field	Default Value
AEAD	aes-256-gcm
Block-Size	65536
Hash	sha-256
Key-Epoch	(absent)
Lock-Encoding	armored
Data-Encoding	armored

Implementations MUST use these values for any omitted fields. CONFIG need only include fields that differ from the defaults; see .

Algorithm Summary Tables This section provides a quick reference of all cryptographic algorithms and identifiers used in SAFE. Detailed specifications appear in later sections.

AEAD Algorithms

Algorithm	Identifier	Nk	Nn	NMR	Key-Epoch
AES-256-GCM	aes-256-gcm	32	12	No	Recommended
ChaCha20-Poly1305	chacha20-poly1305	32	12	No	Required
AES-256-GCM-SIV	aes-256-gcm-siv	32	12	Yes	Not Applicable
AEGIS-256	aegis-256	32	32	No	Not Recommended
AEGIS-256X2	aegis-256x2	32	32	No	Not Recommended

Nk/Nn are key/nonce sizes in octets. "NMR" indicates nonce-misuse resistance (see ). "Key-Epoch" indicates whether Encryptors should include Key-Epoch in CONFIG: Required means MUST, Recommended means SHOULD, Not Applicable means MUST NOT (NMR AEADs), Not Recommended means SHOULD NOT (256-bit nonce AEADs gain no practical benefit). See and for details. AEADs without NMR permit plaintext recovery under nonce reuse; Encryptors SHOULD select an NMR AEAD when nonce reuse cannot be ruled out. All AEADs provide semantics with 16-octet tags. All SAFE DATA payloads begin with a 32-octet salt followed by a 32-octet commitment prefix derived per that binds the ciphertext to the CEK, the negotiated algorithm parameters, and the per-file salt (see ).

Key Encapsulation Mechanisms

KEM	Identifier	HPKE KEM ID	Encap Size	Auth
X25519	x25519	0x0020	32 octets	Yes
P-256	p-256	0x0010	65 octets	Yes
ML-KEM-768	ml-kem-768	0x0041	1088 octets	No

HPKE KEM IDs are defined in Section 7.1 of and the IANA HPKE KEM Identifiers registry. ML-KEM-768 enables hybrid post-quantum constructions via multi-step step sequences (see ). All KEMs use HPKE in export-only mode (AEAD ID 0xFFFF). The encryptor calls SetupBaseS (or SetupAuthS when sid or shint is present) to produce a KEM ciphertext and an HPKE context, then calls Export on the context to derive the step secret (). When a sender parameter is present, HPKE Auth mode is used (see ). The KEM identifier appears in hpke(...) step tokens (). SAFE maintains a registry mapping string identifiers to HPKE KEM IDs ().

Step Types

Step Type	Token Format	Parameters	Secret
Passphrase	pass(kdf=..., salt=...)	kdf, salt	32 octets
HPKE	hpke(kem=X, kemct=..., ...)	kem, kemct, id/hint, sid/shint	32 octets

Step types are composed via multiple Step lines within a LOCK block, with AND semantics: all steps are required to derive the KEK. Each step conforms to the interface defined in and produces a 32-octet secret that contributes to KEK derivation (). Additional step types MAY be registered per .

Algorithm Requirements AEADs used with SAFE MUST provide semantics with a 16-octet authentication tag. KEMs MUST use HPKE export-only mode (AEAD ID 0xFFFF) as specified in . When sid or shint is present, HPKE Auth mode is used ().

Hash Function and KDF SAFE piggybacks on the HPKE KDF interface. HPKE and define two KDF classes: Two-stage KDFs (e.g., HKDF-SHA256, KDF ID 0x0001):

KDF.Nh: output size of Extract (32 for HKDF-SHA256)
KDF.Extract(salt, ikm) -> prk (Nh octets)
KDF.Expand(prk, info, L) -> okm (L octets)

Single-stage KDFs (e.g., TurboSHAKE256, ):

KDF.Derive(ikm, L) -> okm (L octets). For TurboSHAKE256: TurboSHAKE256(M=ikm, D=0x1F, L).

The Hash config parameter selects both the KDF and its class. Any KDF registered for SAFE MUST be registered in the HPKE KDF Identifiers registry and MUST implement either the two-stage (Extract/Expand/Nh) or single-stage (Derive) interface.

SafeDerive SafeDerive binds every derivation to the protocol version and a call-site label. The ikm and info parameters accept a single octet string or a list; list elements are individually lp16-encoded by Encode(). Callers that require suite binding include encryption_parameters in the info argument. Config-independent derivations such as key identifiers () omit it. Two-stage (HKDF): Single-stage (Extendable Output Function (XOF)): SafeDerive labels MUST be unique across all call sites within a single protocol version. The labels defined by this specification are reserved; future extensions and step type registrations MUST NOT reuse them. Similarly, SafeRandom labels () MUST be unique and MUST NOT be reused by extensions.

Random Generation (SafeRandom) SafeRandom is the random generation function used for all encryptor-generated random values in SAFE. It requires a cryptographically secure pseudorandom number generator (CSPRNG).

Base Construction When no private key is available, SafeRandom returns raw CSPRNG output. The label parameter is reserved for use by the hedged construction ().

Hedged Construction When a long-term private key sk is available, the Encryptor SHOULD mix it into SafeRandom to defend against a weak or attacker-influenced RNG. The construction follows : hedge_key is a deterministic function of sk (replacing the signature in with a KDF, since SAFE does not require a signature scheme), and SafeRandom combines it with CSPRNG output via SafeDerive. An adversary who can predict CSPRNG output but does not know sk cannot predict the hedged values. Hedging does not prevent repeated output from RNG state duplication (VM snapshot restore, process fork without reseed); identical CSPRNG output produces identical hedged output regardless of the private key. Suitable private keys include any long-term key held by the Encryptor (an HPKE sender private key, an application-provided signing key, or similar). The key need not correspond to any LOCK step. Encryptors MUST use SafeRandom for all random values generated during SAFE encoding: CEK, payload salt, passphrase salt, lock_nonce, and block nonce base. HPKE internal randomness (Encap) is not hedged by default. Implementations whose HPKE library accepts an external randomness source SHOULD supply SafeRandom(Nrand, "SAFE-ENCAP") instead of raw CSPRNG output, where Nrand is the randomness length required by the KEM. A functioning CSPRNG is REQUIRED when no private key is available. See for the security analysis.

Encryption Parameters The encryption_parameters is an ordered list of the effective parameters (defaults augmented by any config overrides): When Key-Epoch is present in CONFIG, the list includes it as a fourth element: where key_epoch_str is the decimal ASCII representation of Key-Epoch with no leading zeros. When Key-Epoch is absent, encryption_parameters has three elements, preserving backward compatibility with files that predate this feature. Because Key-Epoch changes encryption_parameters, adding or removing it requires re-encryption of the payload and re-wrapping of the CEK in new LOCKs. aead_id, block_size, and hash_id are the ASCII string forms of the AEAD, Block-Size, and Hash parameters respectively. SafeDerive splices this list via ...encryption_parameters and applies lp16 framing to each element (). AEAD identifiers MUST be lowercase ASCII and match exactly the registered values in . Block-Size MUST be rendered as a decimal string with no leading zeros (except for the value 0 itself). Hash identifiers MUST be lowercase ASCII and match exactly the registered values in . SafeDerive binds encryption_parameters throughout the key schedule: the KEK aggregator initialization and final derivation (), and each payload schedule call (). See for a worked example.

Step Interface A step is a registered cryptographic operation that produces a 32-octet step secret from user-supplied credentials or cryptographic material. Each step type MUST define:

Step name:

A unique ASCII identifier used in step tokens (e.g., "pass", "hpke").

Parameters:

An ABNF grammar for step-specific parameters appearing in the token (e.g., kem=x25519, id=...).

Derivation:

A deterministic algorithm that produces exactly 32 octets. The algorithm MUST be reproducible given the same inputs. The step definition MUST specify all required inputs for both encryption and decryption.

KEK schedule integration:

The step secret and binding step_token feed into the KEK schedule () via SafeDerive("kek_step", [agg, step_secret], step_token, 32). The step secret (ikm) enters Extract; the step token (info) enters Expand. The on-wire step token appears verbatim in the LOCK block. Each step type defines an Encode form: the canonical binary encoding of its cryptographically relevant fields via Encode() (). The Encode form serves as the binding step_token in the KEK schedule. Display-only fields (label, hint, shint) are excluded. The binding forms for the built-in step types are:

Step	Binding step_token
pass	Encode("pass", kdf, salt)
hpke	Encode("hpke", kem, kemct, id)
hpke (auth)	Encode("hpke", kem, kemct, id, "auth", sid)

String values (kdf, kem) are UTF-8; binary values (salt, kemct, id, sid) are raw decoded octets, not Base64. Fields computed for binding (hpke id, hpke sid, webauthn-prf rpid) may be omitted on-wire for privacy but are deterministically reconstructed during decryption and always appear in the binding form. For hpke, id is always present in the binding step_token even when omitted from the on-wire token; it is computed during trial decryption. Similarly, sid is optional on-wire but always present in auth-mode binding; when omitted, it is computed from the candidate sender public key.

Registration:

New step types are registered via the IANA SAFE Step Names registry () with Specification Required policy. The registration MUST include: step name, parameters grammar, inputs, derivation algorithm, Encode binding form, and any step-specific parameter definitions. See for an example.

label (OPTIONAL, any step):

A human-readable display name intended to help users identify which passphrase, credential, or key to use during decryption (e.g., "Work laptop", "Recovery key"). The label is always excluded from the binding step_token and has no cryptographic effect. Encryptors MAY include a label in any step token; Decryptors MUST ignore it for binding purposes. The label value MUST match the grammar 1*(ALPHA / DIGIT / "-").

Steps are registered in the IANA SAFE Step Names registry (). The following subsections define the initial registered steps.

Passphrase Step The passphrase step derives a 32-octet step secret from a user passphrase using a password-based KDF. The kdf parameter selects the algorithm:

KDF	Algorithm	Parameters
argon2id	Argon2id	m=65536 KiB, t=2, p=1
pbkdf2	PBKDF2-HMAC-SHA-256	iter=600000

The step token format is: ,salt=) pass(kdf=,salt=,label=) ]]> The kdf parameter is REQUIRED. The label parameter is OPTIONAL and is for display only; it is not included in the binding step_token (). Encryptors MUST generate a fresh 16-octet salt using SafeRandom(16, "SAFE-PASS-SALT") for each pass(...) step in a LOCK. Decryptors MUST reject pass(...) steps whose salt value does not decode to exactly 16 octets. Grammar: Encode form: Binding step_token: Encode("pass", kdf, salt). The step secret is computed as follows:

For kdf=argon2id:: Argon2id(passphrase, salt, m=65536, t=2, p=1, T=32) per Section 3.1 of .
For kdf=pbkdf2:: PBKDF2(PRF=HMAC-SHA-256, Password=passphrase, Salt=salt, c=600000, dkLen=32).

In both cases, salt is the decoded value of the salt parameter. Implementations SHOULD prefer argon2id for its memory-hardness properties. Implementations MAY support pbkdf2 for environments where Argon2id is not permitted by policy.

HPKE Step The HPKE step token has three forms: , id=) ; Identified mode hpke(kem=x25519, kemct=, hint=) ; Hinted mode hpke(kem=x25519, kemct=) ; Anonymous mode ]]> The parameters are:

kem (REQUIRED):: The KEM algorithm. Supported values: x25519, p-256, ml-kem-768.
kemct (REQUIRED):: The Base64-encoded HPKE KEM encapsulated key material (the KEM ciphertext). This value MUST decode to the encapsulated key length for the selected KEM (see ). Decryptors MUST reject hpke steps whose decoded kemct length does not match the KEM's encapsulated key length.
id (OPTIONAL):: The key identifier computed as SafeDerive("SAFE-SPKI-v1", spki_der, "", 32) using the configured Hash (default: sha-256). When present, Decryptors match this value against their local keys. When omitted, Decryptors perform trial decryption. See and .
hint (OPTIONAL):: A 4-digit decimal value (0000-9999) assigned by the recipient out-of-band; not solely dependent on the public key. When present, Decryptors filter candidate keys to those associated with this hint in their local key storage. Mutually exclusive with id.

Encryptors MUST include exactly one of: id, hint, or neither (but not both id and hint).

HPKE Auth Mode In Base mode, any party who knows a recipient's public key can create a valid SAFE object for that recipient. Auth mode uses SetupAuthS/SetupAuthR, which bind the HPKE context to the sender's private key so that the Decryptor can verify who produced the object. This is useful for offline encrypted file exchange where the recipient needs assurance of origin (for example, encrypted firmware images, signed-then-encrypted document workflows, or air-gapped key escrow) without requiring a separate signature layer. The presence of sid or shint selects HPKE Auth mode (mode_auth) instead of Base mode. Auth mode MUST only be used with Diffie-Hellman KEM (DHKEM) based KEMs (x25519, p-256). Encryptors MUST NOT include sid or shint with ml-kem-768 or other non-DHKEM KEMs, because these KEMs do not define AuthEncap/AuthDecap.

sid (OPTIONAL):: The sender's key identifier, computed as SafeDerive("SAFE-SPKI-v1", spki_der, "", 32) using the same Hash as id. When present with a Base64 value, Decryptors match it against known sender public keys. The special value anon indicates anonymous sender Auth mode: the sender's key is not identified, and Decryptors perform trial decryption across candidate sender keys. Mutually exclusive with shint.
shint (OPTIONAL):: A 4-digit decimal value (0000-9999) assigned by the sender out-of-band; parallels hint for recipient keys. When present, Decryptors filter candidate sender keys to those associated with this value. Mutually exclusive with sid.

Encryptors MUST include exactly one of sid or shint (but not both) when using Auth mode. Auth mode token forms extend the base forms: , id=, sid=) hpke(kem=x25519, kemct=, sid=) hpke(kem=x25519, kemct=, sid=anon) hpke(kem=x25519, kemct=, shint=1234) ]]> All combinations of recipient identification (id, hint, or anonymous) and sender identification (sid, shint, or sid=anon) are valid. The hpke step token refines the step-token grammar in . OWS (optional whitespace) is permitted after each comma separator, consistent with step-params: Encryptors MUST NOT include both id and hint, and MUST NOT include both sid and shint. Each HPKE step uses HPKE in export-only mode with ciphersuite (KEM_ID, KDF_ID, 0xFFFF) constructed from the KEM's registered identifiers (). AEAD ID 0xFFFF disables Seal/Open; only Export is used. For Base mode (default): For Auth mode (sid or shint present): The kemct value is the KEM ciphertext (enc in HPKE terminology). The exporter_context is defined in . This design uses HPKE's standardized key schedule and export interface for KDF agility, while SAFE's own SafeDerive function handles KEK aggregation, payload key derivation, and nonce constructions.

Supported KEMs The following table lists the KEMs defined in the IANA HPKE KEM Identifiers registry that are recognized by SAFE:

KEM	KEM ID	KDF ID	HPKE Ciphersuite	Key Encoding
x25519	0x0020	(see below)	(0x0020, KDF_ID, 0xFFFF)
p-256	0x0010	(see below)	(0x0010, KDF_ID, 0xFFFF)
ml-kem-768	0x0041	(see below)	(0x0041, KDF_ID, 0xFFFF)	(see below)

The HPKE Ciphersuite column shows the (KEM_ID, KDF_ID, AEAD_ID) triple used with HPKE's Setup functions. AEAD ID 0xFFFF selects export-only mode per Section 5.3 of .

All KEMs, including DHKEM-based KEMs (x25519, p-256), use the KDF selected by the Hash parameter, both for the HPKE key schedule and for DHKEM's internal operations per : HKDF-SHA256 (KDF ID 0x0001) when Hash=sha-256, or TurboSHAKE256 (KDF ID 0x0013) when Hash=turboshake256.
When Hash=turboshake256, the HPKE implementation MUST conform to the one-stage key schedule defined in .

ML-KEM-768 key encoding follows . Auth mode requires AuthEncap/AuthDecap, which are defined only for DHKEM-based KEMs. ML-KEM-768 MUST NOT be used with Auth mode. Additional KEMs from the IANA HPKE KEM Identifiers registry MAY be supported following the process defined in .

Key Identifier Computation The id parameter in hpke(...) steps identifies the intended recipient public key. Key identifiers hash the SubjectPublicKeyInfo (SPKI) Distinguished Encoding Rules (DER) encoding rather than raw key octets. This ensures key identifiers are consistent with certificate fingerprint practices and include the algorithm Object Identifier (OID), preventing collisions between keys of different types. The resulting Base64 string is the value of the id parameter (44 characters for the 32-octet output).

HPKE Step Secret Derivation When the step sequence includes one or more hpke(...) steps, the LOCK MUST include a corresponding kemct parameter value for each HPKE step, in the same order as they appear in the step sequence. Encryptors MUST generate a fresh encapsulation per LOCK; reusing a prior encapsulation is prohibited. For Auth mode, the Decryptor resolves the sender public key as follows:

If sid is present: match against known sender public keys using the configured Hash.
If shint is present: filter candidate sender keys by the hint value.
If neither is present: try all locally known sender keys matching the kem type.

The step secret is derived via HPKE's Export interface: where ctx is the HPKE context returned by SetupBaseS/R (or SetupAuthS/R for Auth mode) as described in , and step_token is the binding form defined in . When id or sid is omitted from the on-wire token, the Decryptor reconstructs it during trial decryption per . The KEM binds the shared secret to the recipient key (and for Auth mode, the sender key). The exporter_context binds the step secret to the step token, preventing key-confusion attacks where an attacker substitutes one recipient's encapsulation for another's. The HPKE info parameter "SAFE-v1" binds the key schedule to this protocol, preventing cross-protocol reuse of the same KEM keys from producing valid SAFE step secrets. Suite binding is not needed here because the final KEK derivation commits to encryption_parameters (). Encode form: Binding step_token: Encode("hpke", kem, kemct, id) for Base mode; Encode("hpke", kem, kemct, id, "auth", sid) for Auth mode. Display-only fields (hint, shint) are not included. The id and sid fields are reconstructed per when omitted on-wire.

Key Schedules SAFE uses two applications of SafeDerive (). The KEK derivation produces a LOCK-specific KEK from its ordered step secrets. The payload derivation produces the per-file payload key, commitment, accumulator key, and (for NMR AEADs) nonce base from the CEK, encryption parameters, and per-file salt. The following diagram shows the two independent chains: Payload encryption is performed once under the CEK and per-file salt and does not depend on lock structure. Locks are independent wrappers of the same CEK and can be added or removed without touching payload ciphertext.

KEK Schedule The KEK schedule derives a KEK from an ordered sequence of step secrets using a running aggregator. Algorithm: Each step folds the aggregator and step secret into ikm (Extract) as an Encode-framed array. The step token is placed in info (Expand). Suite binding enters at kek_init and again at the final kek derivation, where encryption_parameters commits the aggregator to the negotiated AEAD, Block-Size, and Hash.

Multi-Step Example Consider a LOCK block with two steps requiring both a passphrase and a private key: ) Step: hpke(kem=p-256, id=, kemct=) Encrypted-CEK: ]]> Evaluation proceeds per : The derived_kek depends on both factors. Each step is bound to its position via the aggregator chaining through ikm, preventing step reordering.

Sealing Encrypted-CEK The per-step salt and kemct values MUST be unique per LOCK. Reusing these values with the same credentials produces the same step_secret, weakening KEK uniqueness. With derived_kek computed per , the Encrypted-CEK field is: The AEAD algorithm is the one specified in the CONFIG block (or the default aes-256-gcm when CONFIG is absent); the same AEAD is used for both CEK wrapping and payload encryption. Empty AAD is sufficient because derived_kek already binds encryption_parameters (via kek_init and the final kek derivation, ) and all step_tokens (via kek_step chaining); repeating this binding in the AEAD AAD would be redundant. Encryptors MUST generate lock_nonce using SafeRandom(Nn, "SAFE-LOCK-NONCE"); each LOCK requires a fresh value.

Payload Schedule The payload schedule derives the commitment, payload key, accumulator key, and (for NMR AEADs) nonce base from the CEK using SafeDerive. The salt is a 32-octet random value generated using SafeRandom(32, "SAFE-SALT") and stored at the start of the DATA block. It is appended to encryption_parameters in the info input: For NMR AEADs (NMR=Yes in ), the payload schedule also derives nonce_base: For non-NMR AEADs, nonce_base is not derived. The accumulator key acc_key is always derived and is used for the snapshot accumulator (). The commitment prefix is always 32 octets for all AEADs. Decryptors MUST verify the commitment before decrypting any block and MUST reject the file if the derived commitment does not match the stored value (see ). Each call independently derives from CEK with distinct labels. Using the wrong AEAD identifier or Block-Size when attempting decryption produces different SafeDerive outputs, causing AEAD verification to fail on every block. The per-file salt ensures that even when the same CEK is reused across files, each file produces unique derived keys. This binding provides implicit integrity assurance that the decryptor is using the correct encryption parameters.

Epoch Key Derivation When Key-Epoch is present in CONFIG, per-block encryption uses an epoch key derived from the payload key. Key-Epoch is a non-negative integer r; each epoch spans 2^r consecutive blocks. > key_epoch return SafeDerive("epoch_key", payload_key, [I2OSP(epoch_index, 8)], Nk) ]]> Blocks 0 through 2^r - 1 share epoch 0, blocks 2^r through 2^(r+1) - 1 share epoch 1, and so on. When Key-Epoch is 0, every block has its own key (epoch size 1). Since Key-Epoch is included in encryption_parameters when present (), the commitment and all payload schedule outputs change when the epoch configuration changes. Implementations SHOULD cache epoch keys across consecutive blocks in the same epoch. This construction is inspired by , adapted to SAFE's key schedule.

Per-block Nonces Nonces are unique per block; their size Nn is determined by the AEAD algorithm (see ). Encryptors MUST ensure nonce uniqueness within each block_key(i)'s lifetime (). The per-block encryption produces: See for block_key(i). AEAD.Seal returns (ciphertext, tag) where tag is the final 16 octets of the combined AEAD output per . Implementations receiving a single output MUST split at offset len(output) - 16. For non-NMR AEADs, Encryptors MUST use one of the nonce constructions defined in . Each block's nonce and tag are stored: Where nonce_i is Nn random octets and aad_i is defined below. In armored mode, blocks are stored as nonce_i || ciphertext_i || tag_i. In binary mode, the block metadata (nonce + tag) is stored separately from the ciphertext to enable single-seek block access. For NMR AEADs, per-block nonces are derived deterministically from nonce_base (): The XOR is applied to the last 8 octets of nonce_base; leading octets are unchanged. Nonces are not stored; only the authentication tag is kept: See for security rationale. This design enables re-encryption of the payload without re-wrapping the CEK for each recipient, and supports selective editing of individual blocks. For non-NMR AEADs, per-block random nonces allow CEK reuse across payload revisions while maintaining AEAD security.

Nonce Constructions Two nonce constructions are defined for non-NMR block encryption. Both produce Nn-octet nonces suitable for use with the configured AEAD. Decryptors read the stored nonce from each block and do not need to know which construction was used.

Base-XOR Construction The XOR is applied to the last 8 octets of base; leading octets are unchanged. Within a single file, the XOR with distinct block indices guarantees nonce uniqueness. This construction is one-pass and supports parallel block encryption.

Plaintext-Bound Construction Encryptors SHOULD incorporate plaintext into per-block nonce derivation for SIV-like nonce-misuse resistance when RNG state duplication is a concern (e.g., VM snapshots, process forks without reseed). This requires two passes over each block (hash then encrypt). The construction proceeds in two steps: Pass 1 commits to the plaintext via a SafeDerive hash bound to the suite. Pass 2 mixes fresh randomness, the payload key, and the plaintext hash into the final nonce. Under RNG state duplication, this construction produces different nonces when plaintext differs, limiting exposure to leaking equality of identical blocks at the same index.

Block Rewrite Rules When re-encrypting a modified block, the procedure depends on the AEAD's nonce-misuse resistance property. For non-NMR AEADs (stored nonce required): For NMR AEADs (derived nonce; Key-Epoch MUST be absent): NMR rewrites reuse the derived nonce for that block index. Because the AEAD is nonce-misuse resistant, this degrades to deterministic encryption: identical plaintext at the same index produces identical ciphertext, leaking equality but not content. See .

Snapshot Accumulator The snapshot accumulator binds all block authentication tags into a single value, providing file-level integrity without decrypting every block. It uses SafeDerive and XOR; no additional primitives are needed. For each block i with authentication tag tag_i, the per-block contribution is: The accumulator is the XOR of all contributions: XOR is commutative and associative: blocks may be processed in any order, and a single contribution can be replaced without reprocessing other blocks. The result is Nh octets (32 for all registered Hash algorithms). When re-encrypting block i with new tag new_tag_i (replacing old tag old_tag_i): This update costs two SafeDerive calls and two XOR operations, independent of the total block count. Verification:

Derive acc_key from the CEK and salt ().
Read all stored tags from block metadata.
Compute the accumulator by XOR-combining per-block contributions.
Compare the result to the stored accumulator. If they differ, at least one block has been modified, replaced, or is missing.

The accumulator is a PRF-based XOR-checksum over the set of (index, tag) pairs. Each contribution is a PRF output under acc_key with unique inputs; an adversary who does not know acc_key cannot predict any individual contribution and therefore cannot forge a valid accumulator value. Decryptors MUST verify the accumulator before per-block decryption when the full set of block tags is available. Streaming Decryptors that process blocks incrementally MUST verify the accumulator once all blocks have been processed.

Block AAD For block index i in the range 0 <= i < N, the associated data binds each block to its position and indicates whether it is the final block: Where I2OSP(i, 8) is the block index in network byte order and is_final is 0x01 for the last block (index N-1) and 0x00 for all preceding blocks. Encode provides prefix-free framing via lp16 (). No KDF call is needed: payload_key already depends on encryption_parameters (), and the AEAD tag authenticates the AAD under that key. The is_final flag provides truncation detection: if a Decryptor decrypts block i with is_final=0 and no subsequent block exists, truncation has occurred. Decryptors MUST abort when truncation is detected (is_final=0 with no successor block). For random-access reads, Decryptors SHOULD verify that the block count N in the metadata matches the actual number of blocks. The flag also prevents extension attacks: appending blocks after a block marked is_final=1 will fail AEAD verification. For streaming writes where the total block count is unknown, Encryptors buffer the last block until more data arrives or the stream ends. All emitted blocks use is_final=0; only when the stream closes does the Encryptor encrypt the final block with is_final=1. Encryptors MUST ensure block indices remain below 2^64. Encryptors SHOULD limit i to at most 2^48 to avoid Base64 strings exceeding typical filesystem or object store limits; this is a practical recommendation, not a protocol limit. Decryptors MUST reject block indices i where i >= 2^64.

File Layout A SAFE encoding MUST consist of an optional config header (), followed by one or more LOCK blocks (), followed by exactly one DATA block (). Blocks MUST appear in this order; Decryptors MUST reject encodings that violate it. There is no version marker in the fences. Multiple LOCK blocks provide multi-recipient encryption; the DATA block is shared.

SAFE CONFIG The config header may be omitted when all defaults apply. When present, it lists only non-default parameters. The config does not need to be parsed before attempting decryption if the Decryptor already knows or can infer the default parameters. The header is: Lock-Encoding: armored | readable Data-Encoding: armored | binary | binary-linear -----END SAFE CONFIG----- ]]> All CONFIG fields are optional. Omitted fields use default values (): AEAD defaults to aes-256-gcm, Block-Size to 65536, Hash to sha-256, Lock-Encoding to armored, and Data-Encoding to armored. Hash selects the hash function used throughout the protocol (); any identifier in the SAFE KDF Identifiers registry () is valid. Lock-Encoding specifies the LOCK block representation (). Data-Encoding specifies the payload format (): "armored" uses Base64 within DATA fence markers, "binary" uses block-aligned raw binary after the last LOCK, and "binary-linear" uses sequential raw binary after the last LOCK. The encoding fields are presentational choices that do not affect cryptographic operations. Key-Epoch enables per-epoch key derivation (). When absent, all blocks use the payload key directly. When present, it is a non-negative integer r where r MUST be less than 64; Decryptors MUST reject files where Key-Epoch is 64 or greater. Block i uses an epoch key derived from the payload key with epoch index i >> r, giving each epoch 2^r blocks and limiting AEAD invocations per key (). Key-Epoch MUST NOT be present for NMR AEADs; Decryptors MUST reject files where Key-Epoch is present and the AEAD has NMR=Yes in . Encryptors using chacha20-poly1305 MUST include Key-Epoch; Section 4 of requires nonce uniqueness per key, and epoch keys limit the collision domain to rewrites within each epoch. Encryptors using aes-256-gcm SHOULD include Key-Epoch for rewritable files to stay within the per-key invocation limits of ; see for budget calculations. Key-Epoch: 0 is RECOMMENDED for maximum security; Key-Epoch: 5 is a practical alternative when key-derivation overhead matters. NMR AEADs (NMR=Yes in ) implicitly use derived nonces: per-block nonces are computed from the key schedule and block index, and the format nonce length is 0 (nonces are not serialized). Non-NMR AEADs use stored random nonces. See for details. Implementations MUST support Lock-Encoding: armored and Data-Encoding: armored. Support for Lock-Encoding: readable and Data-Encoding: binary or binary-linear is OPTIONAL. A conforming SAFE file MAY omit the SAFE CONFIG block entirely; parsers MUST treat this identically to a CONFIG block with all defaults. When CONFIG is present, it MAY contain any subset of fields. Implementations MUST construct encryption_parameters using defaults for any omitted fields. Field names within the SAFE CONFIG are case-sensitive. Encryptors MUST NOT include duplicate field names; Decryptors MUST reject SAFE config blocks containing duplicate fields. Decryptors MUST reject SAFE CONFIG blocks containing field names not listed in the SAFE Config Options registry (). The order of fields within a CONFIG block is not significant. Encryptors MAY emit fields in any order; Decryptors MUST accept fields in any order. All header lines MUST contain only ASCII characters (octets 0x20-0x7E and LF). Encryptors MUST NOT include non-ASCII characters in field names or values. Decryptors MUST reject SAFE CONFIG blocks containing non-ASCII octets or malformed UTF-8 sequences. Implementations SHOULD bound SAFE CONFIG size; Decryptors MAY reject SAFE CONFIG headers exceeding 64 KiB. Field values MAY wrap across multiple lines using the same rules as LOCK blocks (): continuation lines MUST be indented with at least two spaces, and Decryptors MUST concatenate continuation lines (stripping leading whitespace) before processing.

Block-Size Selection SAFE defines two Block-Size values: 16384 and 65536. Only these values are valid; Decryptors MUST reject any other Block-Size. Adding new Block-Size values requires Standards Action.

65536 (default):: Larger blocks amortize per-block AEAD overhead and reduce I/O syscalls, yielding higher throughput for sequential encrypt and decrypt. This value is appropriate when the payload will be decrypted in full or streamed sequentially.
16384:: Smaller blocks reduce the cost of partial updates. Re-encrypting a modified block requires reading and rewriting only that block; at 16384 octets the I/O cost per edit is one quarter of the default. Applications that perform random-access writes to encrypted data SHOULD use Block-Size 16384.

Both values align to hardware page boundaries. Block-Size 16384 is one page on systems with 16 KiB pages (e.g., Apple Silicon) and four pages on systems with 4 KiB pages (e.g., x86-64). Block-Size 65536 is four pages and sixteen pages, respectively. This alignment avoids page-crossing penalties with direct I/O or memory-mapped access. The Encryptor selects Block-Size at encryption time. The value is recorded in the SAFE CONFIG and applies to all recipients. There is no mechanism to change Block-Size after encryption without re-encrypting the entire payload.

SAFE LOCK A LOCK block defines the unlock steps for a single recipient and carries the artifacts needed to recover the CEK. Each LOCK contains one or more steps and exactly one Encrypted-CEK. Steps are evaluated in the order they appear. Step-specific inputs are carried as parameters (e.g., salt= for pass, kemct= for hpke). See and for step-specific requirements. The Encrypted-CEK is the concatenation of lock_nonce and the AEAD ciphertext of the CEK under the derived KEK with empty associated data (). The lock_nonce length is the AEAD's nonce size (Nn) as specified in . Encryptors MUST generate a fresh lock_nonce per LOCK using SafeRandom(Nn, "SAFE-LOCK-NONCE") (). Decryptors MUST reject Encrypted-CEK values that do not decode to exactly Nn + 32 + 16 octets (lock_nonce, CEK ciphertext, AEAD tag). Decryptors MUST skip LOCK blocks containing unknown KEM identifiers or unknown step types, and attempt other LOCKs (if available). Decryptors MUST reject step tokens containing parameter names not defined for the step type in its registration. Implementations SHOULD bound the number of LOCK blocks; Decryptors MAY reject files containing more than 1024 LOCK blocks to prevent resource exhaustion. Two Lock-Encoding values are defined: readable (text) and armored (binary). Both produce the same binding step_tokens for the KEK schedule ().

Readable Format The readable format uses text step tokens and colon-delimited fields: ) Step: hpke(kem=x25519, id=, kemct=) Encrypted-CEK: -----END SAFE LOCK----- ]]> Field names are case-sensitive. Encryptors MUST NOT include fields other than Step and Encrypted-CEK. Encryptors MUST include at least one Step line and exactly one Encrypted-CEK line. Decryptors MUST reject LOCK blocks containing multiple Encrypted-CEK lines or unknown field names. Optional whitespace (OWS) after colons and commas is permitted for readability.

Step Syntax Each Step line declares a single cryptographic step. Multiple steps form an ordered sequence with AND semantics: all steps MUST be satisfied to derive the KEK. The syntax follows this ABNF, which applies after Decryptors perform line unfolding (concatenating continuation lines and stripping leading whitespace per ): The binding step_token used in the KEK schedule () is derived per : extract the binding fields and encode them with Encode(). Each Step line contains exactly one step token. LOCK blocks with multiple steps use multiple Step lines. Step-specific inputs are carried as step token parameters (e.g., salt= for pass, kemct= for hpke). The param-value production forbids spaces (SP, 0x20) and tabs (HTAB, 0x09). Percent-encoding is not supported; all parameter values MUST be literal UTF-8 printable characters excluding whitespace. Encryptors MUST emit parameters in the order specified by the step definition. Decryptors MUST reject step tokens whose parameters are not in the specified order. Decryptors MUST reject step tokens containing duplicate parameter names within a single step. See for how step secrets are combined to derive the KEK. See for the HPKE step format and for the passphrase step format.

Line Wrapping Field values MAY wrap across multiple lines. Continuation lines MUST be indented with at least two spaces. Decryptors MUST unfold wrapped values by concatenating continuation lines and stripping leading whitespace.

Step tokens MAY wrap at parameter boundaries (after commas). Encryptors SHOULD insert a space after the comma at each wrap point. Continuation lines use 4-space indent.
Encrypted-CEK values use 2-space indent for continuation lines.

Encryptors SHOULD wrap lines at 64 characters. Decryptors MUST accept any line length. A field value extends from immediately after the colon (and any following whitespace) until one of:

A line starting with "Step:" (unindented)
A line starting with "Encrypted-CEK:" (unindented)
A fence line "-----END SAFE LOCK-----"

Trailing whitespace on individual lines SHOULD be avoided; Decryptors MUST strip trailing spaces and tabs from each line before concatenation. Example with wrapped HPKE step token: Decryptors parse the text, extract field values, and produce the step Encode form for binding.

Armored Format When Lock-Encoding is armored, the SAFE LOCK block contains a single Base64 value. The value is the Base64 encoding of the Encode-serialized LOCK: Each step_i is the binding Encode form (excluding display-only fields) as defined in the step's specification. The encrypted_cek is the raw Encrypted-CEK octets (lock_nonce || ciphertext). Decryptors decode the Base64, split the outer Encode into lp16-framed elements. The last element is the Encrypted-CEK; preceding elements are step tokens. Each step token is itself an Encode whose first element is the step name. Encryptors MUST use Base64 with padding per . The Base64 value MAY wrap across multiple lines; continuation lines MUST be indented with at least two spaces. Decryptors MUST concatenate continuation lines (stripping leading whitespace) before decoding.

LOCK Selection A decryptor determines candidate LOCK blocks without touching the SAFE data block.

Candidate Selection For each LOCK block, determine candidacy as follows:

Parse the Step tokens. If any token references an unsupported step type, the LOCK is not a candidate.
For each hpke(...) step, determine candidate keys based on mode:

Identified (id present):

Compute the key identifier for locally available public keys using SafeDerive("SAFE-SPKI-v1", spki_der, "", 32) with the configured Hash (default: sha-256). Keys whose identifier matches the id parameter are candidates.

Hinted (hint present):

Look up keys in local storage associated with this hint value. Keys with matching hint are candidates.

Anonymous (neither id nor hint):

All local keys matching the kem type are candidates.

If no local recipient keys are candidates, the LOCK is not a candidate. For auth-mode hpke(...) steps (sid or shint present), also determine candidate sender keys:

Identified (sid with Base64 value):

Keys whose identifier matches sid are candidates.

Hinted (shint present):

Keys with matching shint are candidates.

Anonymous (sid=anon):

All locally known sender keys matching the kem type are candidates.

If no sender keys are candidates for an auth-mode step, the LOCK is not a candidate.
For pass(...) steps: the LOCK is a candidate if the implementation supports passphrase entry.
For other registered steps: the LOCK is a candidate if the implementation supports them and local policy permits.

Attempt Order Among remaining candidates, Decryptors SHOULD attempt LOCKs in order of confidence:

LOCKs where all hpke steps are identified or hinted; the decryptor has confirmed it holds matching keys.
LOCKs with anonymous hpke steps; requires trial decryption across all keys of the matching KEM type.
LOCKs with pass steps; may require user interaction, so defer until key-only LOCKs are exhausted.

Encryptors MAY include multiple pass(...)-only LOCK blocks if they use different KDF variants (e.g., one pass(kdf=argon2id, ...) and one pass(kdf=pbkdf2, ...) for the same passphrase). This enables interoperability between implementations with different passphrase KDF support. Encryptors MUST NOT include duplicate pass(...)-only LOCKs with the same KDF variant. Decryptors MUST stop at the first successful CEK recovery. Decryptors MAY attempt multiple candidates in parallel.

Trial Decryption For hinted or anonymous step sequences, Decryptors iterate through candidate key combinations. For composable step sequences (multiple hpke steps with AND semantics), trial decryption MUST consider the combinatorial product of candidates for each step. For auth-mode steps, the product includes sender key candidates in addition to recipient key candidates. For each combination:

Establish an HPKE context for each hpke(...) step via SetupBaseR (or SetupAuthR with the candidate sender key for auth-mode steps) and call Export per
Derive the KEK by aggregating step secrets per
Attempt to open Encrypted-CEK with the derived KEK

A candidate succeeds when AEAD tag verification passes on Encrypted-CEK. If the KEK is wrong, the tag will not verify.

Data Encoding The Data-Encoding CONFIG field specifies how the payload is represented. SAFE defines two payload layouts: linear concatenates encrypted blocks sequentially, while aligned adds padding for block-aligned random access. Three encoding values are defined:

Value	Layout	Representation
armored	linear	Base64 within fence markers
binary	aligned	Raw binary, block-aligned
binary-linear	linear	Raw binary, sequential

The default is "armored" when Data-Encoding is omitted.

Armored Encoding Armored encoding wraps the linear layout () in Base64 with fence markers: -----END SAFE DATA----- ]]> The Base64 string MAY be wrapped across multiple lines for readability. When wrapped, each line break MUST be a single LF character. For length calculations and random-access arithmetic, Decryptors MUST first remove all line breaks (LF and CRLF) and CR octets (0x0D), then strip trailing whitespace from the result. The normalized string length determines padding and block offset computations. Decryptors MUST ignore these characters during Base64 decoding and concatenate all lines before decoding. Encryptors SHOULD wrap Base64 lines at 64 characters. Decryptors MUST accept any line length. Implementations MAY enforce an upper bound on payload size to prevent over-allocation; Decryptors MAY reject payloads exceeding 64 TiB of ciphertext. Armored data arithmetic (computing block count, byte-to-Base64 offsets, and per-block decryption) is detailed in .

Binary Encoding Binary encoding omits fence markers. Binary data begins at the octet immediately following the LF (0x0A) that terminates the last -----END SAFE ...----- line (typically the final LOCK block). Binary data ends at EOF. Two variants exist:

Data-Encoding: binary: Uses the aligned layout (). Optimized for random access to large files via memory-mapped I/O or O_DIRECT.
Data-Encoding: binary-linear: Uses the linear layout (). Suitable for streaming or simple implementations that do not require block-aligned random access.

Implementations that do not support binary encoding MUST fail when encountering Data-Encoding: binary or Data-Encoding: binary-linear, consistent with the handling of unknown AEAD or Hash values. Encryptors SHOULD prefer armored encoding for maximum compatibility. Binary encoding is intended for performance-critical applications or programmatic access where human readability is not required.

Payload Layouts SAFE defines two payload layouts that describe how encrypted blocks are structured.

Linear Layout The linear layout concatenates encrypted blocks sequentially with no padding or alignment constraints: The payload begins with a 32-octet salt, a 32-octet commitment (both derived per ), and the Nh-octet accumulator (), followed by encrypted blocks. For non-NMR AEADs, each encrypted block (eb_i) is Nn + len(plaintext_i) + 16 octets. For NMR AEADs, each encrypted block is len(plaintext_i) + 16 octets (nonces are derived, not stored). Decryptors MUST verify the commitment before decryption and MUST reject the file if the derived commitment does not match the stored value. See . All blocks except the final block contain Block-Size octets of plaintext. The final block MAY be smaller. For non-NMR AEADs, each encrypted block consists of a nonce (Nn octets), ciphertext (same length as the plaintext), and authentication tag (16 octets). For NMR AEADs, each encrypted block consists of ciphertext and authentication tag only. Zero-length plaintexts are allowed. A zero-length plaintext produces N = 1, L_final = 0. For non-NMR AEADs with Nn = 12, the minimum payload is 124 octets (32-octet salt + 32-octet commitment + 32-octet accumulator + 28-octet encrypted block). For NMR AEADs, the minimum is 112 octets (32 + 32 + 32 + 16). Decryptors MUST reject payloads with unexpected structure: incorrect commitment length, missing or invalid accumulator, or block boundaries that do not align with expected sizes. In binary-linear encoding the block count N is not stored explicitly. Streaming readers determine N by reading blocks sequentially until EOF: each non-final block is exactly C octets (Nn + B + 16 for non-NMR AEADs; B + 16 for NMR AEADs). The final block is smaller than C.

Aligned Layout The aligned layout structures the file so that every ciphertext block begins at an offset that is an exact multiple of the Block-Size B. This alignment enables efficient memory-mapped I/O and O_DIRECT access, since the operating system can read any block without copying data across page boundaries. The file begins with a header section containing the text headers (CONFIG and LOCK blocks) followed by binary fields: salt, commitment, block count N, first ciphertext index D, per-block metadata (nonces and tags), and the snapshot accumulator. The header is padded with zeros to a block boundary, followed by zero or more padding blocks for append growth, then ciphertext blocks. Let B denote the Block-Size in octets (16384 or 65536). Let Nn be the nonce size (12 for AES-GCM and ChaCha20, 32 for AEGIS-256 and AEGIS-256X2). N is the block count (uint32), and D is the first ciphertext block index (uint32). Let meta_len be the per-block metadata size: Nn + 16 for non-NMR AEADs, or 16 for NMR AEADs. Each row below represents one Block-Size: Per-block metadata entry: The binary portion immediately follows the text headers:

salt (32 octets)
commitment (32 octets)
N: block count (uint32, big-endian)
D: first ciphertext block index (uint32, big-endian)
metadata: N entries, each meta_len octets
accumulator: Nh octets ()
padding to block boundary, then zero or more padding blocks
ciphertext blocks starting at offset (D × B)

The uint32 block count limits aligned-layout files to 2^32 - 1 blocks. Files exceeding this count MUST use linear layout.

Writing To write an aligned-layout file, the Encryptor computes D as follows. Let H be the total header octet count: all CONFIG and LOCK text (including fence markers and newlines), plus 32 (salt) + 32 (commitment) + 4 (N) + 4 (D) + N * meta_len (metadata) + Nh (accumulator). Then: Padding blocks for append growth MAY be added by increasing D beyond the minimum value. The encryptor writes the header, pads to D * B octets, then writes ciphertext blocks at offsets D * B, (D+1) * B, and so on. The aligned layout requires a seekable output. For streaming writes where N is unknown at the start, the Encryptor estimates a maximum block count, computes D from that estimate, reserves space for D, N, and metadata in the header, then seeks back to fill the actual values once the stream closes.

Reading To read an aligned-layout file:

Parse CONFIG and LOCK text to determine AEAD and Block-Size.
Read the 32-octet salt, 32-octet commitment, N, and D.
Read N metadata entries, each meta_len octets.
Read the Nh-octet accumulator.
Verify the accumulator ().
Ciphertext block i is at offset (D + i) × B.

To read only block i: for NMR AEADs, compute nonce_i from nonce_base and the block index; for non-NMR AEADs, read the nonce from the metadata entry. Read the tag from the metadata entry in both cases. Then read B octets (or fewer for the final block) at offset (D + i) x B. The final block's ciphertext length is file_size - (D + N - 1) * B octets.

Compatibility and Migration

Handling Unknown Elements Decryptors processing SAFE-encoded data MUST:

Fail if they encounter an unrecognized or unimplemented value for any CONFIG field (AEAD, Hash, Data-Encoding, Lock-Encoding, Block-Size). Implementations MUST NOT silently ignore CONFIG values they do not support.
Reject Block-Size values other than 16384 or 65536.
Skip LOCKs containing unknown field names, KEM identifiers, or step types and attempt other LOCKs (if available).
Fail if a CONFIG block contains field names not listed in the SAFE Config Options registry ().
Fail if the payload has unexpected structure (wrong commitment length, trailing octets, misaligned block boundaries).
Skip unknown block types if the IANA SAFE Block Types registry () marks them as Ignorable; otherwise fail.

Versioning This document defines SAFE version 1, identified by fence markers ("-----BEGIN SAFE CONFIG-----", etc.). Future incompatible versions would use different fence markers or a new media type. New features SHOULD be added through IANA registries rather than format version changes.

Extension Points SAFE provides IANA registries for AEADs (), KEMs (), step types (), and block types (). Unknown block types are critical by default: Decryptors MUST fail if they encounter an unrecognized block. The IANA SAFE Block Types registry () MAY mark specific block types as Ignorable, enabling forward-compatible optional extensions such as metadata or signatures that older implementations can safely skip.

Application Profiles This section is informative. It describes three parameter combinations for common deployment scenarios. These profiles compose the CONFIG fields defined in ; they do not introduce new protocol elements.

Objects Applications that prioritize text-safe output and maximum interoperability SHOULD use the default parameters (). No CONFIG block is required. The resulting SAFE object is entirely printable ASCII and can be embedded in email, JSON, YAML, or version-controlled files. AES-256-GCM is the default AEAD ().

Streaming Applications that process data sequentially at high throughput SHOULD consider: AEGIS-256 offers high throughput and a 32-octet nonce that simplifies nonce management. Combined with binary-linear encoding (), this yields minimal framing overhead and sequential I/O without alignment padding. Encryptors using this profile SHOULD apply the hedged nonce construction () or plaintext-bound nonce construction () per . Encryptors targeting broad interoperability SHOULD verify recipient support before selecting this profile.

Edit Applications that perform random-access reads and writes on encrypted data SHOULD consider: AES-256-GCM-SIV is nonce-misuse resistant (), so per-block nonces are derived rather than stored (). This reduces per-block metadata from Nn + 16 octets to 16 octets. Block-Size 16384 aligns each block to a single page on 16 KiB-page systems, minimizing page faults per edit (). Binary aligned encoding () enables O(1) random access to any block via memory-mapped I/O. Re-encrypting a modified block reuses the derived nonce for that block index. Because AES-256-GCM-SIV is nonce-misuse resistant, this degrades to deterministic encryption for unchanged blocks rather than catastrophic nonce reuse ().

FIPS Edit Applications that require FIPS 140-validated algorithms for random-access editing SHOULD consider: AES-256-GCM is FIPS 140-validated; ChaCha20-Poly1305, AES-256-GCM-SIV, AEGIS-256, and AEGIS-256X2 are not currently covered by a FIPS 140 validation program. Key-Epoch: 5 limits each epoch key to 32 blocks, giving 2^27 - 1 (over 134 million) rewrites per block before exhausting the per-key nonce budget (). This is sufficient for virtually all editing workloads while adding negligible key-derivation overhead. The default Block-Size of 65536 reduces the number of epoch key derivations relative to smaller block sizes. Unlike the Edit profile (), this profile stores random per-block nonces (Nn + 16 octets per block vs. 16 octets for GCM-SIV). Applications that can tolerate block-level equality leakage on rewrite SHOULD prefer the Edit profile for its lower per-block overhead.

Security Considerations SAFE provides:

Confidentiality:: Indistinguishability under adaptive chosen-ciphertext attack (IND-CCA2) security for the payload, assuming IND-CCA2-secure AEAD. This follows from the standard reduction: SafeDerive is a PRF, so payload_key is indistinguishable from random; under a random key, the registered AEADs provide IND-CCA2 per their specifications.
Authentication:: Each LOCK's Encrypted-CEK is authenticated via AEAD under derived_kek, which binds step tokens and step secrets through the KEK schedule. Block AEAD with index-bound AAD () prevents reordering, modification, and splicing. The snapshot accumulator () provides file-level integrity over all block tags.
Binding:: The KEK schedule binds encryption_parameters at initialization and final derivation (). Step tokens and per-step secrets are folded into the aggregator via sequential SafeDerive chaining. Payload keys inherit suite binding from their own SafeDerive calls ().

SAFE does not provide:

Encryptor authentication (Base mode):: Without a sender parameter (sid or shint), any party with recipient public keys can create SAFE-encoded data. See for Auth mode authentication properties.
Forward secrecy:: CEK compromise exposes all recipients' copies. This is inherent to stored-object encryption, which has no interactive key exchange.
Unlinkability:: Key identifiers enable linking SAFE-encoded data to the same recipient. See for privacy modes.

SAFE assumes secure key storage, side-channel resistant implementations, and trusted cryptographic primitives. A functioning CSPRNG is REQUIRED. See for defenses against RNG weakness or state duplication.

Threat Model SAFE defends against:

Compromised storage provider (confidentiality):: An adversary with read access to stored SAFE-encoded data cannot decrypt without valid credentials (passphrase or private key) for at least one LOCK. The adversary can observe approximate file size, recipient count, and key identifier linkability. SAFE detects block corruption (AEAD failure) and truncation (is_final mismatch), but does not detect LOCK removal, LOCK addition, or whole-file replacement by an adversary with write access.

SAFE does not defend against:

Compromised recipient:: If a recipient's credentials (passphrase or private key) are compromised, the adversary can decrypt the payload. All recipients share the same CEK; compromise of one recipient's KEK does not expose other recipients' KEKs, but does expose the shared CEK and payload. The weakest LOCK determines the effective security of the entire file: an attacker who can satisfy any single LOCK recovers the CEK.
Active attacker with key compromise:: If an attacker compromises a recipient's private key and can modify files, they can create valid SAFE-encoded data for that recipient (in Base mode). Auth mode () mitigates this for steps where the attacker does not also hold the sender's private key; see .
Side-channel attacks:: SAFE assumes implementations do not intentionally leak secrets. Timing attacks on Argon2id, HPKE, or AEAD operations are out of scope for this document.
Malicious Encryptor:: Any party with a recipient's public key can create valid SAFE-encoded data for that recipient. SAFE does not constrain what an Encryptor can encrypt or for whom. Applications MUST validate decrypted content independently of the encryption envelope.

Sender Authentication Properties When sid or shint is present in an hpke(...) step, SAFE uses HPKE Auth mode (mode_auth, ). Auth mode defends against forgery by parties who do not hold the sender's private key: a decryptor who successfully processes an auth-mode step is assured that the encapsulation was produced by a holder of skS. This closes the "encryptor authentication" gap identified above for Base mode, within the following limits:

Non-repudiation:: Auth mode authenticates the sender only to the holder of the recipient's private key. The recipient cannot prove to a third party that the sender created the SAFE object. Applications requiring non-repudiation MUST use external signatures.
Sender identity confidentiality:: The sid parameter (when a Base64 value) reveals the sender's key identifier to any observer. shint narrows the sender's identity. Anonymous Auth mode (sid=anon) avoids explicit sender identification, at the cost of trial decryption across all candidate sender keys.
Sender key trust:: SAFE does not define a trust model for sender public keys. Decryptors MUST independently verify that a sender's public key is authentic (e.g., via a certificate, trust on first use (TOFU), or out-of-band verification) before relying on auth-mode authentication.

Integrity and Authenticity The KEK schedule binds encryption_parameters at initialization and final derivation, with step tokens and per-step secrets folded via sequential SafeDerive chaining. The payload schedule binds payload_key to encryption_parameters independently, tying block encryption to the negotiated AEAD and Block-Size. Payload AEAD authenticates each block with index-bound AAD, preventing reordering and cross-file splicing. SAFE detects truncation and extension at block boundaries via is_final in block AAD (). The snapshot accumulator () provides file-level integrity: a single Nh-octet value that binds all block tags under acc_key. Decryptors can verify whole-file consistency from metadata alone, without decrypting every block. The accumulator updates in O(1) when individual blocks are rewritten. Applications requiring third-party verifiability (e.g., signatures) MUST use external signatures.

Implementation Considerations The step sequence has AND semantics: an attacker must break every step to recover the CEK, so security is at least that of the strongest step. Compromising one step secret (e.g., a passphrase) allows the attacker to compute intermediate aggregator values up to that step; this is inherent to sequential chaining and does not weaken subsequent steps. Nonces MUST be unique: fresh lock_nonce per LOCK, and fresh random nonce per block. Implementations MUST zeroize sensitive values (CEK, KEK, PRKs, payload_key, acc_key, nonce_base) immediately after use. Long-lived processes that retain a CEK (e.g., for incremental writes) SHOULD store it in swap-protected memory (e.g., mlock). To prevent error oracles, implementations exposing decryption to untrusted callers (e.g., network services, APIs) MUST return a single generic "decryption failed" error rather than distinguishing between wrong passphrase, wrong key, commitment mismatch, or AEAD failure. Local tools (e.g., CLI applications, test harnesses) MAY use the detailed error codes in for diagnostics. Implementations MUST use constant-time AEAD, KEM, KDF, commitment comparison, and accumulator verification operations. This extends to passphrase KDF evaluation and Base64 decoding of secret material (Encrypted-CEK, step parameters carrying key material). Commitment and accumulator comparisons MUST use a constant-time equality function (e.g., CRYPTO_memcmp or equivalent). Trial decryption loops () MUST NOT leak timing information about which candidate key succeeded.

Passphrase KDF Selection SAFE supports two passphrase KDF variants with different security properties:

pass(kdf=argon2id, ...):: Memory-hard function that resists GPU and ASIC attacks. The default parameters (64 MiB memory, 2 iterations) provide strong resistance to offline attacks. Recommended for most deployments.
pass(kdf=pbkdf2, ...):: Widely deployed function using PBKDF2-HMAC-SHA-256. Lacks memory-hardness, making it more vulnerable to GPU and ASIC attacks than Argon2id. The 600,000 iteration count provides equivalent CPU-based attack resistance but does not mitigate hardware-based attacks. Use only when policy prohibits memory-hard KDFs.

Encryptors targeting Decryptors with mixed policy constraints MAY include two pass(...) LOCK blocks: one with pass(kdf=argon2id, ...) and one with pass(kdf=pbkdf2, ...), using the same passphrase but fresh salts for each. Applications SHOULD enforce a minimum passphrase complexity policy (e.g., at least 20 characters or equivalent entropy). For high-value data, Encryptors SHOULD combine a pass(...) step with an hpke(...) step in the same LOCK, so that compromise of the passphrase alone is insufficient. Multiple LOCK blocks allow observers to infer shared payload access. HPKE key identifiers link files to the same recipient across objects. The Base64 length reveals approximate payload size; LOCK count reveals recipient count. Applications concerned about traffic analysis SHOULD pad payloads.

Recipient Anonymity and Trial Decryption SAFE supports three levels of recipient identification for hpke(...) steps:

Identified mode:: The id parameter uniquely identifies the recipient's public key. Observers can link SAFE-encoded data encrypted to the same recipient.
Hinted mode:: The hint parameter is a recipient-assigned value (not cryptographically derived). It filters candidates locally while revealing nothing about the key itself. Multiple keys may share the same hint.
Anonymous mode:: No identifier is present. Decryptors MUST trial-decrypt against all local keys matching the kem type. Provides maximum privacy at the cost of increased decryptor computation.

Privacy Benefits Omitting or replacing the key identifier with a hint prevents passive observers from mapping SAFE-encoded data to specific public keys. This is valuable when file-recipient associations are sensitive metadata.

Sender Anonymity Auth-mode hpke(...) steps support the same three levels of sender identification via sid and shint:

Identified (sid present):: The sid parameter identifies the sender's public key using the same Hash as id. Observers can link SAFE objects to the same sender across files.
Hinted (shint present):: The shint parameter is a sender-assigned value that filters candidates locally. It reveals less than sid but still narrows the sender's identity.
Anonymous (neither sid nor shint):: Decryptors trial-decrypt against all locally known sender keys matching the kem type. Provides sender privacy at the cost of increased trial decryption (see ).

Encryptors SHOULD prefer sid unless sender privacy is required. The same trade-offs between identification, hinting, and anonymity apply to sender keys as to recipient keys.

Trial Complexity Anonymous mode with composable step sequences (multiple hpke steps) requires combinatorial trial decryption. For a step sequence with two anonymous hpke(...) steps, where the Decryptor holds K1 keys for step 1 and K2 keys for step 2, up to K1 x K2 combinations may be attempted. Auth-mode steps add a further multiplicative factor: if an auth-mode step has no sid or shint, the Decryptor MUST try all S candidate sender keys, multiplying the search space by S. Implementations MUST set a MaxTrialAttempts limit to bound computation and MUST reject LOCK blocks that would exceed this limit. A value of 1024 is RECOMMENDED; implementations MAY adjust based on deployment constraints.

Denial of Service Considerations An attacker can craft SAFE-encoded data with many anonymous LOCK blocks to force Decryptors into expensive cryptographic operations. Implementations MUST:

Limit the number of LOCK blocks processed per object
Prioritize identified blocks over hinted blocks over anonymous blocks
Abort early when resource limits are exceeded

Implementations MUST also limit the number of steps per LOCK block. A limit of 16 steps per LOCK is RECOMMENDED; this prevents an attacker from crafting a single LOCK block that forces evaluation of an excessive number of passphrase KDF computations. Implementations SHOULD limit the total number of passphrase KDF evaluations to 8 per file; an attacker who crafts multiple LOCKs with pass(...) steps can otherwise force expensive Argon2id computations proportional to the LOCK count. ML-KEM decapsulation is significantly more expensive than X25519; anonymous ML-KEM steps amplify the DoS potential.

Hint Assignment The hint is a 4-digit decimal value (0000-9999) assigned by the recipient; it is not solely dependent on the public key. Recipients communicate their hint to Encryptors out-of-band. Multiple keys MAY share the same hint. Encryptors MUST NOT assume the hint uniquely identifies a key. Decryptors MAY reassign hints at any time; Encryptors SHOULD refresh hint values periodically through out-of-band communication. Encryptors SHOULD prefer identified mode unless recipient privacy is required.

Nonce Generation and CEK Reuse Encryptors SHOULD use the hedged construction () when a private key is available, the plaintext-bound nonce construction () when RNG state duplication is a concern, and an NMR AEAD () for additional protection. The following cases describe the resulting security properties.

With private key, working RNG:: Full protection. The block nonce base is derived from both fresh randomness and the hedge key. Nonces are unique across files and within files.
With private key, duplicated RNG state:: Deterministic encryption per Encryptor. Different Encryptors (with different private keys) produce different hedge keys and therefore different CEKs and nonce bases. Within a single file, block indices guarantee nonce uniqueness. Across files from the same encryptor, the CEK and salt repeat, producing identical payload keys and ciphertext for identical plaintext blocks at the same index. This leaks equality but not content. The plaintext-bound nonce construction () further limits exposure: nonces differ when plaintext differs, even across files.
Without private key, working RNG:: Full protection. SafeRandom returns raw CSPRNG output. Nonce uniqueness depends on the RNG.
Without private key, duplicated RNG state:: No defense. CEKs and salts repeat across files, producing identical payload keys and nonce bases. Within a file, block indices still provide distinct nonces. Across files, nonce reuse under distinct plaintext permits key recovery attacks against AES-GCM, ChaCha20-Poly1305, AEGIS-256, and AEGIS-256X2. AES-256-GCM-SIV limits the damage to deterministic encryption (leaks equality). The plaintext-bound nonce construction also limits nonce reuse to identical blocks at the same index.

A functioning CSPRNG is REQUIRED when no private key is available. Encryptors operating in environments where RNG state duplication is possible (VM snapshots, process forks without reseed, container cloning) SHOULD use the plaintext-bound nonce construction (). Because the plaintext-bound construction incorporates a plaintext-dependent derivation via SafeDerive("SAFE-NONCE", plaintext_i, encryption_parameters, 32) into nonce derivation, two instances that share identical key material still produce distinct nonces whenever plaintext differs. The two-pass cost of this construction is justified by the defense it provides against state duplication. Within a single file, block indices are bounded by the plaintext length and Block-Size. Encryptors MUST ensure block indices remain below 2^64. Practical implementations SHOULD enforce a lower bound; for example, rejecting plaintexts exceeding 2^48 blocks (approximately 16 EiB at the default Block-Size of 65536 octets) provides a conservative margin while supporting files far larger than current storage systems.

File Extension Appending data to an existing SAFE file requires re-encrypting the old final block (which had is_final=1) with is_final=0, then encrypting the new blocks. Encryptors MUST NOT generate a new CEK or salt; the existing LOCKs and salt are reused. Encryptors MUST verify the snapshot accumulator before extending the file; extending a corrupted file propagates undetected damage. The procedure is:

Decrypt the current final block (index N-1) and verify is_final=1.
Re-encrypt block N-1 with is_final=0. For non-NMR AEADs, Encryptors MUST generate a fresh nonce using SafeRandom (). For NMR AEADs, re-encrypting block N-1 at the same index produces the same nonce (nonce_base XOR uint64(N-1)). The AAD differs because is_final changes from 1 to 0; nonce-misuse resistance ensures security despite the repeated nonce. See .
Encrypt new blocks N through N+K-1 with is_final=0.
Encrypt block N+K (the new final block) with is_final=1.
Update the metadata (nonces, tags) and block count N.
Recompute the snapshot accumulator.

For NMR AEADs, re-encryption of block N-1 at the same index reuses the same derived nonce. Because the AAD differs (is_final changed from 1 to 0), the NMR AEAD produces different ciphertext. This is the standard NMR equality-leakage property: an observer can detect that block N-1 was re-encrypted, but content is not revealed.

Derived Nonces For NMR AEADs, per-block nonces are derived deterministically from nonce_base and the block index rather than generated randomly and stored. This is restricted to NMR AEADs for the following reasons:

Uniqueness:: The SafeDerive output is unique per CEK (each CEK produces a distinct nonce_base). XOR with distinct block indices yields distinct nonces for all i < 2^64.
Nonce reuse tolerance:: Re-encrypting block i with the same CEK reuses nonce_i. NMR AEADs degrade gracefully to deterministic encryption: identical plaintext at the same index produces identical ciphertext, but no additional information is leaked. Non-NMR AEADs would suffer catastrophic nonce reuse, which is why derived nonces are not used with them.

Selective Editing Security Per-block random nonces and the is_final flag enable selective editing: individual blocks can be re-encrypted without affecting other blocks or LOCK blocks. When editing:

Generate a fresh random nonce for any re-encrypted block
Update the is_final flag if the last block changes
Update the snapshot accumulator ()
Blocks not being edited retain their original nonces and ciphertexts

The is_final flag prevents truncation and extension attacks:

Truncation: decrypting a block with is_final=0 when no successor exists indicates malicious or accidental truncation
Extension: appending blocks after a block with is_final=1 will fail AEAD verification because the original final block's AAD included is_final=1

Key Identifier Collisions Key identifiers are 32-octet hashes of SPKI DER encodings (). Both registered Hash algorithms (sha-256 and turboshake256) produce 32-octet output, giving a birthday bound on collision probability of approximately N^2 / 2^257 for a deployment with N keys. This is negligible for any practical key population. Implementers MUST NOT rely solely on key identifier matching for authorization; successful HPKE decapsulation and AEAD verification of Encrypted-CEK are required.

Key Commitment SAFE supports multiple LOCK blocks that can be added or removed independently without re-encrypting the payload, because each LOCK wraps the same CEK. However, removing a LOCK does not revoke access: any party who previously decrypted the CEK retains the ability to decrypt the payload. Applications requiring revocation MUST generate a new CEK and re-encrypt. Without key commitment, an adversary could craft LOCK blocks that decrypt to different CEKs and exploit AEAD malleability to create payload ciphertext valid under multiple keys:

Creates LOCK₁ that wraps CEK₁ for recipient A
Creates LOCK₂ that wraps CEK₂ for recipient B
Crafts payload ciphertext C that decrypts to plaintext P₁ under payload_key₁ (derived from CEK₁) and to P₂ under payload_key₂ (derived from CEK₂)

None of the AEADs registered for SAFE provide key commitment from the AEAD mechanism alone at the 128-bit security level (AES-GCM and ChaCha20-Poly1305 are well-known to lack this property; AEGIS-256 with 128-bit tags provides only birthday-bound commitment at approximately 2^64). SAFE's external 32-octet commitment prefix () supersedes the AEAD's native commitment properties, providing uniform 2^128 key-commitment security across all registered suites. The commitment prefix in the SAFE DATA block () provides uniform key commitment for all AEAD choices. The commitment is always 32 octets, derived via SafeDerive("commit", CEK, payload_info, 32) where payload_info = [...encryption_parameters, salt], per . Recipients verify that the derived commitment equals the prefix before block decryption. This binds the ciphertext to the CEK, the negotiated algorithm parameters, and the per-file salt, providing 2^128 key-commitment security and preventing cross-algorithm commitment collisions. The security relies on collision resistance of SafeDerive: the Encode() framing ensures unambiguous parsing of all inputs, so distinct (encryption_parameters, salt, CEK) tuples cannot produce the same commitment. Formally, for any two distinct input tuples the probability of a commitment collision is at most 2^(-128), under the assumption that the underlying KDF is a PRF.

AEAD Usage Bounds The security properties described in this section address distinct threats and are provided by separate mechanisms. Key commitment () prevents an adversary from crafting ciphertext that decrypts to different plaintexts under different keys; the 32-octet commitment prefix solves this uniformly for all registered AEADs and is independent of nonce discipline. Block-level integrity () prevents reordering, truncation, and extension; the block index and final-block indicator in each block's AAD solve this independently of nonce collision risk. Nonce collision risk is a separate concern. For non-NMR AEADs with stored random nonces, the primary practical constraint is the total number of block encryptions performed under one payload key over the file's lifetime. This total includes both initial writes and all subsequent rewrites of individual blocks. See for defenses against RNG weakness and state duplication, including the hedged nonce construction (, ).

Lifetime Encryption Budget Let q denote the total number of block encryptions under one payload key, counting every initial block write and every block rewrite. Because all recipients of a SAFE object share one CEK and therefore one payload key, the per-key analysis applies regardless of recipient count; adding recipients does not increase q. For AEADs with Nn-octet random nonces, the probability of at least one nonce collision among q encryptions is approximately: For 96-bit nonces (Nn = 12), this simplifies to approximately q^2 / 2^97. This is a standard birthday-bound approximation, not a formal proof of the AEAD's concrete multi-user security. The following table illustrates q for representative workloads at the default Block-Size of 65536 octets:

Total encrypted data	Approximate q
1 TiB	2^24
16 TiB	2^28
256 TiB	2^32

The same values of q can be reached by smaller files that are rewritten many times. A 1 GiB file contains 2^14 blocks at the default block size; rewriting the entire file 1024 times produces approximately 2^24 total block encryptions, the same budget as encrypting 1 TiB once. The relevant quantity is lifetime encrypted blocks per payload key, not current file size. When Key-Epoch is present (), each epoch key covers at most 2^r blocks and their rewrites. The birthday bound then applies per epoch key rather than file-wide, so the effective q per key is bounded by the epoch size plus rewrites, not total file size. See for per-epoch budget calculations. In a multi-user setting where an attacker targets any one of U independently keyed SAFE files, the effective collision probability is approximately U * q^2 / 2^(8*Nn + 1). For 96-bit nonces with U = 2^20 files each at q = 2^32, this is approximately 2^(-13), which is not negligible. Key-Epoch () mitigates this by reducing the per-key q to the per-epoch budget; with Key-Epoch: 0 each key encrypts a single block, making per-key q equal to the number of rewrites of that block. At more typical workloads without epochs (q = 2^24 per file), the multi-user bound is approximately 2^(-29). The 256-bit nonce AEADs (AEGIS-256, AEGIS-256X2) render multi-user bounds operationally irrelevant (approximately 2^(-173) at the same parameters).

Per-AEAD Analysis

AES-256-GCM:: AES-256-GCM is nonce-respecting with 96-bit nonces. SAFE uses a fresh random nonce per block for this suite. With stored random nonces, the practical limit is birthday-bound nonce collision under a single payload key: approximately q^2 / 2^97. At q = 2^32 (approximately 256 TiB at the default block size, or equivalent rewrite volume), the collision probability is approximately 2^(-33), which is negligible for most applications. Nonce reuse under AES-GCM permits authentication-key recovery and full plaintext recovery for the affected blocks. Encryptors SHOULD include Key-Epoch () for rewritable files to limit per-key invocations within the bounds of . Key-Epoch: 0 is RECOMMENDED; Key-Epoch: 5 is a practical alternative when key-derivation overhead matters (see for the tradeoff). Alternatively, implementations MAY generate a fresh CEK and re-wrap it in new LOCKs.
ChaCha20-Poly1305:: ChaCha20-Poly1305 is nonce-respecting with 96-bit nonces. The ChaCha20-Poly1305 specification (Section 4 of ) requires nonce uniqueness per key and notes the collision risk of random nonces; SAFE's use of stored random nonces gives the same birthday-style collision accounting as AES-256-GCM (approximately q^2 / 2^97). Nonce reuse under ChaCha20-Poly1305 permits XOR of plaintexts for the affected blocks and compromises Poly1305 authentication. Block rewrites are especially relevant because the same logical block may be encrypted multiple times under the same payload key, each time consuming budget. Because requires nonce uniqueness per key, Encryptors MUST include Key-Epoch when using chacha20-poly1305 (). Key-Epoch: 0 is RECOMMENDED; Key-Epoch: 5 is a practical alternative when key-derivation overhead matters. Key-Epoch () confines the collision domain to rewrites within each epoch.
AES-256-GCM-SIV:: AES-256-GCM-SIV is nonce-misuse resistant (NMR). Under nonce reuse, it degrades to deterministic encryption: identical plaintext at the same block index produces identical ciphertext, leaking equality but not content. The collision analysis is therefore qualitatively different from AES-256-GCM and ChaCha20-Poly1305: the practical question is whether leaking block-level equality across rewrites is acceptable for a given application, not whether a nonce collision permits plaintext recovery. SAFE uses derived nonces for NMR AEADs (), which are deterministic per block index by design. Key-Epoch MUST NOT be present for this suite (). Unique nonces remain preferred to avoid equality leakage; misuse resistance does not provide unlimited safety. The concrete security bound for AES-256-GCM-SIV (Section 6 of ) includes a message-length-dependent term: the distinguishing advantage is bounded by approximately (q * l)^2 / 2^128, where q is the number of queries and l is the maximum message length in 128-bit blocks. At SAFE's default Block-Size of 65536 (l = 4096 blocks), this term is negligible for practical query counts.
AEGIS-256:: AEGIS-256 is nonce-respecting with 256-bit nonces. The birthday bound for 256-bit random nonces is approximately q^2 / 2^257. At q = 2^48 (approximately 16 EiB at the default block size), the collision probability is approximately 2^(-161), which is negligible for any foreseeable SAFE workload. The larger nonce space makes random-nonce collision operationally irrelevant at SAFE scale. Key-Epoch adds no practical benefit for this suite (). Implementations MUST still generate fresh random nonces for each block encryption.
AEGIS-256X2:: AEGIS-256X2 shares the 256-bit nonce of AEGIS-256. The same analysis applies: the birthday bound of q^2 / 2^257 makes nonce collision negligible for any practical SAFE deployment. As with AEGIS-256, Key-Epoch adds no practical benefit. AEGIS-256X2 provides higher throughput on wide-vector hardware; the nonce discipline requirements are identical to AEGIS-256.

Epoch Key Rotation Key-Epoch () limits AEAD invocations per key. With Key-Epoch = r, each epoch key covers at most 2^r blocks (plus their rewrites). The birthday bound applies per epoch key, not file-wide. For 96-bit nonce AEADs, each epoch key's budget is 2^32 encryptions (P < 2^(-33)). The total rewrite budget per epoch key is 2^32 - 2^r encryptions, shared across all 2^r blocks in the epoch. Assuming uniform rewrite distribution:

Key-Epoch	Epoch size	Avg rewrites/block
0	1	2^32 - 1
5	32	2^27 (134M)
8	256	2^24 (16M)
16	65536	2^16 (65K)

In a multi-user setting with U files, the per-epoch multi-user bound is U * q_epoch^2 / 2^(8*Nn + 1), where q_epoch is the total encryptions under one epoch key (at most 2^r initial blocks plus their rewrites). With Key-Epoch: 0 (r=0) and W rewrites per block, q_epoch = 1 + W; even at U = 2^20 files and W = 2^20 rewrites, the bound is approximately 2^20 * 2^40 / 2^97 = 2^(-37). If rewrites concentrate on a single block within an epoch, that block can consume the full epoch budget. With r=0 each key encrypts a single block, so the cross-block collision risk is eliminated and the only collision risk is across rewrites of that block — over 2^32 rewrites to reach the threshold. Section 8 benchmarks the overhead of epoch key derivation across segment sizes and rotation masks; at r=0 the overhead is noticeable for small segments but decreases rapidly with segment size, and by r=5 it is dominated by the cost of processing the plaintext. Each epoch key at r=5 still permits over 134 million rewrites per block. Implementations SHOULD set Key-Epoch: 0 for maximum security. When throughput is critical (e.g., Hardware Security Module (HSM)-backed key derivation or constrained devices), Key-Epoch: 5 provides a practical alternative with strong security margins. For 256-bit nonce AEADs (AEGIS-256, AEGIS-256X2), epoch rotation adds no practical benefit. Implementations SHOULD NOT include Key-Epoch for these suites. Epoch keys are derived, not stored, so no LOCK re-wrapping is needed. This construction adapts the epoch-based key rotation of to SAFE's key schedule.

Relationship to Key Commitment The nonce-collision analysis above is orthogonal to key commitment. As noted in , none of the AEADs registered for SAFE provide key commitment from the AEAD mechanism alone at the target security level. SAFE therefore provides a uniform file-level commitment prefix that is verified before block decryption. Commitment addresses wrong-key and cross-parameter ambiguity; the nonce analysis in this section addresses per-key AEAD lifetime and rewrite safety. The choice of layout (linear versus aligned, ) does not change the cryptographic analysis; it affects only framing and on-disk storage layout.

Algorithm Agility and Post-Quantum Support SAFE accommodates post-quantum KEMs without format changes. ML-KEM-768 (HPKE KEM ID 0x0041) is registered and MAY be used as kem=ml-kem-768. Hybrid post-quantum constructions require no protocol extensions. An encryptor lists both a classical and a post-quantum hpke(...) step in the same step sequence: , id=) Step: hpke(kem=ml-kem-768, kemct=, id=) ]]> The KEK schedule () folds each step's secret into the aggregator in order, so the derived KEK depends on both the X25519 and ML-KEM-768 shared secrets. An attacker must break both KEMs to recover the KEK. Because the KEK schedule folds each step secret sequentially, the derived KEK's security is conjunctive: an attacker must break every step. Hybrid post-quantum protection follows naturally from combining classical and post-quantum steps. The decryptor evaluates both decapsulations during CEK recovery. Each KEM ciphertext is carried in the kemct parameter of its corresponding hpke(...) step token. See for a complete example. Implementations planning PQ migration SHOULD ensure kemct parsing does not impose unnecessary length limits (ML-KEM-768 ciphertexts are 1088 octets). Auth mode () relies on DHKEM AuthEncap/AuthDecap, which requires a CDH-hard group. No post-quantum KEM currently supports Auth mode; ML-KEM-768 MUST NOT be used with Auth mode (). Applications requiring post-quantum sender authentication MUST use external signatures.

Security Level and Design Notes SAFE derives all symmetric keys at 256 bits. The AEAD tag length (128 bits), accumulator contribution length (Nh = 256 bits), and commitment length (256 bits) provide at least 128-bit security against forgery and collision attacks. The KEK schedule initializer kek_init = SafeDerive("kek_init", "", encryption_parameters, 32) uses an empty ikm. This is a public derivation: its output is deterministic and computable by anyone who knows the encryption parameters. Security of the KEK relies on the step secrets folded in subsequent aggregator rounds, not on kek_init being secret. The Encode function is injective for a fixed number of arguments: distinct input tuples produce distinct outputs because each field is length-prefixed. This ensures that binding step_tokens are unambiguous. Per-block nonces are unique within a file by construction: for non-NMR AEADs, each nonce is generated via SafeRandom; for NMR AEADs, nonce_base XOR block_index is unique because block indices are unique. The relevant birthday bound for nonce collisions is across files or across block rewrites under the same payload key; see for per-AEAD analysis.

Downgrade Resistance SAFE has no algorithm negotiation: the Encryptor selects encryption_parameters unilaterally, and the Decryptor either accepts them or fails. An active attacker who modifies encryption_parameters (e.g., substituting a weaker AEAD) changes the derived KEK () and payload keys (), causing CEK unwrapping or block decryption to fail. Forging a valid SAFE object with altered parameters requires the attacker to also hold valid credentials for the target LOCK. Decryptors SHOULD enforce a locally configured allowlist of acceptable encryption parameters. Rejecting algorithms outside the allowlist limits the attack surface to supported primitives. The symmetric components of SAFE (HPKE export-only key schedules, SafeDerive-based KEK aggregation, commitment prefixes, and AEAD encryption) are not vulnerable to quantum attacks. Grover's algorithm provides at most a quadratic speedup against symmetric primitives, leaving all symmetric operations at or above 128-bit security. The post-quantum migration surface is limited to KEM selection. A deployment using Hash=turboshake256 eliminates all SHA-256 dependencies: per , all KEMs use the Hash-selected KDF internally.

Privacy Considerations This section addresses the privacy properties of SAFE per . SAFE is primarily a data-at-rest format; it does not define a transport protocol, so many considerations (correlation by IP, traffic analysis of flows) do not apply directly. SAFE-encoded data reveals the following metadata to passive observers: approximate payload size (from Base64 or binary length), recipient count (from the number of LOCK blocks), and — when key identifiers are present — linkability across files encrypted to the same recipient (). Hinted mode () reduces linkability; anonymous mode eliminates key-identifier-based linking at the cost of increased trial decryption. Auth-mode sender identifiers (sid, shint) create analogous sender linkability (). Applications concerned about metadata leakage SHOULD pad payloads and SHOULD prefer hinted or anonymous modes. Beyond the metadata listed above, the step types and KEM identifiers in each LOCK are visible in cleartext, revealing the authentication factors required (e.g., passphrase, X25519, ML-KEM-768). In multi-recipient files, the set of LOCK blocks reveals co-recipient relationships. For NMR AEADs, block rewrites at the same index produce identical ciphertext when the plaintext is unchanged, leaking equality (). A comprehensive privacy analysis is deferred to a future revision.

IANA Considerations

SAFE AEAD Identifiers Registry IANA is requested to create a SAFE AEAD Identifiers registry. Registration policy is Specification Required. Designated Experts should verify that proposed AEADs provide semantics with a 16-octet authentication tag and Nk of 32 octets (SAFE derives all keys at 256 bits). Experts MUST reject registrations where Nk is not 32. Identifiers MUST consist of lowercase ASCII letters, digits, and hyphens, and MUST NOT exceed 255 octets. The algorithm MUST be appropriate for general-purpose use in encrypted data formats. Initial entries:

Identifier	Nk	Nn	NMR	Key-Epoch	Change Controller
aes-256-gcm	32	12	No	Recommended	IETF
chacha20-poly1305	32	12	No	Required	IETF
aes-256-gcm-siv	32	12	Yes	Not Applicable	IETF
aegis-256	32	32	No	Not Recommended	IETF
aegis-256x2	32	32	No	Not Recommended	IETF

Nk/Nn are key/nonce sizes in octets. Nn is required to compute block boundaries (). "NMR" indicates nonce-misuse resistance. "Key-Epoch" indicates whether Encryptors should include Key-Epoch in CONFIG; see for normative requirements and for details.

SAFE KEM Identifiers Registry IANA is requested to create a SAFE KEM Identifiers registry. This registry maps SAFE's string identifiers (used in kem= parameters) to HPKE KEM IDs. Registration policy is Specification Required. Designated Experts should verify that the KEM is registered in the IANA HPKE KEM Identifiers registry, is compatible with HPKE export-only mode (AEAD ID 0xFFFF) as specified in , and that a specification for SPKI encoding of public keys is provided. The Auth column indicates whether the KEM supports AuthEncap/AuthDecap for HPKE Auth mode. Encryptors MUST NOT include sid or shint with KEMs where Auth=No. Initial entries:

Identifier	HPKE KEM ID	Encap Size	Auth	Change Controller
x25519	0x0020	32 octets	Yes	IETF
p-256	0x0010	65 octets	Yes	IETF
ml-kem-768	0x0041	1088 octets	No	IETF

HPKE KEM IDs are defined in the IANA HPKE KEM Identifiers registry established by . Identifiers MUST consist of lowercase ASCII letters, digits, and hyphens, and MUST NOT exceed 255 octets.

SAFE KDF Identifiers Registry IANA is requested to create a SAFE KDF Identifiers registry. Registration policy is Specification Required. Designated Experts should verify that identifiers consist of lowercase ASCII letters, digits, and hyphens, do not exceed 255 octets, that the underlying KDF provides at least 128-bit security, and that the entry references a KDF registered in the HPKE KDF Identifiers registry (Section 7.2 of ). Each entry MUST reference a KDF registered in the HPKE KDF Identifiers registry. Two-stage KDFs provide Extract(salt, ikm), Expand(prk, info, L), and Nh. Single-stage KDFs () provide Derive(ikm, L). The Nh column specifies the output size in octets used for accumulator contributions and commitment derivation; Nh MUST be 32 for all registrations. The Class column determines which SafeDerive instantiation is used (see ). The CONFIG field name remains "Hash" for wire compatibility; the IANA registry is named "SAFE KDF Identifiers" because the identifiers select a KDF (and its underlying hash function) rather than a bare hash algorithm. All conforming implementations MUST implement sha-256, which is the default when Hash is omitted from the SAFE CONFIG. Implementations MAY implement turboshake256. Initial entries:

Identifier	HPKE KDF ID	Class	Nh	Reference	Change Controller
sha-256	0x0001	two-stage	32		IETF
turboshake256	TBD	single-stage	32		IETF

[RFC Editor: The HPKE KDF ID for turboshake256 is pending allocation in the HPKE KDF Identifiers registry per . Replace "TBD" with the assigned value before publication.]

SAFE Step Names Registry IANA is requested to create a SAFE Step Names registry. Each registration defines a step type conforming to the interface in . The registry has the following columns:

Step Name:: Unique ASCII identifier for the step type (e.g., "pass", "hpke").
Parameters Grammar:: ABNF grammar for step-specific parameters in the token, or "None" if no parameters.
Inputs:: Description of required inputs (e.g., "user passphrase, salt", "recipient private key, kemct").
Secret Length:: MUST be 32 octets for all registered steps.
Reference:: Document specifying the step's derivation algorithm.

Registration policy is Specification Required. Designated Experts MUST verify:

The derivation algorithm is deterministic and produces exactly 32 octets
Parameter names do not conflict with existing registrations
The specification provides complete implementation guidance including the Encode binding form

Step names MUST match the grammar 1*(ALPHA / DIGIT / "-") and MUST NOT exceed 255 octets. Initial entries:

Step Name	Parameters Grammar	Inputs	Secret Length	Reference	Change Controller
pass	kdf, salt, (t, p, m for argon2id; c for pbkdf2)	passphrase, salt	32 octets		IETF
hpke	kem, kemct, id, (sid, shint for auth)	private key, kemct	32 octets		IETF

The pass step's algorithm variant (argon2id or pbkdf2) is specified in the step token's kdf parameter. The default KDF is argon2id; pbkdf2 is available for environments where policy prohibits Argon2id. The hpke step additionally requires the step token itself as input. When sid or shint is present, the sender's private key (for encryption) or public key (for decryption) is also required. Supported kem values are defined in ; key identifier computation is defined in . hpke(...) with sid or shint is OPTIONAL and limited to DHKEM-based KEMs (x25519, p-256). Future registrations MAY define additional step types (e.g., hardware token, Oblivious Pseudorandom Function (OPRF)) or variant algorithms for existing step names (subject to Designated Expert review for interoperability impact). A registration request MUST include:

Step Name and Parameters Grammar (ABNF)
Complete list of Inputs with their sources
Derivation algorithm producing exactly 32 octets
Definition of any step-specific parameters (name, encoding, semantics)
Security considerations for the step type

See for an illustrative example.

SAFE Config Options Registry IANA is requested to create a SAFE Config Options registry. Each registration defines a CONFIG field name and the registry or value set that defines its legal values. The registry has the following columns:

Field Name:: Case-sensitive ASCII field name used in SAFE CONFIG.
Value Definition:: Registry or fixed set of values allowed for the field.
Reference:: Document specifying the field and its semantics.

Registration policy is Specification Required. Designated Experts MUST verify that the field name does not conflict with existing registrations, that the specification defines default behavior when the field is absent, and that the value definition is unambiguous. Initial entries:

Field Name	Value Definition	Change Controller
AEAD	SAFE AEAD Identifiers registry	IETF
Block-Size	16384, 65536	IETF
Hash	SAFE KDF Identifiers registry	IETF
Key-Epoch	Non-negative integer; absent when disabled	IETF
Lock-Encoding	armored (default), readable	IETF
Data-Encoding	armored (default), binary, binary-linear	IETF

The default encoding is "armored" when the Data-Encoding field is omitted. The default Lock-Encoding is "armored" when omitted. Key-Epoch is absent (disabled) when omitted. Block-Size values are fixed by this specification; adding new values requires a Standards Track document update.

SAFE Block Types Registry IANA is requested to create a SAFE Block Types registry. This registry lists the block types that may appear in SAFE-encoded data, identified by their fence markers. The registry has the following columns:

Block Type:: The block type name as it appears in fence markers (e.g., "CONFIG", "LOCK", "DATA").
Fence Marker:: The opening fence marker string (e.g., "-----BEGIN SAFE CONFIG-----").
Ignorable:: "Yes" if Decryptors MAY skip unrecognized instances of this block type without failing; "No" if Decryptors MUST fail when encountering an unrecognized block of this type.
Reference:: Document defining the block's semantics.

Registration policy is Specification Required. Designated Experts MUST verify:

The block type name does not conflict with existing registrations
The specification clearly defines the block's syntax and semantics
Blocks marked Ignorable=Yes do not affect security or correctness if omitted

Block type names MUST consist of uppercase ASCII letters and hyphens and MUST NOT exceed 32 octets. Initial entries:

Block Type	Fence Marker	Ignorable	Change Controller
CONFIG	-----BEGIN SAFE CONFIG-----	No	IETF
LOCK	-----BEGIN SAFE LOCK-----	No	IETF
DATA	-----BEGIN SAFE DATA-----	No	IETF

All initial block types are critical (Ignorable=No). Future extensions MAY register new block types with Ignorable=Yes for optional features such as detached signatures, metadata, or recipient hints.

Media Type Registration IANA is requested to register the following media type per :

Type name:: application
Subtype name:: safe
Required parameters:: None
Optional parameters:: None
Encoding considerations:: Binary or 7bit. Armored-encoded SAFE data (the default) consists of ASCII printable characters and line feeds, with Base64 encoding for payload data. Binary-encoded SAFE data have ASCII headers followed by raw binary payload data.
Security considerations:: SAFE-encoded data contain encrypted content. See of this document.
Interoperability considerations:: SAFE-encoded data are ASCII-armored with PEM-style fence markers. Line wrapping of Base64 content is permitted; Decryptors MUST accept any line length.
Published specification:: This document
Applications that use this media type:: File encryption, secure file sharing, encrypted backups
Fragment identifier considerations:: None
Additional information:: Deprecated alias names for this type: None
: Magic number(s): Files begin with "-----BEGIN SAFE" (ASCII)
: File extension(s): .safe
: Macintosh file type code(s): None
Person & email address to contact for further information:: N. Sullivan (nicholas.sullivan+ietf@gmail.com)
Intended usage:: COMMON
Restrictions on usage:: None
Author:: See Authors' Addresses section
Change controller:: IETF

References Normative References The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] 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] Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Elliptic Curve Cryptography Subject Public Key Information This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [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. Media Type Specifications and Registration Procedures This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. PKCS #5: Password-Based Cryptography Specification Version 2.1 This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques. This document represents a republication of PKCS #5 v2.1 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 2898. Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. 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. Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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. Hybrid Public Key Encryption Cisco Inria Inria 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 a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. 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. 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. Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) sn3rd AWS AWS Cloudflare The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. 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. 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. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC 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. Informative References Cryptographic Message Syntax (CMS) This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] Privacy Considerations for Internet Protocols This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. 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. Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Privacy Pass Issuance Protocols This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol. 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"). JSON Web Encryption (JWE) JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (Selective Forwarding Units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. This mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. Chunked Oblivious HTTP Messages Apple Mozilla This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. Apple Encrypted Archive (AEA) Apple Inc. The age file encryption format Actually Good Encryption? Confusing Users by Changing Nonces Web Authentication: An API for accessing Public Key Credentials - Level 3 Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance Random-Access AEAD for Fast Lightweight Online Encryption

Examples This appendix is informative. Note: The examples in this section illustrate structure and formatting only. The Base64 values are placeholders and do not represent valid cryptographic outputs. Implementers requiring test vectors with known inputs and outputs should consult the Test Vectors appendix (). A minimal object with readable LOCK format (Lock-Encoding set to readable; aes-256-gcm, commitment prefix): A LOCK block encoded as armored (default Lock-Encoding): HPKE recipient in armored format (derived from the readable example above): A HPKE recipient with non-default Block-Size (AEAD omitted, uses default aes-256-gcm with commitment prefix): HPKE recipient with Hash: turboshake256 (32-octet key identifier, default aes-256-gcm with commitment prefix): AEGIS-256 with TurboShake key identifier (commitment prefix in DATA): Anonymous X25519 recipient (trial decryption required): Hinted ML-KEM-768 recipient (4-digit hint for candidate filtering): Two recipients, one passphrase-only and one HPKE (default aes-256-gcm): Multi-step sequence with AND semantics (passphrase AND HPKE, chacha20-poly1305 with commitment prefix): Same multi-step example in armored format (default Lock-Encoding): Note: The armored LOCK examples above use placeholder Base64 values. The armored payload is Base64(Encode(step_1, ..., encrypted_cek)) per . Two-passphrase step sequence (requires both passphrases to decrypt): Hybrid post-quantum step sequence (X25519 AND ML-KEM-768, default aes-256-gcm with commitment prefix):

Implementation Guide This appendix is informative. For a concise summary of the encryptor and decryptor flows, see .

Encryptor Processing Encryptor processing proceeds in three phases: setup, recipient key wrapping, and content encryption. During setup, the Encryptor:

Selects an AEAD algorithm and Block-Size (or accepts defaults)
Emits a SAFE CONFIG block if using non-default values
Generates a random 32-octet CEK: SafeRandom(32, "SAFE-CEK")
Generates a 32-octet salt: SafeRandom(32, "SAFE-SALT")

Encryptors should generate a fresh CEK for each file. When the same CEK is reused across files, the per-file salt ensures payload keys are unique: each salt produces distinct commitment, payload_key, acc_key, and nonce_base values via . For each recipient, the Encryptor wraps the CEK by:

Emitting Step lines with required step parameters (salt for pass steps, kemct for hpke steps)
Generating a fresh lock_nonce: SafeRandom(Nn, "SAFE-LOCK-NONCE")
Deriving step secrets and computing the KEK per
Emitting the Encrypted-CEK field

To encrypt content, the Encryptor:

Derives payload_key from the CEK, encryption_parameters, and salt per
Splits the plaintext into Block-Size blocks (N blocks total)
For NMR AEADs, derives nonce_base per and computes nonce_i = nonce_base XOR uint64(i) for each block. For non-NMR AEADs, generates per-block nonces using one of the constructions in .
For each block i: a. Computes nonce_i per the chosen construction b. Determines is_final = 1 if i == N - 1, else 0 c. Constructs data_aad(i, is_final) per d. Computes key_i = block_key(i) (). e. For non-NMR AEADs: emits nonce_i || AEAD.Seal(key_i, nonce_i, aad, block). For NMR AEADs: emits AEAD.Seal(key_i, nonce_i, aad, block) (ciphertext and tag only; nonce is not stored).

Decryptor Processing Decryptor processing proceeds in three phases: configuration, CEK recovery, and content decryption. During configuration, the Decryptor reads the SAFE CONFIG (if present) to learn non-default values and constructs encryption_parameters from AEAD, Block-Size, and Hash. To recover the CEK, the Decryptor:

Selects a LOCK block per
Parses lock_nonce (first Nn octets) from the Encrypted-CEK field
Evaluates steps to derive the KEK per
Decrypts Encrypted-CEK to recover the 32-octet CEK

Encrypted-CEK size validation is specified in . To decrypt content, the Decryptor reads the 32-octet salt from the start of the DATA block, then derives payload_key from the CEK, encryption_parameters, and salt per . For each block i, the Decryptor computes key_i = block_key(i) (). For NMR AEADs, the Decryptor derives nonce_base and computes nonce_i = nonce_base XOR uint64(i). For non-NMR AEADs, the Decryptor reads each nonce from the stored metadata. Each block is decrypted using key_i, its nonce, ciphertext, tag, and data_aad(i, is_final) per . The location of these components depends on the layout:

Linear layout (): for non-NMR AEADs, each encrypted block contains nonce, ciphertext, and tag concatenated; for NMR AEADs, ciphertext and tag only.
Aligned layout (): for non-NMR AEADs, nonces and tags are in the header metadata array; for NMR AEADs, only tags are stored. Ciphertext blocks are at aligned offsets.

See for offset calculations.

Error Codes for Testing This appendix is informative. For interoperability testing, implementations MAY use the following error identifiers to categorize failures:

Error Code	Description	When to Emit
ERR_UNSUPPORTED_AEAD	Unknown AEAD algorithm	Parsing SAFE CONFIG
ERR_UNSUPPORTED_KEM	Unknown KEM identifier	Parsing hpke(...) step
ERR_INVALID_BLOCK_SIZE	Invalid Block-Size value	Parsing SAFE CONFIG
ERR_HPKE_NO_MATCH	No matching private key	Recipient discovery
ERR_HPKE_DECAP_FAILED	HPKE decapsulation error	CEK recovery
ERR_LOCK_AEAD_FAILED	Encrypted-CEK decryption failed	CEK recovery
ERR_PAYLOAD_AEAD_FAILED	Block decryption failed	Content decryption
ERR_BLOCK_OUT_OF_RANGE	Block index invalid	Content decryption
ERR_MALFORMED_BASE64	Base64 decoding error	Any Base64 field
ERR_DUPLICATE_FIELD	Repeated field name	Parsing SAFE CONFIG
ERR_DUPLICATE_PARAM	Repeated step parameter	Parsing Step lines
ERR_MISSING_SALT	pass(...) without `salt`	Parsing LOCK
ERR_MISSING_KEMCT	hpke(...) without `kemct`	Parsing LOCK
ERR_MULTIPLE_PASS_ONLY_LOCK	Multiple same-variant pass-only LOCKs	Discovery
ERR_NON_ASCII_HEADER	Non-ASCII in header	Parsing any header
ERR_RESOURCE_LIMIT	Size/count limit exceeded	Parsing any block
ERR_INVALID_SALT_LENGTH	salt not exactly 16 octets	Parsing `salt`
ERR_COMMITMENT_MISMATCH	Commitment verification failed	Key schedule
ERR_ACCUMULATOR_MISMATCH	Accumulator verification failed	Integrity check
ERR_TRUNCATION	Missing final block or block with is_final=0 at EOF	Content decryption

Armored Data Arithmetic This appendix is informative. In armored mode, Decryptors compute the block count N and final block size from the Base64 payload length. Let S_b64 be the payload string between the fences, len_b64 its length in characters, pad the number of trailing = signs (0, 1, or 2), and len_bin_total = 3 * floor(len_b64 / 4) - pad. The header region is 32 (salt) + 32 (commitment) + Nh (accumulator) octets. The encrypted block region is len_bin_ciphertext = len_bin_total - 64 - Nh. Let B = Block-Size and Nn = AEAD nonce length. For NMR AEADs, nonces are derived (not stored), so the per-block overhead excludes Nn. Define: A decryptor decrypting block index i computes octet offsets relative to the start of the encrypted block region (after salt, commitment, and accumulator): For each block index i, the Decryptor:

Extracts S_b64[char_start:char_end]
Base64-decodes to a temporary buffer tmp
Computes skip = byte_start mod 3
Selects encrypted_block = tmp[skip : skip + byte_len]
For non-NMR AEADs: parses nonce_i = encrypted_block[0:Nn] and ciphertext_i = encrypted_block[Nn:]. For NMR AEADs: ciphertext_i = encrypted_block and nonce_i = nonce_base XOR uint64(i) per
Determines is_final = 1 if i == N - 1 else 0
Constructs data_aad(i, is_final) per
Computes key_i = block_key(i) ()
AEAD-opens ciphertext_i under key_i with nonce_i and data_aad

Selective Decryption This appendix is informative. To decrypt block index i from a long object, a Decryptor first selects a candidate LOCK per . The decryptor constructs encryption_parameters from the SAFE CONFIG or from defaults, parses lock_nonce from Encrypted-CEK, evaluates the step sequence to derive the KEK, and opens Encrypted-CEK to recover the CEK. The decryptor reads the 32-octet salt from the start of the DATA block, then derives payload_key and acc_key from the CEK, encryption_parameters, and salt. It then locates block i in the payload. No other blocks need to be read or decoded. For binary encoding, read N and D from the header, then compute block i's ciphertext offset as (D + i) × B. The nonce and tag are at offset header_len + 64 + 8 + i × meta_len, where meta_len is Nn + 16 for non-NMR AEADs or 16 for NMR AEADs (). For armored encoding, the Decryptor must compute the Base64 character window covering block i and decode only that window, as described below.

Example: Armored Selective Block Decryption This example uses a non-NMR AEAD (AES-256-GCM, Nn=12). For NMR AEADs, omit Nn from per-block sizes (C = B + 16 instead of Nn + B + 16). Consider Block-Size=16384, Nn=12, and three blocks: two full blocks plus a 5000-octet final block. To decrypt block i=0, compute octet and character offsets (salt, commitment, and accumulator occupy the first 96 octets): Extract S_b64[128:22012], Base64-decode, then take 16412 octets as the encrypted block (skip = 0, no leading octets to discard). Parse the first Nn octets (12 for AES-256-GCM) as the stored nonce, compute block_key(i) (), and AEAD-open the remaining octets under block_key(i) with the extracted nonce and block AAD. For NMR AEADs, derive the nonce from nonce_base instead ().

Design Rationale This appendix is informative. SAFE's design choices reflect trade-offs between flexibility, performance, and simplicity. This section explains the rationale behind key architectural decisions.

Two-Tier Key Hierarchy SAFE separates the Content-Encryption Key (CEK) from the Key-Encryption Key (KEK) to enable multi-recipient encryption without duplicating payload ciphertexts.

Benefits A single CEK is generated once and used to encrypt the payload; each recipient's LOCK derives a KEK that wraps the same CEK. This design offers several advantages:

Storage and bandwidth efficiency: Adding recipients requires only adding LOCK blocks (typically < 1 KB each), not duplicating the entire payload. For large files, this is critical.
Key rotation: Recipients can be added or removed by re-wrapping the CEK under new KEKs without re-encrypting the payload.
Operational flexibility: The CEK remains constant while KEKs rotate, simplifying key management.

Trade-offs This design implies that all recipients share the same payload_key. Encryptors who require per-recipient payload keys (e.g., for fine-grained access control that survives CEK compromise) would need to encrypt multiple independent payloads. If recipients directly decrypted the payload with their KEK, each recipient would require a distinct copy of the ciphertext, multiplying storage and bandwidth costs.

Minimal Block AAD Block associated data is defined as Encode("SAFE-DATA", I2OSP(i, 8), I2OSP(is_final, 1)), binding each block to its position and finality. Suite parameters and LOCK-specific data are excluded from block AAD.

Rationale This choice prioritizes simplicity and O(1) random access:

Selective decryption: payload_key already depends on encryption_parameters, so block AAD need not repeat them. This avoids requiring every block decryption to reference the SAFE CONFIG.
Multi-recipient caching: Including LOCK-specific data (Step lines, kemct) would couple block decryption to a specific LOCK, preventing efficient caching of payload_key across multiple recipients.

Security Properties Suite and LOCK binding is indirect through the key hierarchy:

The KEK schedule binds encryption_parameters at initialization and final derivation, with all step_tokens folded between; Encrypted-CEK AEAD authenticates the CEK under this KEK.
The payload schedule binds payload_key to encryption_parameters via SafeDerive.
Block AAD includes the block index and finality flag, preventing reordering, splicing, truncation, and extension within a file.
The snapshot accumulator () binds all block tags under acc_key, providing file-level integrity without per-block decryption. Each contribution is a PRF output under acc_key; XOR accumulation is unforgeable without knowledge of the CEK.

Alternative Designs Considered An alternative design could include a "recipient_id" in block AAD, but this would require additional per-recipient metadata and complicate multi-recipient scenarios. SAFE's choice favors performance and simplicity for the common case of single-recipient or trust-equivalent multi-recipient files, while accepting that ciphertext blocks alone do not directly identify which LOCK unlocked them. SAFE provides built-in truncation and extension detection via the is_final flag in block AAD (). The final block is marked with is_final=1; all preceding blocks use is_final=0. This design, inspired by the STREAM construction , enables:

Truncation detection: a block with is_final=0 and no successor indicates truncation
Extension prevention: appending after is_final=1 fails AEAD verification
Streaming writes: encryptors buffer the last block until the stream closes, then encrypt it with is_final=1

Per-block random nonces () enable selective editing: individual blocks can be re-encrypted without affecting LOCK blocks or other blocks. This design trades a small storage overhead (Nn octets per block) for flexibility in payload modification.

Fixed HKDF Salt SafeDerive () uses a fixed string ("SAFE-v1") as the HKDF salt in its Extract step. The same string appears in the Encode-framed Input Keying Material (IKM), making its presence in the salt redundant but harmless. This design is intentional: the fixed salt binds every Extract call to the protocol version at the HMAC key position, while security relies on the entropy of the IKM, not the salt. All security-critical IKMs (CEK, step secrets, hedged random values) have sufficient min-entropy for this to hold. Krawczyk's analysis of HKDF shows that Extract with a fixed salt is a good randomness extractor when the IKM has high min-entropy. For the XOF single-stage variant, there is no separate salt; the version string appears only within the Encode frame.

Test Vectors This appendix is informative. This appendix provides a complete known-answer test for a passphrase-based SAFE encoding using default parameters (aes-256-gcm, Block-Size=65536, Hash=sha-256, Data-Encoding=armored). All values are hex unless noted. Readable format: ~~~~ -----BEGIN SAFE CONFIG----- Lock-Encoding: readable -----END SAFE CONFIG----- -----BEGIN SAFE LOCK----- Step: pass(kdf=argon2id, salt=AQEBAQEBAQEBAQEBAQEBAQ==) Encrypted-CEK: AgICAgICAgICAgICNSy+hajkQ05c2Y1lB8gHWd/kH74TpknfV6n39G0af5DGDhUx kuy4yDpkllameFSH -----END SAFE LOCK----- -----BEGIN SAFE DATA----- BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBARCMwpzeTV/TzafAnE2lUYE f3Av83xTqOF+sjQnMWg5BUtBYPGvhL10+7HPf9zK5psgJ8f/3GenoDvDPBuUiaTo AwMDAwMDAwMDAwMDtCuhJcxdN2rvA/HsPsvJyWxCZCZflN6koTErvQ== -----END SAFE DATA----- ~~~~ Same object in armored format (default Lock-Encoding). The armored LOCK body is Base64(Encode(step, ecek)) per :

X25519 Test Vector This appendix is informative. This appendix provides a complete known-answer test for a single X25519 recipient using DHKEM(X25519, HKDF-SHA256) per . All values are hex unless noted. The ephemeral and recipient keys are from RFC 9180, Appendix A.7.1 (DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM), so the shared_secret value can be independently verified against that appendix.

Auth Mode Test Vector This appendix is informative. This appendix provides a known-answer test for Auth mode HPKE (X25519) with a single recipient. The recipient keys are the same as . All values are hex unless noted.

Multi-Block Test Vector This appendix is informative. This appendix provides a known-answer test with two blocks, demonstrating block index > 0, is_final transitions, and accumulator XOR of multiple contributions. Uses a passphrase LOCK with default parameters. All values are hex unless noted.

SafeDerive Test Vectors This appendix is informative. These vectors validate the SafeDerive function in isolation, independent of the SAFE protocol. Inputs are deliberately short for readability. See for the definition. Common inputs for all vectors:

Hash=sha-256, L=32

Hash=sha-256, L=16

Hash=turboshake256, L=32

Hash=turboshake256, L=16

Defining New Step Types This appendix is informative. New step types can be defined and registered to extend SAFE with additional authentication mechanisms. This section illustrates the process using three hypothetical steps: two Privacy Pass Key Derivation Function (PPKDF) steps for token-gated key derivation (), and a WebAuthn PRF step for hardware token authentication.

Example: Privacy Pass Steps Privacy Pass type 0x0001 tokens use a Verifiable Oblivious Pseudorandom Function (VOPRF) . The client constructs a TokenInput containing a nonce, blinds it, and sends the blinded element to the issuer. The issuer evaluates its PRF on the blinded element and returns the result. The client unblinds to obtain the authenticator, which is a deterministic function of the TokenInput and the issuer's secret key. In normal issuance the nonce is random, making each token unique. PPKDF sets the nonce to a deterministic value derived from the SAFE context, so the authenticator is reproducible and serves as step key material. The issuer's behavior is unchanged and cannot distinguish a PPKDF request from normal token issuance. Two step types use this mechanism:

ppkdf: token-gated key derivation with application-supplied context.
ppkdf-pass: token-gated key derivation with password-derived context for online throttling.

Shared Parameters

issuer (REQUIRED):: Server name (host or host:port) of the Privacy Pass token issuer. The issuer holds the VOPRF key pair; its public key pkI must be known to the client.
salt (REQUIRED):: Base64-encoded salt; must decode to exactly 32 octets. Generated at encryption time using SafeRandom.

The binding step_token uses the Encode form ():

ppkdf: Encode("ppkdf", issuer, salt)
ppkdf-pass: Encode("ppkdf-pass", issuer, kdf, salt)

where issuer and kdf are UTF-8 strings and salt is the raw decoded 32 octets.

ppkdf Step The ppkdf step provides token-gated key derivation with application-supplied context. Token form: ) ]]> Grammar: Derivation: Decode salt to salt_bytes (32 octets). Compute a deterministic nonce for the TokenInput: where binding_step_token is the Encode-based binding form defined in . Construct a type 0x0001 TokenInput (, Section 5.1) with nonce as above. Set challenge_digest to SafeDerive("SAFE-PPKDF", TokenChallenge, encryption_parameters, 32), using a TokenChallenge with issuer_name = issuer and empty redemption_context and origin_info. Blind the TokenInput and send in a standard type 0x0001 TokenRequest. The issuer evaluates the VOPRF and returns a TokenResponse. Verify the VOPRF proof and unblind to obtain the authenticator (32 octets). Set step_secret = authenticator.

ppkdf-pass Step The ppkdf-pass step adds password-derived input. Each password guess requires a VOPRF evaluation from the issuer. Token form: ) ]]> Grammar: The kdf parameter selects the password KDF using the same algorithms and default parameters as the pass() step (). Derivation: Decode salt to salt_bytes (32 octets). Derive pw32 from the user's password using the KDF indicated by the kdf parameter, with salt_bytes as salt input and the default parameters defined in . Compute the deterministic nonce: Execute the PPKDF protocol as in the ppkdf step using this nonce. Set step_secret = authenticator.

IANA Registry Entries Registration of ppkdf and ppkdf-pass is deferred to a separate document; this appendix is informative. A registration for these steps would include:

Step Name	Parameters	Inputs	Secret	Ref
ppkdf	issuer=X, salt=X	PPKDF token	32 octets	(this doc)
ppkdf-pass	issuer=X, kdf=X, salt=X	PPKDF token, password	32 octets	(this doc)

Security Considerations for Privacy Pass Steps For ppkdf: The issuer sees only the blinded_element. It cannot learn context, step_secret, or anything about the SAFE file. The VOPRF proof lets the client detect the wrong issuer key. Compromise of skI enables offline computation of step_secret for any context, breaking the online-gating property. For ppkdf-pass: Each password guess requires a VOPRF evaluation; issuer rate limits control guessing frequency. The issuer never sees the password-derived context. Compromise of skI still requires inverting the memory-hard KDF to recover the password. Example LOCK block: ) Encrypted-CEK: Base64-encoded encrypted CEK -----END SAFE LOCK----- ]]>

Example: WebAuthn PRF Step A WebAuthn-based step would allow hardware token authentication using the PRF extension defined in Web Authentication Level 3 . Unlike WebAuthn assertions (signatures), the PRF extension provides deterministic output suitable for SAFE's step model.

Step Definition

Step name:: webauthn-prf

The webauthn-prf step token has three forms: The parameters are:

rpid (OPTIONAL):: The WebAuthn relying party identifier. When present, the Decryptor uses this rpId for the WebAuthn ceremony. When omitted, selects anonymous RP mode.
salt (REQUIRED):: The Base64-encoded PRF salt; must decode to exactly 32 octets. Generated at encryption time using SafeRandom.
label (OPTIONAL):: A human-readable display name for this credential (e.g., "YubiKey", "Phone"). Not included in the binding step_token; see .

Credential selection is delegated to the authenticator via WebAuthn's allowCredentials mechanism. The Decryptor passes all candidate credential IDs for the rpId; the authenticator selects the matching credential internally. Grammar:

Anonymous RP mode:: When rpid is omitted from the token, the Decryptor tries each rpId for which it holds credentials. Each rpId requires a separate WebAuthn ceremony (and potentially a user prompt). Privacy benefit: hides the relying party from passive observers. Cost: one ceremony per candidate rpId.
Derivation:: The authenticator evaluates the PRF extension with the selected credential and the decoded salt: Inputs: credential (local, selected by authenticator for the rpId), prf_salt (from token).
Encode form:: Encode("webauthn-prf", rpid, salt). rpid is UTF-8; salt is the raw decoded 32 octets. rpid is always present in the binding form even when omitted on-wire; when omitted, the Encryptor or Decryptor uses the rpId from the WebAuthn ceremony. Label is not included in binding.
Validation:: salt must decode to exactly 32 octets. rpid, when present, must match the hostname grammar 1*(ALPHA / DIGIT / "-" / ".").

Example LOCK:

IANA Registry Entry

Step Name	Parameters	Inputs	Secret	Ref
webauthn-prf	rpid=X, salt=X	Credential, rpId	32 octets	(this doc)

Security Considerations for WebAuthn PRF Step The WebAuthn PRF step provides hardware-bound key material (the authenticator holds the secret), user presence verification (touch required), phishing resistance (rpid binding), and offline decryption capability once the PRF output is computed. The PRF extension requires WebAuthn Level 3 support in the browser. Non-discoverable credentials wrap key material in the credential ID; losing the credential ID means losing access to the encrypted file. Unlike the Privacy Pass steps, no server-side rate limiting is possible. Privacy: rpid in cleartext reveals the relying party to passive observers. Anonymous RP mode (rpid omitted) hides this but the rpId may still be guessable from context. Trial bounds: anonymous RP mode requires one WebAuthn ceremony per candidate rpId. Decryptors should impose a local bound on the number of rpIds to try. Prefer identified mode when privacy is not required.