The Chorale Protocol: Interception-Resistant Packet Transmission with Topology-as-Secret Ordering, Cascade-Integrity Witnessing, Polyglot Cover Packets, Per-Packet Time-Lock Sealing, and Multi-Jurisdiction Substrate Diversity

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 31 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Existing transport-layer cryptographic protocols including [RFC9846] provide confidentiality based on computational hardness assumptions that are not robust to large-scale fault-tolerant quantum computation. Post-quantum key encapsulation mechanisms (see [FIPS203]) 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 [Shannon1949] 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 Section 20. 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.¶

2. 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 Section 3. 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 [FIPS204] 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 Section 4. 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 Section 5.¶

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 Section 4 and Section 9). 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 Section 7.¶

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 Section 10. 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.¶

3. 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 [BB84] 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 [FIPS204] 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.¶

4. 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.¶

{
  "session_id": "...",
  "ecdh_public_jwk": { ... },
  "hash_family": ["sha3-512", "sha-512", "sha-256"]
}

SAS_preimage = hash_family || "|" || SAS_words

SAS_digest = H_negotiated( SAS_preimage )

5. Multi-Sovereign Entropy Generator

This section governs the generation of pad material for the everlasting and information-theoretic regimes of Section 20. 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.¶

6. 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 [RFC5869].¶

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 Section 20 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 Section 5 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 Section 4:¶

• 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.¶

7. 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 [Wesolowski2018] and [BBBF2018], 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.¶

8. 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 Section 4:¶

• 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.¶

9. Cryptographic Profile

Implementations MUST support SHA-256 [FIPS180-4], SHA-512 [FIPS180-4], and SHA3-512 [FIPS202] for Neighbour-Witness computation, with the choice of function within a session bound by the negotiated hash family of Section 4. Implementations SHOULD also support SHA3-256, BLAKE2b, and BLAKE3 for tenant- selected digest profiles outside the negotiated set.¶

Implementations MUST support Ed25519 [FIPS186-5] and ECDSA-P256 [FIPS186-5] for digital signatures. ECDSA-P256 signatures are canonically paired with SHA-256 per [FIPS186-5]; this pairing is NOT subject to the hash-family negotiation of Section 4. Implementations SHOULD also support ECDSA-P384 [FIPS186-5] for Commercial National Security Algorithm Suite 2.0 transitional compatibility.¶

Implementations MUST support CRYSTALS-Dilithium / ML-DSA [FIPS204] 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.¶

10. 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.¶

11. 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.¶

12. 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.¶

13. 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.¶

14. Polyglot Cover-Encoding Layer

Cover packets, as defined in Section 10, 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.¶

idx         = H(session_id || cover_batch_nonce || i) mod |ENCODINGS|
encoding[i] = ENCODINGS[idx]

15. 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_code":   "<operator-assigned slug>",
  "provider":     "cloudflare" | "fly" | "render" | "vercel" |
                  "aws" | "gcp" | "azure" | "self-hosted",
  "region":       "<provider-specific region identifier>",
  "jurisdiction": "<ISO 3166-1 alpha-2>",
  "substrates":   [ "fibre" | "satellite" | "microwave" |
                    "mesh" | "sneakernet" | "sovereign" ],
  "forward_url":  "https://<host>/forward",
  "shared_secret_hash": "<hex digest of HMAC key under the
                        session's negotiated hash family>"
}

16. 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.¶

17. Comparison with Related Work

[RFC9846] (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 Section 20 are met, which TLS does not define.¶

[Chaum1981] 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.¶

[Loopix2017] provides cover traffic at the timing level; Chorale extends cover indistinguishability to the integrity-witness structure level.¶

[Shamir1979] secret sharing and [ReschPlank2011] 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.¶

[RSW1996] time-lock puzzles and [Wesolowski2018] VDFs are used per-message in prior art; Chorale applies them per-packet to multiply adversary cost by N while preserving receiver parallelisability.¶

18. 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).¶

19. 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.¶

20. 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 Section 4.5. 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.¶

21. 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.¶

22. 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 Section 7 - 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).¶

23. Positive-Attestation Binding

This section is informative. The quorum-beacon value of Section 22 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.¶

24. 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.¶

25. 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.¶

26. 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 Section 20. 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.¶

SAS_digest = H_negotiated( hash_family || "|" || SAS_words )

27. IANA Considerations

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

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 Section 4 and Section 8.¶

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 Section 9.¶

28. Related Standards

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

• [SCITT-ARP] defines an attestation resolution profile for the SCITT framework.¶

• [E8VS] defines a verified profile for the Australian Essential Eight cyber baseline.¶

• [AIGVS] defines an AI Governance Verification Scaffold.¶

The Chorale Protocol references [RFC3161] for trusted-timestamp anchoring of envelopes, [RFC5869] for HKDF, [FIPS180-4], [FIPS198-1], [FIPS202], [FIPS186-5], [FIPS203], [FIPS204] for cryptographic primitive selection, and [RFC9794] for post-quantum hybrid terminology where applicable.¶

29. References

Appendix A. 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.¶

Author's Address