]> Certisyn, Inc.

US jhillier@certisyn.com

Security confidentiality post-quantum one-time pad traffic analysis cover traffic verifiable delay function multi-substrate defence finance sovereign hash agility This document specifies the Chorale Protocol, a secure packet transmission system with active integrity assurance, for use cases requiring resistance to interception, traffic analysis, replay, tampering, and retrospective decryption by adversaries with future quantum capability. Chorale defines three confidentiality regimes, computational, everlasting and information-theoretic, and states the keying conditions under which each may be relied upon. The information-theoretic regime requires an independently corroborated co-presence or quantum-key-distribution strand consumed as an unexpanded pad. A session keyed by a derived keystream is computational and is reported as computational. A conforming implementation fails closed and refuses to report a regime its keying does not support. The protocol composes a per-session secret graph topology that determines packet ordering without transmitting any ordering information on the wire, cascade-integrity witnessing over the hidden topology, cover packets carrying valid-looking witnesses for fictional sessions, per-packet Verifiable Delay Function time-lock sealing, multi-source physical-entropy one-time pad composition with sovereign jurisdictional separation, multi-substrate flight requiring threshold reconstruction across diverse path types, and a tombstone ledger that makes pad reuse structurally impossible at the receiver. This version introduces hash-family negotiation at handshake, raising the default hash function for HKDF key derivation, VDF time-lock sealing, and server-blind relay commitments from SHA-256 to SHA-512, with SHA3-512 admitted as a Keccak-family alternative for adversary-evolution- tolerant postures and SHA-256 retained as a backward-compatible legacy mode for resource-constrained devices. The protocol is intended for use by intelligence agencies, central banks, treaty-bound corridors, regulator-to-regulator communications, and other settings demanding the strongest practical confidentiality and integrity properties.

Introduction Existing transport-layer cryptographic protocols including provide confidentiality based on computational hardness assumptions that are not robust to large-scale fault-tolerant quantum computation. Post-quantum key encapsulation mechanisms (see ) mitigate the long-term risk but do not eliminate the threat of harvest-now- decrypt-later collection of ciphertext. Information-theoretic confidentiality via one-time pads provides provable secrecy independent of adversary computational power, but practical deployment is constrained by the key-distribution problem and by operational failures arising from pad re-use. This document specifies the Chorale Protocol, a packet-based secure transmission system that composes pad-based confidentiality with a set of mechanisms that defend the pad-based scheme against the operational and physical-layer attacks that have historically broken one-time pad deployments in practice. The confidentiality regime a session attains is determined by how its keying material reaches the payload, and is specified in . The protocol is designed for use by parties able to perform a one-time co-presence event to establish session anchor material, including intelligence agencies operating within allied corridors, central banks operating within multilateral settlement frameworks, regulator-to-regulator filings within mutual-recognition treaty zones, and other contexts in which the additional setup cost is warranted by the confidentiality requirements.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms:

Session Anchor:

A per-session secret comprising at least a topology graph, a one-time pad, a Merkle root over expected plaintexts, a duress codeword, and a post-quantum digital signature binding the anchor to the sender's verifiable credential. Established during a co-presence event.

Topology Graph:

A graph G = (V, E) with N nodes wherein each node v is associated with a set N(v) of at most K named neighbour-nodes. The edge structure is a per-session secret never transmitted over any network substrate.

Atomic Packet:

A single unit of message decomposition corresponding to exactly one node of the topology graph.

Neighbour-Witness:

A cryptographic hash, attached to each atomic packet, of the payloads of the K neighbours of the corresponding node in the topology graph.

Cover Packet:

A packet structurally indistinguishable from an atomic packet but carrying random payload and a neighbour-witness computed against a fictional session topology generated fresh per cover-packet batch.

Tombstone Ledger:

A synchronised append-only record at both sender and receiver endpoints of per-pad-section consumption.

Substrate:

A network channel suitable for packet transport. Multiple heterogeneous substrates (terrestrial fibre, satellite, microwave, mesh radio, sneakernet courier, sovereign dedicated fibre) are used in combination.

Co-presence Event:

A one-time event during which the sender and receiver establish the Session Anchor via a channel guaranteeing secrecy against any non-endpoint adversary.

Hash Family:

One of a small set of cryptographic hash function families permitted for use as the underlying primitive of HKDF key derivation , VDF iterative sealing, and server-blind relay commitments within a session. Negotiated once per session at handshake and bound for the lifetime of the session.

Protocol Overview The Chorale Protocol comprises the following steps:

1. Co-presence. The sender and receiver establish a Session Anchor via a co-presence event . The anchor MUST include a Topology Graph and a one-time pad. The anchor SHOULD include a duress codeword, a Merkle root over expected plaintexts, and a post-quantum digital signature binding the anchor to the sender's verifiable credential.
2. Hash-family negotiation. As part of the rendezvous payload exchanged at handshake, the sender and receiver each advertise a list of supported hash families. They converge on the strongest mutually-supported family per the algorithm in . The negotiated family is bound for the lifetime of the session and drives all subsequent HKDF, VDF, and commitment-layer computations.
3. Pad generation. The one-time pad is generated by combining, via bitwise exclusive-or, the outputs of at least two and preferably at least three uncorrelated physical entropy sources resident in distinct sovereign jurisdictions .
4. Decomposition. The sender computes ciphertext C as the bitwise exclusive-or of the plaintext message with a portion of the one-time pad. The sender records the pad consumption in the Tombstone Ledger. The sender optionally applies a per-packet reading-frame offset, then partitions C into N Atomic Packets each corresponding to one node of the Topology Graph.
5. Witnessing. For each Atomic Packet P_i corresponding to node v_i, the sender computes a Neighbour-Witness W_i = H(P_{N(v_i)[1]} || P_{N(v_i)[2]} || ... || P_{N(v_i)[K]}) where H is the hash function selected by the negotiated hash family (see and ). The Neighbour-Witness is appended to the packet.
6. Time-lock sealing. For each Atomic Packet, the sender computes a Verifiable Delay Function time-lock seal S_i = VDF(P_i || W_i, T) requiring T sequential operations to compute and to invert. The seal is appended to the packet. See .
7. Cover packet generation. The sender generates a quantity of Cover Packets at least equal to the quantity of Atomic Packets. Each Cover Packet has random payload and a Neighbour-Witness computed against a fictional session topology generated fresh per cover-packet batch. The fictional topology MUST be discarded after dispatch.
8. Flight. The sender transmits Atomic Packets and Cover Packets over two or more Substrates of heterogeneous type. The release schedule is modulated by prime-modular timing . Multi-substrate flight MUST be configured such that no single substrate carries more than K-1 of the M shares required for reconstruction, where K and M are system parameters.
9. Reassembly. The receiver collects transmitted packets across an arbitrary time window. For each packet, the receiver attempts to match the Neighbour-Witness against the receiver's local copy of the Topology Graph. Packets whose witnesses do not validate are classified as Cover Packets and discarded. For each Atomic Packet, the receiver validates the Neighbour-Witness against the K-neighbour-packet payloads. If any validation fails, the receiver enters a cascade-failure state and aborts reassembly.
10. Time-lock inverse. For each Atomic Packet, the receiver computes the inverse of the time-lock seal S_i in parallel across multiple physical processors.
11. Plaintext reconstruction. The receiver orders the validated, unsealed packet payloads according to the Topology Graph, producing the ciphertext stream C. The receiver applies the inverse of the per-packet reading-frame offset, if applicable. The receiver computes the plaintext P = C XOR K[i:i+L].
12. Final verification. The receiver computes the Merkle root of P and compares to the Merkle root shared at co-presence. If the roots match, the plaintext is accepted; otherwise the session is rejected.
13. Tombstone update. Both endpoints update the Tombstone Ledger to mark consumed pad sections. Any subsequent attempt to consume a marked section MUST be structurally rejected at the receiver.

Co-presence Event The Session Anchor MUST be established via a co-presence event through one of the following channels:

• In-person meeting of the sender and receiver, with the anchor written to identical removable media at each endpoint;
• Quantum Key Distribution session between endpoints;
• A sovereign trusted exchange operating under bilateral or multilateral treaty (e.g., the AUKUS dedicated communications corridor);
• Any other channel for which the parties can demonstrate that the anchor cannot be observed by any non-endpoint adversary.

The Session Anchor includes:

• The Topology Graph G with N nodes and K-degree neighbour structure (RECOMMENDED N >= 64, K = 7, minimum girth >= 5);
• The one-time pad K of length sufficient for the projected message volume of the session;
• A session identifier known only to the endpoints;
• A Merkle root computed over one or more expected plaintexts;
• A duress codeword known only to the endpoints;
• A post-quantum digital signature binding the anchor to a verifiable credential of the sender.

The Topology Graph and the one-time pad MUST NOT be transmitted over any network substrate after the co-presence event has completed.

Hash Family Negotiation Implementations MUST select a single hash family per session at the rendezvous-and-handshake step, and MUST bind that selection for the lifetime of the session. This section defines the registered families, the negotiation algorithm, and the binding semantics.

Registered Hash Families The following hash families are defined by this document.

Identifier	Underlying primitive	Default for
sha-256	SHA-256	Backward-compatible legacy / constrained dev
sha-512	SHA-512	Sovereign and Allied-corridor deployments
sha3-512	SHA3-512	Adversary-evolution-tolerant posture

The sha-256 identifier is RETAINED as the legacy backward- compatible family. Resource-constrained devices that cannot accommodate the 64-byte block size of SHA-512 MAY advertise sha-256 only. Implementations supporting sha-256 MUST NOT use shorter digests for HKDF or VDF computations. The sha-512 identifier is the RECOMMENDED default for new deployments. It is the mandatory-to-implement family for sovereign corridor and Allied-corridor profiles, and is the negotiation default when both peers advertise it. The sha3-512 identifier is OPTIONAL. It is RECOMMENDED for adversary-evolution-tolerant postures where deployment is intended to remain resilient against future cryptanalytic advances in the Merkle-Damgard SHA-2 construction. The Keccak sponge construction is structurally independent of the Merkle-Damgard lineage, providing cryptographic-construction diversity against the same threat class that the multi-source entropy generator addresses at the entropy layer.

Rendezvous Payload Field The rendezvous payload exchanged at handshake MUST include a hash_family field carrying the list of hash family identifiers the sending peer supports, ordered by descending preference. The field MUST be a JSON array of strings drawn from the registered set above. Example rendezvous payload fragment:

Negotiation Algorithm On receipt of the peer's rendezvous payload, each endpoint MUST compute the negotiated hash family as follows:

1. Form the intersection of the local supported list and the remote advertised list.
2. If the intersection is empty, the session MUST be aborted with a no-common-hash-family error. Implementations MUST NOT silently downgrade to an out-of-set algorithm.
3. From the intersection, select the strongest family by the following preference ordering, from strongest to weakest: sha-512 > sha-256 ]]>
4. Both endpoints, executing the same algorithm against the same two advertised lists, MUST reach the same selection. Disagreement is a protocol violation and MUST abort the session.

The negotiated identifier MUST be carried in the Session Anchor and MUST be recorded in the session record on both endpoints for audit.

Binding Semantics Once negotiated, the hash family is bound for the lifetime of the session. The negotiated family MUST drive:

• HKDF key derivation of the session topology graph bytes and the one-time pad bytes from the ECDH shared secret;
• The HMAC primitive used for any per-session MAC key derivation and per-packet packet-authentication tag;
• The VDF iterative-hash construction used for per-packet time-lock sealing (see );
• The server-blind relay commitment digest length and computation (see ).

The negotiated hash family MUST NOT drive the digital-signature hash used by the ECDSA-P256 signature primitive of , which remains SHA-256 per the canonical pairing of the curve. The hash-family negotiation surface of this section is explicitly scoped to HKDF, VDF, MAC, and commitment computation. Signature hash agility is out of scope for this version. A session MUST NOT change hash families mid-flight. A peer wishing to upgrade the family for subsequent traffic MUST establish a new session via a fresh co-presence event.

SAS Binding of the Negotiated Family The out-of-band Short Authentication String (SAS) recited at the end of the rendezvous-and-handshake step MUST cover the negotiated hash_family byte in addition to the ECDH public keys. The SAS preimage is constructed as: and the SAS digest is computed under the negotiated family: Implementations MUST also include the hash_family identifier in the HKDF info label that derives the SAS keystream so the SAS words themselves diverge across families even before the digest step. Either binding alone would suffice; both together provide defence in depth. This binding is what makes an active man-in-the-middle attempting a hash-family downgrade detectable at the SAS step. See for the threat model and analysis.

Multi-Sovereign Entropy Generator This section governs the generation of pad material for the everlasting and information-theoretic regimes of . Implementations MUST generate that pad material by combining outputs of at least two uncorrelated physical entropy sources by bitwise exclusive-or. Implementations SHOULD use at least three sources resident in at least three distinct sovereign jurisdictions to ensure that compromise of any single source (whether by adversary infiltration, supply-chain attack, or sovereign-government coercion) does not reduce the effective entropy of the pad. Recommended source types include:

• A DNA sequencer producing noise from per-base call-quality jitter of an ongoing biological sequencing run;
• A quantum random number generator producing noise from a vacuum- fluctuation or radioactive-decay source;
• An atmospheric radio noise generator producing noise from a wide- band radio receiver tuned to an unallocated frequency band.

HKDF Key Derivation Implementations using the client-keyed handoff (the standard form for new deployments) derive the session Topology Graph bytes and the payload keystream bytes from an ECDH shared secret via HKDF . A keystream derived in this way is not a one-time pad. Expansion of a shared secret cannot increase its entropy, and the shared secret is itself established under a computational assumption. A session keyed by this path therefore attains the computational regime of and MUST report it as such. Implementations MUST NOT describe a derived keystream as a one-time pad, and MUST NOT claim a raised regime on the strength of the pad-generation requirements of unless the generated material reaches the payload unexpanded. The HKDF hash function MUST be the SHA-2 or SHA-3 function corresponding to the negotiated hash family of :

• sha-256 => HKDF-SHA-256
• sha-512 => HKDF-SHA-512 (RECOMMENDED default)
• sha3-512 => HKDF-SHA3-512

HKDF emits an arbitrary-length output keystream and the on-wire materialisation of derived bytes is unchanged across families. The substantive change introduced by raising the default from HKDF-SHA-256 to HKDF-SHA-512 is in the internal mixing margin: the larger internal state and block size of SHA-512 give a wider collision-resistance band against any future cryptanalytic discovery affecting the SHA-2 family's compression function. HKDF-SHA3-512 admits a Keccak-construction alternative for deployments wishing to diversify away from the Merkle-Damgard construction altogether. Implementations MUST use distinct info strings for the topology and pad derivations so that the same shared secret produces unrelated keystreams. The RECOMMENDED info values are chorale-topology-N{N}-K{K} for the topology and chorale-keystream-{padBytes} for the payload keystream.

Verifiable Delay Function Sealing Implementations MUST attach a Verifiable Delay Function (VDF) seal to each Atomic Packet. Two constructions are admitted:

• An algebraic VDF in an RSA group, per and , for deployments holding the hardware to evaluate modular squarings at production rate;
• An iterative-hash VDF based on the negotiated hash family, for deployments preferring a software-only path with no RSA group dependency.

The iterative-hash VDF baseline is 200 rounds of iterated application of the negotiated hash family to the concatenation of the packet payload and the neighbour-witness, with each round's output fed as the input to the next. Where the negotiated family is sha-256 the construction is equivalent to the v-01 baseline. Where the negotiated family is sha-512 or sha3-512 the per-round work approximately doubles relative to the SHA-256 baseline, since SHA-512 and SHA3-512 each process the same number of input bits per round through a larger internal state. Both sender and receiver pay this work symmetrically; the cost is bounded at protocol setup by the choice of round count and hash family. The 200-round count is a deployment baseline. Implementations MAY raise the round count for stronger sequential-cost bounds at the corresponding increase in send and verify latency. The round count MUST be carried in the seal field so the receiver can reproduce the construction without negotiating round count separately. The rationale for the doubled per-round work is that the VDF is the anti-replay and anti-shortcut primitive against future adversaries who may develop parallel-execution shortcuts on SHA-2-family iteration. A larger per-round state surface raises the bar for any such shortcut. The cost trade is symmetric: the sender's send-time cost rises in lockstep with the adversary's inversion cost, so an honest deployment is not disadvantaged by the upgrade.

Server-Blind Relay Commitment Layer The Chorale relay layer is server-blind: relays carry opaque bytes and a fixed-length commitment to per-session material (topology hash, pad hash, short-authentication-string hash) without holding any preimage. Commitment integrity at the relay defends against an adversary who compromises the relay infrastructure and attempts to substitute material at the rendezvous step. The commitment digest length MUST match the negotiated hash family of :

• sha-256 => 32-byte SHA-256 commitment (legacy)
• sha-512 => 64-byte SHA-512 commitment (RECOMMENDED default)
• sha3-512 => 64-byte SHA3-512 commitment

The upgrade from 32-byte SHA-256 to 64-byte SHA-512 commitments doubles the collision-resistance band of the commitment digest while increasing per-session storage at the relay by 32 bytes per commitment (negligible for any practical deployment). The 32-byte SHA-256 commitment MUST be retained as a legacy mode for backward-compatible negotiation with constrained-device endpoints advertising only sha-256. The relay MUST NOT interpret commitment bytes. The relay MUST record the digest length advertised in the session record and MUST reject mismatched-length commitment-update attempts within a single session.

Cryptographic Profile Implementations MUST support SHA-256 , SHA-512 , and SHA3-512 for Neighbour-Witness computation, with the choice of function within a session bound by the negotiated hash family of . Implementations SHOULD also support SHA3-256, BLAKE2b, and BLAKE3 for tenant- selected digest profiles outside the negotiated set. Implementations MUST support Ed25519 and ECDSA-P256 for digital signatures. ECDSA-P256 signatures are canonically paired with SHA-256 per ; this pairing is NOT subject to the hash-family negotiation of . Implementations SHOULD also support ECDSA-P384 for Commercial National Security Algorithm Suite 2.0 transitional compatibility. Implementations MUST support CRYSTALS-Dilithium / ML-DSA for the post-quantum signature on the Session Anchor. The selection of cryptographic profile per session is a tenant configuration parameter. The selection MUST be recorded in an auditable activation log such that the algorithm used for any past envelope can be determined.

Packet Flight Atomic Packets and Cover Packets are released into the network with release schedule modulated by per-session prime-modular timing. Specifically, each packet is released at a time t_i congruent to a_i (mod p) where p is a per-session-secret prime number and a_i is a per-packet release offset derived from session-derived randomness. Multi-substrate flight is configured such that no single substrate carries more than K-1 of the M shares required for reconstruction. RECOMMENDED parameters: K = 5, M = 8.

Tombstone Ledger Each pad section is assigned a unique tombstone identifier at issuance. On consumption, the tombstone is marked spent. Any subsequent attempt to consume a spent tombstone MUST be structurally rejected at the receiver endpoint, regardless of whether the sender intentionally or accidentally re-uses a pad section. The Tombstone Ledger MUST be maintained synchronously at both sender and receiver endpoints.

Duress Codeword If the Session Anchor includes a duress codeword, use of the duress codeword in place of the authentic session codeword in a packet payload MUST cause the protocol to complete successfully at the receiver - to avoid alerting the adversary that the duress has been detected - while silently flagging the receiver-side audit log to a duress condition. Subsequent packets received after the duress flag is set SHOULD be treated as potentially compromised and routed to a duress-quarantine queue.

Cascade Integrity Property The Chorale Protocol provides cascade integrity over the hidden topology. If an adversary captures the dispatched packets and modifies a single bit of any single packet, that modification invalidates the Neighbour-Witness recorded for that packet at each of the K packets that name it as a neighbour. Because the adversary does not know the Topology Graph, the adversary cannot identify which K packets must be additionally modified to maintain consistency. Each attempted single-packet forgery cascades to invalidate K+1 Neighbour-Witnesses at the receiver. For Topology Graphs of girth >= 5 and K = 7, the probability that an adversary modifying random subsets of packets can maintain Neighbour- Witness consistency without knowledge of the topology decreases exponentially with the number of packets modified.

Polyglot Cover-Encoding Layer Cover packets, as defined in , are by themselves cryptographically indistinguishable from real packets at the witness layer. However, an adversary performing traffic-shape analysis on a single substrate may still derive useful information from the encoding presentation of the captured stream: if every packet on the wire is base64-encoded ciphertext of similar length, the substrate itself becomes a fingerprint indicating that it carries Chorale-like traffic. This section defines an OPTIONAL extension which generates each cover packet in one of a heterogeneous set of presentation encodings, with the encoding assignment derived from a session-bound seed shared between sender and receiver.

Cover Encoding Set Implementations supporting this extension MUST be able to generate cover packets in each of the following presentation encodings:

• base64-binary - random bytes encoded as base64 (the legacy form)
• hex - random bytes encoded as lowercase hexadecimal
• english-prose - syntactically valid English text from a wordlist
• german-prose - syntactically valid German text from a wordlist
• mandarin - Mandarin Chinese filler phrases
• arabic - Arabic filler phrases
• json-noise - JSON-shaped key-value pairs with random values
• log-line - structured log line shape (timestamp + level + msg)

Real packets MUST continue to use the base64-binary presentation because the receiver decode path requires deterministic byte recovery. Only cover packets carry the polyglot presentation.

Per-Packet Encoding Selection For each cover packet at index i in a batch of N cover packets, the sender selects the encoding as: where H is the session's negotiated hash family (see and ) and cover_batch_nonce is a fresh 16-byte random value generated at the start of each cover batch. The receiver, holding the session topology, discards cover packets at the witness validation stage and never invokes the polyglot decoder.

Security Property An adversary observing the complete on-wire stream on any single substrate sees a deliberately heterogeneous mix of presentation shapes. Without the session topology AND the cover-batch nonce, the adversary cannot determine:

1. which packets are real vs cover;
2. what presentation encoding the real packets use (they appear as one base64 stream among seven others);
3. whether the substrate carries a single coherent transmission, multiple overlapping transmissions, or unrelated traffic.

This extends the indistinguishability guarantee of cover packets from the cryptographic witness layer (which holds against any adversary) up to the substrate-encoding fingerprint layer (which holds against the specific adversary class of traffic-shape analysers).

External Relay Manifest A Chorale deployment achieves substrate diversity (claim 6 of the underlying patent) by dispatching atomic packets across multiple physical network paths. This section specifies an OPTIONAL registry mechanism by which a deployment may declare and discover the relay endpoints that constitute its substrate fabric.

Relay Registry Schema Each registered relay endpoint is described by a JSON object with the following fields: ", "provider": "cloudflare" | "fly" | "render" | "vercel" | "aws" | "gcp" | "azure" | "self-hosted", "region": "", "jurisdiction": "", "substrates": [ "fibre" | "satellite" | "microwave" | "mesh" | "sneakernet" | "sovereign" ], "forward_url": "https:///forward", "shared_secret_hash": "" } ]]> The shared_secret_hash length and computation MUST match the negotiated hash family of : 64 hex characters for SHA-256, 128 hex characters for SHA-512 and SHA3-512.

Dispatch HMAC Authentication Every dispatch from sender to a registered relay endpoint MUST carry an HMAC signature in the X-Chorale-Signature header, computed under the HMAC primitive parameterised by the session's negotiated hash family of , over the request body using the shared secret recorded against the relay's registry entry. Relays MUST reject requests whose signature does not match. This prevents a registered relay from being weaponised as an injection point by third parties.

Substrate Diversity Constraint A deployment compliant with this extension SHOULD maintain a registry such that the active relays collectively satisfy:

• at least three (3) distinct jurisdiction values;
• at least three (3) distinct provider values;
• coverage of every substrate type the deployment dispatches across.

When these conditions hold, the security property of is strengthened from "no single substrate carries more than the threshold" to "no single jurisdiction and no single provider observes more than the threshold", which is the operational form of the property that defends against state-level adversaries with single-jurisdiction reach.

Reproducibility Surface This section specifies an OPTIONAL test-vector reproducibility surface that permits any third party to verify implementation conformance to this draft without requiring access to implementation source code.

Canonical Test Vectors A conforming implementation SHOULD ship a canonical set of deterministic test vectors. Each test vector specifies:

• id - globally unique identifier (e.g. CHORALE-VEC-001)
• hash_family - the negotiated hash family identifier
• N, K - topology parameters
• pad_hex - fixed pad bytes as hex
• topology_edges - fixed neighbour graph
• plaintext - fixed input string
• expected.merkle_root - digest of plaintext UTF-8 bytes under the vector's hash family
• expected.pad_consumed - pad bytes consumed by the encoding
• expected.real_body_sha - per-node body digest array under the vector's hash family
• expected.real_neighbour_witness - per-node witness array under the vector's hash family

Three minimum vectors are RECOMMENDED per hash family:

• one short vector with N=4, K=2, plaintext length <= N;
• one medium vector with N=8, K=3, plaintext length > N;
• one edge-case vector with plaintext length < N.

Cross-Implementation Agreement A conforming implementation SHOULD expose a public reproducibility endpoint at which:

1. Every test vector is executed against the server-side implementation;
2. The same vectors are re-executable against a browser-resident implementation (or other independent implementation);
3. A cross-implementation agreement matrix is rendered showing, for each vector, whether the implementations produced byte-identical outputs at every protocol layer (merkle root, body hashes, neighbour witnesses, reassembled plaintext) under the vector's declared hash family.

Any party may re-execute the agreement matrix without source-code access. This establishes claim-to-code traceability for the protocol's named properties and is the foundation on which third-party security review is conducted.

Comparison with Related Work (TLS 1.3) provides confidentiality based on computational hardness assumptions vulnerable to retrospective decryption under quantum capability. Chorale attains the same computational regime on its derived-keystream path, and admits an everlasting or information-theoretic regime at the payload layer where the keying conditions of are met, which TLS does not define. established the mixnet as the response to traffic analysis. The Tor protocol, in that lineage, provides pseudonymity but remains subject to traffic analysis and defines no payload-layer confidentiality regime above the computational. provides cover traffic at the timing level; Chorale extends cover indistinguishability to the integrity-witness structure level. secret sharing and AONT-RS encode share ordering or share identity within the share; Chorale moves share ordering into the per-session secret Topology Graph and transmits no ordering information on the wire. time-lock puzzles and VDFs are used per-message in prior art; Chorale applies them per-packet to multiply adversary cost by N while preserving receiver parallelisability.

Implementation Considerations Implementations should consider the following operational matters: Endpoint hardware tamper evidence. Endpoints should be commissioned with optical microscopy verification of the silicon dies of the multi-sovereign entropy generator and the Verifiable Delay Function evaluator against vendor reference images. Electromagnetic emanation profiling against a baseline recorded in a certified anechoic chamber should be performed prior to each session. Pad replenishment. The one-time pad is exhausted by transmission. Implementations should provide for pad replenishment via further co-presence events or via Quantum Key Distribution at the rate required for the projected message volume. Receiver hardware parallelism. The Verifiable Delay Function evaluator at the receiver should be capable of parallel operation across multiple physical processors to minimise reassembly latency. Substrate diversity. Implementations should ensure that the substrates available to a session include at least one substrate that is resilient to anticipated adversary disruption capabilities (e.g., undersea cable cut, satellite spot-beam interception, microwave path obstruction).

Covert Posture and Constant-Rate Pacing A session MAY set a covert flag. When set, the stealth defence set - constant-rate pacing, cover-continuity, decoy pairing, and rotating rendezvous - is enabled at ANY posture, decoupling undetectability from the threat tier. A non-covert session behaves exactly as in prior revisions. Under constant-rate pacing the endpoint emits ONE fixed-size cell on a fixed cadence, whether or not real data is queued. A real cell carries an encrypt-then-MAC frame body; a chaff cell is uniform random of the identical wire size. Real and chaff cells are byte-for-byte indistinguishable to any party without the session key: distinguishing a real cell from chaff reduces to forging the cell MAC. Timing analysis, volume analysis, and the "who is active when" signal are therefore removed from the intra-stream layer. Because the defence relies on the stream being message-independent, the stream MUST run continuously; starting or stopping it in step with message activity would reintroduce the signal it removes.

Confidentiality-Regime Floor and Corroboration A session achieves one of three confidentiality regimes, determined by its keying method: computational (client hybrid-PQC handoff or server-generated pad), everlasting (bounded-storage class), or information-theoretic (an unconditional co-presence or QKD strand). A policy MAY declare a requiredFloor. Every send path enforces the floor identically and FAILS CLOSED: a send is refused when the regime relied upon is below the floor, when the policy is malformed, or on infrastructure error. A raised regime (everlasting or information-theoretic) is RELIED upon only when the co-presence or bounded-storage strand is INDEPENDENTLY CORROBORATED - for example by completing the out-of-band SAS confirmation of . An un-corroborated claim does not inflate the regime; it down-rates to computational. A pad held by the server (persisted server-side) MUST NOT claim a regime above computational under any declared co-presence class, because such a pad cannot deliver unconditional secrecy against the server or a subsequent compulsion of it. Only a client-keyed session, whose pad never leaves the endpoint, may claim a raised regime.

Negotiated Cover Ratio The ratio of cover packets to real packets is operator-negotiable, carried in the session hardening policy, with a default of three cover packets per real packet. A negotiated ratio applies for the session lifetime.

Beacon Quorum and Trust-Root Pluralisation Where a session binds to public randomness (for rendezvous or epoch binding), it MAY draw that randomness from a quorum of independent public beacons rather than a single beacon. The epoch value is derived by HKDF over all contributions under a robust combiner with three properties:

1. UNPREDICTABLE-IF-ANY-ONE-HONEST: an adversary controlling all but one contributor can neither bias nor predict the output while one honest contributor remains.
2. QUORUM-GATED: a minimum number of distinct beacons MUST be present, so a withheld beacon below quorum is detected rather than silently trusted.
3. VERIFIER-TRANSPARENT: each combine emits a transcript hash binding the exact contributions, so any relying party recomputes and checks the epoch value without trusting the operator.

An OPTIONAL private commit-reveal mix folds endpoint entropy into the epoch value so that it is additionally unpredictable to a public observer, with a last-actor grinding attempt detected as a commit-reveal mismatch. Combined with the sequential-hash time-lock of - which provides delay without trusting any clock - the trust-root surface carries no single load-bearing root: not the beacon (plural under a combiner), not the clock (delay function), and not the verifier (public transcript).

Positive-Attestation Binding This section is informative. The quorum-beacon value of MAY additionally serve as the moving-target binding for a co-deployed positive- attestation engine, so that a single trust-root-plural randomness spine serves both this transport and the attestation layer. The attestation layer is out of scope for the normative behaviour of this protocol.

Operator Authentication and Assurance Binding Chorale binds each message or session to a live operator authenticator (the hardware-presence binding of the co-presence and endpoint model). This section specifies how a deployment REQUIRES and BINDS the ASSURANCE LEVEL of that authentication - authenticator assurance, biometric liveness, and identity proofing - WITHOUT the protocol performing biometric matching. All biometric processing remains within the operator's certified authenticator or presentation-attack-detection subsystem; the protocol binds only the resulting signed ATTESTATIONS, never a biometric template. This aligns a deployment with the authenticator- and identity-assurance levels of the applicable scheme (for United States federal use, NIST SP 800-63) and, where biometrics are used, with the presentation-attack-detection requirements of ISO/IEC 30107.

Assurance Factors An operator MAY present one or more factor attestations with a send. Each attestation is an opaque, verifier-checkable evidence object bound to a fresh challenge:

• possession: the authenticator produced an assertion (a token was held).
• user_verification: the authenticator performed a biometric or PIN check (the WebAuthn user-verification result), mapping to an authenticator-assurance level.
• liveness: a certified subsystem attests presentation-attack detection at a stated level.
• identity_proofing: a reference to an identity-proofing result at a stated level.

An attestation MUST carry the fresh challenge it answers. The relying endpoint MUST issue a single-use challenge and MUST reject any attestation whose challenge does not match the issued value, so a recorded assertion cannot be replayed within or across sessions.

Assurance Floor A session policy MAY declare an assurance floor: a minimum number of DISTINCT independent factors (a quorum), OPTIONAL pinned factors, and OPTIONAL minimum authenticator-, liveness-, and identity-assurance levels. The send path MUST refuse to transmit when the floor is not met, in the same fail-closed manner as the confidentiality-regime floor (), and MUST refuse when the policy is malformed or when a policy is present but no attestation is supplied. Consistent with the protocol's principle that no single element is individually load-bearing, the floor is by default a THRESHOLD over independent factors: a policy that requires a quorum without pinning any specific factor is met by any sufficient subset, so the loss of a single factor does not by itself deny an otherwise-authorised session. A deployment MAY pin a specific factor where its regime demands it; that is an explicit operator choice and does not change the threshold semantics for the remaining factors.

Binding and Privacy Admitted factor attestations are folded into the local key derivation in a DETERMINISTIC order, so the binding is independent of the order in which factors are presented and remains sound if any one folded attestation is unpredictable to the adversary - the same robust-combiner property as the beacon quorum of . Only a hash COMMITMENT over the folded attestations is written to any sealed record; the attestation bytes and any personally identifying material are never persisted. A session with no assurance policy is unaffected by this section.

Deployment Architecture and Integration Context This section is informative. It describes the environment in which a Chorale endpoint is deployed and the interfaces between the Chorale transport and the surrounding components of the reference platform. None of it is required for two conforming Chorale endpoints to interoperate; it is provided so that an implementer and a security reviewer understand the trust boundaries the protocol assumes and the mitigations available for the residual risks in the Security Considerations.

Endpoint and Hardware Model Chorale is designed to run on commodity hardware. It requires no hardware security module, trusted platform module, or trusted execution environment to operate; the reference implementation runs in an ordinary browser and in a server runtime. Specialised hardware, where present, strengthens key custody but is never a precondition for the protocol's security properties. Three endpoint mechanisms bound the risk that the endpoint - the honest primary attack surface once the wire is defeated - presents.

• Randomness. Key, pad, share, and nonce generation draws from a multi-source generator whose output is the exclusive-or of the system generator and an independently seeded HMAC-DRBG, admitted only after a NIST SP 800-90B entropy health test. The exclusive-or of independent sources is sound if any one source is sound, so a single biased or backdoored generator can neither control nor predict the output.
• Pad at rest. The one-time-pad reservoir is never at rest in exportable plaintext. Pad bytes are wrapped under a non-exportable, hardware-backed key, and pad regions are handed to a consumer under a draw-and-destroy discipline that zeroes the source immediately after use, minimising residency and removing the cloud-profile-sync exposure a non-live adversary would otherwise harvest.
• Key custody. The pad MAY additionally be bound to a hardware token the operator already carries (for example a WebAuthn PRF or challenge-response token) and split under a threshold secret-sharing scheme across independent stores: endpoint storage, a hardware-held share, and a server-blinded share. Any sub-threshold subset is information-theoretically empty; a honey-wrap ensures a sub-threshold or wrong-token unwrap yields a plausible decoy rather than an error, denying an offline oracle.

These mechanisms protect key material at rest and past traffic after a later endpoint image; they do not defend a live endpoint compromised while composing a message. That residual is bounded, not removed, by the session key ratchet.

Data Sovereignty and Jurisdictional Diversity Chorale is sovereignty-preserving in three concrete senses. First, in the client-keyed regime () the pad never leaves the endpoint and the relay and server never observe plaintext, so no operator, host, or jurisdiction holds the material required to read traffic. Second, packet flight is distributed across substrates in distinct jurisdictions (), so no single jurisdiction observes the whole of a transmission and compelling any one substrate operator yields only cover-indistinguishable fragments. Third, the assignment of substrate and jurisdiction to a session is operator-controlled policy, so a deployment MAY enforce data-residency and routing constraints without changing the protocol. The server-blind relay commitment layer () lets each relay attest that it forwarded what it received without being able to read it.

Cryptographic-Sovereignty Boundary and Breach Containment A Chorale endpoint MAY be deployed behind a cryptographic-sovereignty boundary that binds keys to the boundary and permits a relying party to verify sealed records with only the artefact and a published key, without trusting the platform that produced them; the platform holds only a public fingerprint of a secret, never the secret itself. The boundary carries a breach-containment sentinel: on a seal-verification failure, a detected retrospective drift, or an access denial, the sentinel commits a structured breach event - anchored to an external ledger - quarantines the affected session, and locks the affected principal. Each step of the containment path is best-effort and independent, so a breach response completes even if an individual subsystem is unavailable, and an incomplete on-chain anchor is retried on the next surveillance cycle. From the protocol's perspective this is a fail-closed response to boundary compromise: a boundary that can no longer prove its own integrity is rendered inert rather than trusted.

Threshold Key Custody and Time-Lock The verifiable-delay sealing of is one half of a custody model in which single-use key material is additionally held under threshold secret-sharing and released only after an unavoidable delay. Material under time-lock cannot be reached or re-encrypted before its release, which removes the leverage a ransomware adversary would otherwise obtain over an endpoint's key store, and the threshold split ensures no single store holds a usable key.

Display and Anti-Capture of Delivered Plaintext After Chorale delivers plaintext to an endpoint, the last exposure is the display itself - a screen capture or a camera photograph of the rendered content. A Chorale deployment MAY render delivered content through an optical-capture- resistant, ephemeral display that reconstructs the content only transiently across temporal shares, so a single captured frame does not yield it, and MAY seed the surface with watermarked decoy assets whose leak is self-incriminating. This closes the delivery path against an observer who has defeated neither the cryptography nor the endpoint but simply photographs the screen.

Composition and Assembly Chorale is one component of a composed platform assembled over a shared sealed-attestation substrate. A composition layer maintains a registry of the platform's functional components, a unified verdict envelope, and a cross- component routing map, so that Chorale transport can be invoked by any platform surface requiring interception-resistant delivery without that surface re-implementing the protocol. This is deployment context and imposes no requirement on the wire protocol.

Reality Attestation The beacon-quorum value of is shared with a reality-attestation layer that binds an artefact's claimed time and place to a quorum of independent public physical registers - for example mains-frequency continuity, provenance markers, and public randomness beacons - under a not-before randomness commitment, sealing the result as an independently replayable record. Divergence among the quorum of sealed sensors is treated as an adversary-adaptation signal. This layer is the positive-attestation counterpart to Chorale's confidentiality: Chorale establishes that a message could not be read; the reality-attestation layer establishes that an artefact's asserted origin could not have been fabricated below a stated cost. The two share one trust-root-plural randomness spine and are otherwise independent.

Security Considerations The Chorale Protocol is designed to defend against the following adversary capabilities:

1. Wire-level interception of all packets across all substrates simultaneously. Resisted at the strength of the regime in force under . Under the information-theoretic regime the adversary obtains ciphertext carrying no information about the plaintext. Under everlasting or computational the payload rests on the stated assumption and the guarantee is bounded by it.
2. Wire-level packet injection or modification. Defeated by cascade Neighbour-Witness integrity over the hidden Topology Graph; any modification cascades to invalidate K+1 witnesses.
3. Traffic analysis including timing correlation and packet-count correlation. Defeated by Cover Packets indistinguishable from Atomic Packets at the integrity-witness level, combined with prime-modular timing dispatch.
4. Retrospective decryption by adversaries with future quantum capability. Defeated under the information-theoretic regime, which is unconditionally secure against an unbounded adversary. Under everlasting the payload is secure against an adversary bounded in storage at the declared bound. Under computational harvest-now-decrypt-later is mitigated by the post-quantum handshake and is not eliminated.
5. Single-substrate compromise including cable taps, satellite spot-beam interception, and substrate denial-of-service. Defeated by multi-substrate flight requiring K-of-M shares across diverse path types.
6. Single-entropy-source compromise including supply-chain compromise of an entropy generator or sovereign-government coercion of an entropy source operator. Defeated by triple- sovereign-XOR pad composition.
7. Pad reuse including operator error and deliberate reuse. Defeated by the Tombstone Ledger, which structurally rejects reuse at the receiver.
8. Endpoint coercion of a sender operator. Mitigated by the duress codeword mechanism, which silently flags receiver-side audit to a duress condition.

The protocol does NOT defend against the following residual attack surfaces, which are addressed by operational and hardware measures outside the scope of this specification:

• Endpoint compromise of either the sender or the receiver (mitigated by hardware tamper-evidence, TEMPEST-certified operating environments, and Shamir-style split custody of the Session Anchor);
• Side-channel attacks on the Verifiable Delay Function evaluator hardware (mitigated by constant-time implementations and hardware-pinned VDF chips);
• Rubber-hose attacks producing the Session Anchor (mitigated by split custody and non-extradition-jurisdiction custodian distribution).

Implementers MUST consider these residual attack surfaces and implement appropriate operational and hardware measures.

Hash Family Negotiation Under Active MITM An active man-in-the-middle who intercepts the rendezvous payload can attempt a hash-family downgrade by rewriting one peer's advertised list before forwarding it to the other (and symmetrically on the return). For example, Alice advertises [sha3-512, sha-512] and Bob advertises [sha3-512, sha-512, sha-256]. An MITM strips sha3-512 and sha-512 from Alice's view of Bob's advertisement (or vice versa), forcing the intersection-and-strongest algorithm to land on sha-256 so the MITM can later mount cryptanalytic attacks at the weaker security margin. Chorale defends against this attack by binding the negotiated hash_family byte into the Short Authentication String preimage recited out-of-band at handshake completion, per . The SAS digest is computed as: An MITM who forces Alice to negotiate sha-256 while leaving Bob on the belief that they have negotiated sha-512 produces SAS digests under different families with different family-byte preimages. When Alice reads her SAS aloud and Bob compares it against his own, the words diverge and the divergence is detected before any session traffic is transmitted. The session is then aborted at the operator layer. This defence is structural: it does not require the operators to understand cryptography. They follow the existing SAS recital discipline (read aloud, compare, abort on mismatch); the hash_family byte in the preimage is what makes that discipline suffice against the downgrade attack. The defence depends on the out-of-band channel used for SAS recital being secret from the MITM. A telephone call, a video-call audio channel, or a physically-co-located reading all suffice. Any channel the MITM can also rewrite (e.g., an in-band text message without operator visual identity verification) does NOT suffice and MUST NOT be used for SAS recital.

Hash Family Selection This subsection records the rationale for the hash-family choices of . sha-512 is the RECOMMENDED default for new deployments. Relative to the v-01 baseline of sha-256, the wider internal state of SHA-512 provides a larger collision-resistance band against any future cryptanalytic advance in the SHA-2 family's compression function and against quantum-adversary Grover-search applied to preimage finding. The 256-bit effective post-quantum-Grover preimage strength of SHA-512 matches the security band of an unexpanded pad and of post-quantum signature schemes parameterised at the 256-bit security level. sha3-512 SHOULD be preferred where deployment posture demands diversity at the cryptographic-construction level. SHA-512 and SHA-256 share the Merkle-Damgard construction lineage; any cryptanalytic discovery affecting the SHA-2 compression function collapses both. SHA3-512, built on the Keccak sponge construction, is structurally independent and would not be co-affected by such a discovery. The same logic that motivates the multi-source entropy generator at the pad layer motivates SHA3-512 as a hedge at the hash-family layer. sha-256 is RETAINED only as a backward-compatible legacy mode for resource-constrained devices that cannot accommodate the larger block size of SHA-512. New deployments SHOULD NOT advertise sha-256 only. Mixed-corridor deployments where one endpoint is constrained MAY accept sha-256 negotiation for that corridor.

Allied Artefact Crypto-Profile Binding Rides Opaque Through Chorale The Chorale Protocol transmits Allied verification-artefact crypto- profile algorithm tags as opaque bytes within the encrypted payload. The protocol does not interpret, validate, or constrain the per- artefact hash family carried inside the payload. An Allied corridor operating under the Chorale Protocol may carry artefacts tagged under any algorithm in the Allied crypto-profile registry, and the Chorale transport layer makes no inference on those tags. This separation is deliberate. The Chorale hash-family negotiation of governs the transport-layer primitives that defend the wire: HKDF derivation, VDF sealing, commitment-layer digests, and per-packet HMAC tags. The Allied artefact crypto- profile, defined and managed in the Allied verification platform specification, governs the per-artefact content-hash algorithm used for ingestion, evidence-chain commitment, and envelope sealing. These two surfaces are intentionally orthogonal. A constrained- device corridor negotiating sha-256 for Chorale MAY carry an Allied artefact whose internal crypto-profile is sha3-512. A sovereign-corridor session negotiating sha3-512 for Chorale MAY carry artefacts tagged sha-256 from a partner-tenant origin. Implementations MUST NOT cross-validate the Chorale negotiated hash family against the Allied artefact crypto-profile. The two surfaces are governed by distinct registries and have distinct audit trails.

Constant-Time Comparison and Non-Persistence All secret-dependent comparisons - neighbour-witness verification, dispatch HMAC verification, commitment and Merkle comparison, and duress-codeword comparison - are performed in constant time, so no secret is leaked through comparison timing. The relay and receiver persist neither plaintext, nor a plaintext-derived commitment, nor any distinguishable duress marker. The stored record of a send made under a duress codeword is indistinguishable from that of a normal send; the duress signal is surfaced only out-of-band to the recipient endpoint. This preserves the deniability on which coercion resistance depends.

Empirical Indistinguishability of the Constant-Rate Stream The real-versus-decoy indistinguishability of the constant-rate stream () is measured rather than asserted. Over a large sample of real and chaff cells drawn from the reference implementation, a panel of statistical distinguishers and a trained classifier separate real from chaff cells with an area-under-curve within statistical noise of the 0.5 coin-flip baseline, while the same distinguishers separate a deliberately unprotected control format at 1.0, establishing that the null result reflects genuine indistinguishability and not an insensitive test. Pooled keystream entropy is within measurement error of the 8.0 bits-per-byte uniform ideal. The method and figures are recorded in the implementation's assurance harnesses.

Endpoint Compromise and Hardware Assumptions Chorale assumes no specialised hardware for its security properties; see . The endpoint is the primary residual attack surface once the wire is defeated. The at-rest pad protection, multi-source randomness, and threshold hardware-bound custody of reduce the value of an endpoint image and deny an offline oracle, but a live endpoint compromised during composition is a stated ceiling of the protocol, bounded by the session key ratchet and, at the display, by the anti-capture rendering of . Breach of a cryptographic- sovereignty boundary, where deployed, triggers the fail-closed containment of .

IANA Considerations This document requests the establishment of a "Chorale Hash Family" registry, with the following initial registrations:

Identifier	Underlying primitive	Status	Reference
sha-256	SHA-256	Legacy	This memo
sha-512	SHA-512	Recommended (default)	This memo
sha3-512	SHA3-512	Optional	This memo

The registration policy for new entries is "Specification Required" per BCP 26. New entries MUST identify the underlying hash primitive, the digest length, and the status (Legacy, Recommended, Optional). New entries MUST be assessed against the digest-length and effective preimage-strength requirements stated in and . A future version of this document may additionally register:

• A media type "application/chorale-packet" for Atomic Packets and Cover Packets;
• A URI scheme "chorale:" for Session Anchor references;
• A registry of named cryptographic profiles for the algorithm selection described in .

Related Standards The Chorale Protocol is part of a family of standards drafted by the same author for verification-anchored infrastructure:

• defines an attestation resolution profile for the SCITT framework.
• defines a verified profile for the Australian Essential Eight cyber baseline.
• defines an AI Governance Verification Scaffold.

The Chorale Protocol references for trusted-timestamp anchoring of envelopes, for HKDF, , , , , , for cryptographic primitive selection, and for post-quantum hybrid terminology where applicable.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. 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. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology Informative References

Acknowledgments The author thanks the broader cryptographic-research community for the foundational work cited herein, including Shannon's 1949 proof of OTP security, Shamir's 1979 secret sharing construction, Chaum's 1981 mixnet, the Rivest-Shamir-Wagner 1996 time-lock puzzle, the Boneh-Bonneau-Bunz-Fisch 2018 VDF construction, the Loopix mixnet, the Bennett-Brassard 1984 quantum key distribution protocol, and the NIST Post-Quantum Cryptography project. The author also acknowledges the operational lessons of the Soviet VENONA programme (pad reuse as failure mode), the Crypto AG / Operation Rubicon programme (hardware supply chain as compromise vector), and the public disclosures of the NSA TAO catalogue (endpoint implant as residual attack surface), which together motivated the operational hardening described herein.