background gif

Attacks · Replay, relay & forgery

Stale envelope

Envelopes carry a freshness window. Captured proofs replayed after the window closes fail before business logic — freshness is a gate check, not a courtesy.

~5 min readContinue: Forgery

Opening

What the attacker wants

The stale-envelope attacker holds a once-valid proof past its freshness window and presents it as if still live. The conversion is wait-and-reuse: steal inside the window, submit after clocks or caches make the ticket look merely “old but fine.” Stale attacks thrive where freshness is a metric instead of a reject.

How it works today

Long-lived session tokens make stale a soft problem. Attackers wait inside the token lifetime; grace periods and sticky sessions keep business running. Ambient estates often treat freshness as optional telemetry rather than an early reject. Short windows shrink steal-and-wait without replacing burn — both are required.

Why it fails against one-shot proofs

Gate freshness checks require the envelope timestamp to fall inside the configured window for the route. Out-of-window submissions are rejected at the gate surface before business logic. Freshness works together with burn: even inside the window, a spent nonce cannot return. Regulated buyers can name freshness as an ops control in reviews without needing an NDA stage matrix.

Read the dual plates as ambient success versus mechanism denial for stale envelope: the surface plate shows why classical estates pay; the denial plate shows which ENI6MA check family stops the conversion without dumping an NDA attack-to-stage matrix. Claims below stay model-scoped.

Old ticket still works

How to read: stale tray left; grace-period ambient win. Takeaway: freshness is often soft.

Ambient stale success is the late ticket that still runs the app.

Out-of-window dies early

How to read: expired-tau myths fail; freshness check rejects early. Takeaway: stale envelopes never reach the app.

Freshness fails closed early — the app never sees the out-of-window call.

Scoped claims

Authority expires at the end of each request.ShippingThe envelope binds method, endpoint_id, request hash, policy hash, tau, and nonce (one message, one use).Holds under the reference architecture

Where Gate stops it

Public gate order only — which check family denies this conversion. Not an NDA attack-to-stage matrix.

  1. Recompute the request hash

    The gate hashes the body it actually received and compares it to the envelope.

    Rejects: A body that was altered after the proof was made.

  2. Check endpoint and policy

    The envelope names the endpoint and the policy it was made for; both must match this route.

    Rejects: A valid proof relayed to a different endpoint.

  3. Confirm the circuit is active

    The handle is resolved against the registry and must be active. Deactivating a handle is how revocation happens.

    Rejects: A proof from a revoked identity.

  4. Check freshness

    The envelope timestamp must fall inside the freshness window configured for the route.

    Rejects: A captured envelope replayed after the window closed.

  5. Burn the nonce

    The nonce is spent here, before the proof is validated. Every submission spends it, including one that is about to fail validation.

    Rejects: Any second use of the same envelope. This is where replay dies.

  6. Validate the proof

    Only now is the proof itself checked, against the local binary or the registry. Both modes are equivalent at the envelope layer.

    Rejects: A forged or malformed proof.

  7. Apply application policy

    Ordinary authorization runs in the post-proof zone: arguments, limits, and business rules.

    Rejects: A well-proved request asking for something it is not allowed to ask for.

  8. Serve the request

    The application does its work, and the response is bound back to the request that earned it.

Where it shows up

Watch it fail

Go deeper

  • ENI6MA ALGO1 Proof Variants: Formal Model and Proofs

    This text formalizes the principal ENI6MA proof mechanism, focusing on the ALGO1 family and its challenge/response variants. ALGO1 is modeled not as a SNARK/STARK circuit proof system but as a multi-round identification protocol based on position-wise bucket membership: the verifier accepts when the prover selects, each round, a zone whose witness contains the corresponding secret character.

  • SYSTEM

    This deep dive describes E6-Agent: a security-first communications substrate built around symmetric clone agents, identical binaries configured with peer identities that communicate over encrypted, proof-gated channels. Agents are designed to be operationally Stateless: single-shot messages or continuous oscillation handshakes without retaining sensitive state across invocations.

  • Holographic Entanglement for Keyless Proof

    This paper proposes an “informational entanglement” framing that unifies spatio-temporal entropy and attestation into a keyless authentication primitive. Two compiled twins sharing a sealed private morphism transform fresh session entropy, timestamp, and contextual inputs into a one-time holographic witness (an ephemeral trajectory on a discrete orientation ring).

Formal note

Freshness is a public gate stage that rejects out-of-window envelopes before application handlers run.