Mechanism
Two-stage authentication is the method by which a recipient accepts a message under the memory-native identity substrate. The disclosure defines it precisely: first verifying header-level continuity of a presented Dynamic Agent Hash (DAH) before decryption, then validating an embedded sender DAH after decryption, with failure at either stage causing rejection. There is no static credential, no certificate, and no persistent keypair anywhere in the path. Identity is expressed as a trust slope, the cumulatively validated sequence of dynamic hashes produced by successive identity mutations, and each stage tests the presented value against that slope.
A sender generates a current dynamic agent hash, DAH_t, as a successor of its prior trusted hash, DAH_{t−1}, under an update rule that incorporates at least one unpredictability contribution and a volatile salt. The sender derives a symmetric encryption key from the recipient's current dynamic identity, selected from a recipient dynamic agent hash (DAH_R) or a recipient dynamic device hash (DDH_R), and encrypts the payload with that key. Inside the encrypted payload it embeds a sender dynamic agent hash, DAH_S, computed contemporaneously with DAH_t. The constructed message carries DAH_t in the transport header and DAH_S inside the ciphertext, and the message does not include the symmetric encryption key.
Identity is therefore bound at both the transport layer and the semantic layer. The header value permits fast, stateless screening at the receiver; the same identity is also bound inside the protected payload so that content is tied to transport. The two stages are evaluated in fixed order, and the message is accepted only upon successful validation of both DAH_t and DAH_S.
Stage One: Header Continuity Before Decryption
When a message arrives, the recipient reconstructs an expected successor candidate for time t from its locally retained trust-slope state for the sender, which includes at least the most recently validated and previously accepted DAH_{t−1}. The reconstruction advances that retained state under the same update rule and within a recipient-defined set of policy-bounded continuity parameters. The recipient then validates the presented DAH_t against the expected successor candidate. Because each step binds to the prior step and to non-exported unpredictability, an attacker lacking the sender's local state or volatile salt cannot feasibly synthesize a valid successor.
This first check is performed before any decryption is attempted, providing a lightweight continuity test that screens incoming header values against the sender's trust slope. If continuity cannot be confirmed immediately, the recipient may defer the decision until a bounded proof or checkpoint is obtained. The spec frames this as fast, stateless screening: malformed or off-slope traffic is rejected at the header before the payload parser is ever reached.
Stage Two: Embedded Hash Validation After Decryption
Once header continuity is validated, the recipient derives a symmetric encryption key from the corresponding one of DAH_R or DDH_R and decrypts the payload. Successful decryption demonstrates that the encrypted payload was generated for the correct memory-resolved identity state of the recipient at the time of transmission. The recipient then extracts the embedded sender hash, DAH_S, from the decrypted plaintext and validates it against a reconstructed trust slope for the sender, obtained by advancing the locally retained trust-slope state under the update rule and within the same policy-bounded continuity parameters.
This second-stage verification provides semantic authentication independent of the transport header, ensuring that both routing-layer and content-layer integrity requirements are satisfied before the message is accepted. The two stages answer different questions: stage one screens the header value as a valid successor on the slope, and stage two confirms that the identity bound inside the protected content is likewise on-slope. Validating the embedded value after decryption prevents man-in-the-middle substitution of the header, because an attacker who swaps the header cannot also produce a payload whose embedded DAH_S is a valid successor under the sender's non-exported state.
Rejection and Rekey Fallback
The acceptance rule is conjunctive: the message is accepted only upon successful validation of both DAH_t and DAH_S. If either the header-level continuity of DAH_t or the payload-level continuity of DAH_S fails, the recipient rejects the message without external registry lookup. On failure the recipient records a rejection, may degrade the sender's trust score according to local policy, and may quarantine the message or sender for review. The disclosure does not provide a reduced-privilege acceptance path: failure at either stage causes rejection.
A separate fallback addresses the case where the sender does not possess the recipient's most recent identity value. The sender derives the symmetric key from the most recently trusted recipient anchor or epoch and transmits an initial attempt under a bounded rekey-failure tolerance. If decryption fails, the sender performs a fallback consisting of either a short challenge-response rekey exchange scoped to the recipient's current epoch or a checkpoint request sufficient to reconstruct a successor window to the recipient's current identity. Retries are limited to a policy-bounded attempt window. Receivers may apply a two-epoch acceptance window for recipient identity, enforce per-sender rate limits on failed decryptions, and emit opaque failure codes to prevent oracle leakage.
Stateless Key Derivation
The construction permits fully stateless operation. Neither sender nor recipient maintains long-lived session keys; instead, all symmetric keys are derived transiently from identity values produced by the dynamic update rule. The symmetric key is derived via a key-derivation function keyed by the DAH_R or DDH_R and a domain-separated context tag, and no asymmetric key exchange is performed. The derived key may be scoped to expire with a recipient epoch to prevent cross-epoch decryption.
When recipient identity is produced through a local-state vector, stability-tuned projections and error-tolerant sketches prevent benign fluctuations in local measurements from causing unnecessary decryption failures, while substantive role or context changes intentionally alter recipient identity and force rekeying. When identity is produced from a hardware anchor and volatile salt, freshness is maintained by the non-repeating salt. Hybrid implementations combine both sources to improve robustness across heterogeneous device classes.
Unpredictability Sources for the Update Rule
The two-stage method is neutral to the source of per-step unpredictability used to advance the trust slope, and the same validation logic applies across embodiments. In a hardware-anchor embodiment, the unpredictability contribution is a keyed derivation from a static hardware anchor, such as a TPM, TEE, or SoC identifier, combined with a volatile per-epoch salt. In a local-state embodiment, the contribution is an extractor output over a stability-tuned local state vector, used without exposing the raw local state. In a hybrid embodiment, the hardware-anchor derivation and the local-state extractor output are concatenated in the same update rule, and failure of either contribution is sufficient to break continuity.
Across these embodiments the structural property is preserved: stage one validates the header DAH_t and stage two validates the embedded DAH_S against the same advanced trust-slope state, under the same policy-bounded continuity parameters. The continuity check in the local-state embodiment uses a stability-tuned acceptance neighborhood over extractor outputs; in the hardware-anchor embodiment it verifies per-epoch salt freshness and cadence. The header DAH presented in transport may additionally be rotated at a policy-defined cadence independent of payload semantics to reduce long-range linkability, with verifiers resolving the rotation through forward links.
Distinction From Prior Art
Conventional digital identity and authentication systems rely on persistent public-private keypairs and signature-based validation, exposing users and devices to key compromise, metadata correlation, certificate revocation failure, and susceptibility to quantum attacks. Public key infrastructure typically requires centralized trust anchors, global registries, and persistent key material. The accepting and validating in the disclosed method are performed without reliance on persistent private keys or external certificate authorities.
Mutual TLS and similar transport-layer schemes establish identity at session setup and then let subsequent traffic inherit that outcome. The two-stage method instead evaluates continuity on the presented message itself and binds the same identity into the encrypted payload, so a header substituted in transit cannot be reconciled with the embedded sender hash. Security depends on the min-entropy of per-step unpredictability and the preimage resistance of the hash or extractor rather than on algebraic assumptions vulnerable to Shor-type attacks, aligning the construction with post-quantum expectations.
Disclosure Scope
The disclosure under U.S. Application No. 19/388,580 covers memory-native two-stage authentication in which a recipient first validates header-level continuity of a presented dynamic agent hash (DAH_t) against an expected successor reconstructed from locally retained trust-slope state, then, after deriving a symmetric key from the recipient's own current identity and decrypting, validates an embedded sender dynamic agent hash (DAH_S) against the advanced trust slope, accepting the message only upon success at both stages and rejecting without external registry lookup upon failure at either. Coverage extends to the dynamic update rule with at least one unpredictability contribution and a volatile salt, the hardware-anchor, local-state, and hybrid unpredictability embodiments, the identity-derived symmetric key derivation without asymmetric key exchange, the provisional-key and checkpoint or challenge-response rekey fallback under a bounded attempt window, the two-epoch acceptance window with opaque failure codes, and header DAH rotation at a policy-defined cadence. Embodiments that depend on persistent keypairs, external certificate authorities, single-stage validation, or post-decryption-only validation fall outside the described construction.
