background gif
eni6ma

Attacks · Replay, relay & forgery

Replay

Burn-before-validate spends the nonce before the proof is checked. A second submission of the same envelope fails at the ledger — even when crypto would still look fine.

~6 min readContinue: Relay

Opening

What the attacker wants

The replay attacker wants a second allow from work that already succeeded once. Capture a valid ceremony, envelope, or token; store it; submit it again against the same or a similar route. The prize is duplicated authority without re-earning the proof — a free second call, a delayed fraud, or a cloned agent action that looks cryptographically pretty while the ledger should already know the nonce is gone. In buyer language: the attacker is not trying to invent a new proof — they are trying to spend yesterday’s success again.

How it works today

Ambient estates make replay the default product behavior. Bearer tokens and session cookies are designed to work until expiry. Possession is authority for the whole window, so “capture once, submit twice” is not an exotic exploit — it is how the credential was meant to travel. Even “short-lived” tokens often leave enough room for steal-and-wait. Observers who film a successful call can often resubmit the same bytes and watch business logic run again. Incident response playbooks for ambient estates still center on rotation windows precisely because replay was product behavior.

Why it fails against one-shot proofs

ENI6MA orders the gate so burn happens before validate. Stage 5 writes the nonce into a durable ledger before stage 6 checks the proof. Every submission spends the nonce, including one that is about to fail validation. That ordering is why replay dies structurally rather than by hoping the attacker is slow or the crypto looks wrong on the second try. A second submission of the same envelope fails at the ledger even when the proof bytes would still verify in isolation. Pair this page with Verify’s replay-fail path: the falsifiable check is a second submission that must die at the ledger.

Capture once · submit twice

How to read: record-and-resubmit left; first and second allow ambient win. Takeaway: possession window is replay window.

Ambient success is the double allow: first call works, second call works, until someone rotates the token.

Burn-before-validate stops replay

How to read: second-submit myths fail; ledger burn then reject. Takeaway: spent nonces do not authorize again.

After burn-before-validate, the second submission is a ledger fact — not a race the attacker can win by being fast.

Scoped claims

Burn-before-validate is the structural reason a second submission of the same envelope always fails.ShippingGate stage 5 spends the nonce in the durable ledger before stage 6 validates the proof.Holds under the reference architecture

Replay is impossible by design.ShippingThe nonce is burned before validation in a durable ledger; it is spent even when validation later fails.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

Formal note

Burn-before-validate is an ordering claim on the public gate: ledger spend precedes proof validation so replay cannot return as authority.