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. Session-bound residues and microsecond geometry in the observable-channel papers reinforce why yesterday’s success is not tomorrow’s credential.

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

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

  • Information-Theoretic Boundaries of the Rosario Primitive: Observable-Channel Isolation

    This paper formalizes information-theoretic boundaries of the Rosario Primitive with emphasis on the observable channel and adversarial inference limits. The central claim is that, in the ideal regime, the observable channel carries zero mutual information about the hidden state beyond a nonce-scoped event-validity residue; in the non-ideal regime, leakage remains small, measurable, and non-accumulative under proper constraints.

Formal note

Burn-before-validate is an ordering claim on the public gate: ledger spend precedes proof validation so a second submission of the same envelope fails even when proof bytes would still verify in isolation. Replay denial is conversion denial for captured authority — the residue is nonce-scoped history, not a reusable credential. Companion proof-variant and observable-channel papers situate the ordering inside session-bound residue and witness models.