What You Are Building

You want two parties to exchange encrypted messages, but you cannot lean on the usual machinery. There is no certificate authority you trust, no registry to look up a recipient's public key, and no reliable moment to run a Diffie-Hellman handshake because the recipient may be offline, ephemeral, or memory-constrained when you send. This is the situation for serverless functions with no durable storage, delay-tolerant and mesh links, IoT endpoints, and distributed agents that spin up and vanish.

The goal is confidentiality plus sender authentication where the sender derives a symmetric key from the recipient's current identity state and sends a self-contained message. The recipient reproduces the same key from its own local identity state and decrypts. No key travels on the wire, no keypair is persisted, and no external authority is consulted on the common path.

This guide describes the architecture disclosed in United States Patent Application 19/388,580. It is a design you implement yourself, not a package you install.

Why the Obvious Approaches Fall Short

The standard approaches are sound where their assumptions hold; the problem is the assumptions.

PKI with certificates. Public key infrastructure binds a persistent public key to an identity through a certificate authority. It works well for the web, but it requires a long-lived private key on each party, a trust anchor both sides accept, and a working revocation story. In decentralized or memory-constrained settings there may be no acceptable central anchor, no durable place to keep a private key, and no live path to a revocation service when you need it. The patent's background section names these same structural constraints: persistent key material, centralized trust anchors, and revocation dependence.

Interactive key exchange. An ephemeral Diffie-Hellman handshake avoids long-lived encryption keys, but it is interactive: both parties must be online at the same time to complete the exchange before the first protected message. That round trip is exactly what you do not have with a store-and-forward relay, a spaceborne link, or a recipient that is not currently running.

Pre-shared symmetric keys. A shared secret removes the handshake but reintroduces a static credential to provision, store, and rotate across every pair of parties. That does not scale to large, fluid populations of short-lived agents, and a single leaked key compromises every message under it.

The structural gap is the same across all three: each treats identity as a static credential that must be held, exchanged, or certified. The architecture below treats identity as a moving, locally reconstructable value, which removes both the persistent secret and the handshake from the common path.

The Architecture

The core idea is that a party's identity is not a fixed key but a trust slope: a cumulatively validated sequence of ephemeral hashes, each one a verifiable successor of the last. The spec calls these a Dynamic Agent Hash (DAH) for an agent and a Dynamic Device Hash (DDH) for a device. A symmetric key is derived transiently from the recipient's current dynamic identity, so it exists only for as long as that identity step does and never needs to be sent.

1. Identity as a successor chain. Each identity step is computed from the immediately prior step plus a fresh source of local unpredictability. The spec's update rule is DAHₜ = H(DAHₜ₋₁ ∥ Ext(Xₜ) ∥ saltₜ ∥ tag), where Xₜ is derived from a locally observed state vector, Ext(·) is a strong randomness extractor, saltₜ is a non-repeating volatile salt, and tag is a domain separator. A hardware-anchor variant substitutes KDF(HWID, saltₜ) for the extractor term, and a hybrid concatenates both. Because each step binds to non-exported unpredictability (the local state vector, or a hardware anchor combined with the salt), an attacker who lacks the device's local state cannot feasibly synthesize valid successors. This is the mechanism that lets identity move without a keypair.

2. Deriving the message key from the recipient's identity. Per Section 3 of the spec (FIG. 4), the sender applies a key-derivation function to the recipient's current DDH or DAH together with a domain-separating context string, and uses the resulting symmetric key for authenticated encryption of the payload. The recipient, holding its own current identity, runs the corresponding derivation and reproduces the same key to decrypt. The spec is explicit that the message does not include the symmetric key. That is the property you are after: the key is a function of an identity state both sides can independently compute.

3. Two-stage binding at transport and payload layers. The sender places its current dynamic hash (DAH_t) in the transport header for fast, stateless screening, and also embeds a copy of its current sender hash (DAH_S) inside the encrypted payload. The recipient does two checks: first a fast continuity check that the header hash is a valid on-slope successor of the last trusted state (this rejects malformed traffic before decryption); then, after decrypting, it validates the embedded sender hash against the reconstructed sender slope. The spec states the message is accepted only on successful validation of both. Binding identity at both layers is what prevents a man-in-the-middle from swapping the payload after transport-level screening.

4. Replay and spoof resistance from monotonic progression. Acceptance is bound to forward movement along the slope. A presented hash that equals a previously accepted value for the same sender and context, or that regresses behind the last trusted state, is rejected as replay or regression (spec Section 4). Off-slope claims are treated as probable spoofs. There is no nonce database to consult and no authority to ask; the check is local against retained slope state.

5. A bounded fallback for identity drift, not a standing handshake. When the sender lacks the recipient's current identity, it encrypts under the most recent trusted recipient anchor and sends. On decryption failure, the spec provides a bounded fallback: either a short challenge-response rekey scoped to the recipient's current epoch, or a checkpoint request that returns a bounded proof window sufficient to advance to the recipient's current identity. Retries are capped by policy to a fixed attempt window to avoid oracle leakage. Crucially, this is an off-path recovery step, not a handshake required before every message.

6. Why this is post-quantum aligned. The spec grounds security in the unpredictability of per-step inputs and the preimage resistance of the hashes and extractors, rather than on the number-theoretic hardness that Shor's algorithm targets. It states that with λ bits of min-entropy per step, an offline next-step forgery succeeds with probability approximately 2^(-λ), degrading only quadratically to about 2^(-λ/2) under Grover-style search, and suggests 256 to 512-bit extractor and digest sizes as conservative margins. This is a claimed structural property of the design, not a benchmark.

How to Approach the Build

The following is an ordered path a developer would take to implement the architecture. The interface sketches are illustrative and faithful to the spec; they are not a library.

Step 1: Choose your unpredictability source. Decide per device class. Constrained devices that expose a hardware identifier (TPM, TEE, SoC ID) use the hardware-anchor path: KDF(HWID, saltₜ). Richer platforms build a local state vector from device-observable signals (monotonic counters, high-resolution timing deltas, scheduler jitter, I/O inter-arrival micro-jitter) and run it through a strong extractor. You can hybridize by hashing both into the same step. The salt must be non-repeating per device and epoch.

Step 2: Make the local state vector stable enough to be reproducible. This is the subtle part. The recipient must reproduce the same identity value the sender keyed against, so small measurement fluctuations must not change the token while genuine role or context changes must. The spec's approach: normalize and clip signals to bounded ranges, project to a fixed dimension via signed random projections with a public seed, and apply a locality-sensitive binarization so that minor fluctuations yield stable Xₜ but real changes flip a controlled subset of bits. Budget real engineering time here; get this wrong and you get spurious decryption failures.

Step 3: Implement the update rule and a slope store. Wrap the successor computation:

# illustrative, faithful to spec Section 2, not a drop-in library
def next_identity(prev, x_t, salt, tag):
    token = extractor(project(x_t))        # Ext(Xₜ)
    return H(prev + token + salt + tag)     # DAHₜ

Each party keeps an append-only record of validated steps and records a mutation class per step (role update, delegation, policy commit) for provenance. Receivers store the last trusted successor per sender.

Step 4: Implement send. Derive the message key from the recipient's current identity, encrypt with an authenticated cipher, and embed your own current hash in the ciphertext:

# illustrative
key = KDF(recipient_current_DAH, context_string)
payload = AEAD_encrypt(key, plaintext + embed(sender_current_DAH))
message = Header(sender_current_DAH) + payload   # key is NOT in message

Step 5: Implement receive as two stages. First screen the header hash for on-slope continuity against your last trusted state for that sender; reject or defer before touching the ciphertext. Then derive the decryption key from your own current identity, decrypt, extract the embedded sender hash, and validate it against the sender's reconstructed slope. Accept only if both stages pass. Record rejections with an explicit reason (continuity violation, neighborhood mismatch, salt staleness, replay).

Step 6: Add the bounded fallback and sparse recovery. Implement the capped rekey handshake and the checkpoint request so a sender working from a stale recipient anchor can advance to the current identity. For memory-constrained or intermittently connected nodes, add the delayed-validation path: senders ship bounded per-step proofs (extractor tokens and/or keyed derivations with per-step salts) so a receiver can replay intervening steps from its last periodic anchor without live synchronization. Keep failure responses opaque so they do not leak rekey status.

Step 7: Add rotation and replay policy. Enforce non-reuse within a policy horizon, a minimum inter-step interval, and (per the spec) a two-epoch acceptance window with per-sender rate limits keyed to header continuity. Rotate entropy anchors on staleness, recording a forward link so verifiers can bridge old and new epochs.

What This Does Not Give You

This is an architecture disclosed in a patent filing, not a drop-in library, an SDK, or a downloadable package. There is nothing to npm install. You implement every component described above yourself, and the security you get depends on how well you do it, especially the local-state-vector stability and the min-entropy λ of your per-step contribution.

It has not been benchmarked or productized here, and no performance numbers are claimed beyond the forgery-probability relationships the spec derives from min-entropy. Treat those as the design's stated security argument, not measured results from a running system.

It is not a general replacement for PKI. If your counterparty is a browser talking to a public web server, PKI is the right tool and this is not. The architecture targets decentralized, stateless, memory-constrained, and disconnected environments where a persistent keypair or a synchronous handshake is impractical. For legacy interoperability the spec keeps a strictly segregated fallback adapter that uses conventional PKI signatures, walled off from the trust slope; that is a bridge, not the core design.

Finally, correctness hinges on both parties independently reconstructing the same identity state. If the recipient's identity has drifted and no fallback or checkpoint can bridge it, a message will not decrypt. Sizing the acceptance windows, salt cadence, and checkpoint frequency for your environment is design work you own.

Disclosure Scope

The approach described in this guide is disclosed in United States Patent Application 19/388,580. This guide is educational: it explains the architecture and how a developer might approach building it. It is not a warranty, a specification of a shipping product, or an offer of software, and it does not grant any license. Every mechanism described above traces to that filing; where the filing does not state a parameter, guarantee, or measurement, this guide does not claim one. Readers implementing the architecture are responsible for their own security review and for any patent, export, and compliance considerations that apply to their use.