background gif
eni6ma

Attacks · Replay, relay & forgery

Request tamper

The gate hashes the body it actually received and compares it to the envelope. Alter the payload after the proof is made and the composite digest fails.

~6 min readContinue: Stale envelope

Opening

What the attacker wants

The tamper attacker wants to change what the server will do without re-earning authority. Capture a request that already carries a valid proof, edit arguments or JSON fields, and resend the mutated body with the original envelope. The conversion is silent mutation: keep the authorization object, swap the business payload, hope the gate never looks at the body the way the prover did. Tamper is how argument injection becomes a security incident without ever stealing a new secret.

How it works today

Ambient signed tokens that omit body binding invite exactly this path. Auth headers and cookies often authorize “the caller” while application code trusts the body separately. Argument injection after mint is a classic conversion: the crypto still looks fine, the ACL still says yes, and only the numbers in the JSON changed. Observers who can modify traffic mid-path treat auth and payload as detachable. API gateways that authenticate the caller but trust the body downstream recreate the ambient conversion path by architecture.

Why it fails against one-shot proofs

ENI6MA recomputes a composite request hash over method, endpoint, body, policy, tau, and nonce, then compares it to the envelope. A pencil edit to the body alone breaks the digest. The attacker must re-prove for the new payload — there is no free mutation of an already-bound envelope. Tamper fails because the authority object includes the request the gate actually received. The digest story is deliberately boring: if the body changed, the envelope is about a different request, full stop.

Read the dual plates as ambient success versus mechanism denial for request tamper: 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.

Edit body · keep authority

How to read: tamper tray left; auth stays while business changes. Takeaway: auth decoupled from payload.

Ambient tamper keeps the auth header and changes the business fields — conversion without a new proof.

Tamper breaks the digest

How to read: body-only edit myths fail; request_hash mismatch requires re-prove. Takeaway: altered payload is not the same envelope.

When the digest covers the body, a body-only edit is a mismatch, not a clever exploit.

Scoped claims

Every envelope is bound to a specific method, endpoint, request body, policy, freshness window, and nonce.Shippingsha256(method || endpoint_id || request_body_hash || policy_hash || tau || nonce_uuid)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.

  • ENI6MA Protocol: Rosario–Wang Formalism

    This work presents a unified formalism for the ENI6MA protocol grounded in the Rosario–Wang holographic manifold collapse and informational entanglement. It addresses the fragility of credentialed systems that store long-lived secrets, and positions the construction as an alternative to heavy algebraic zero-knowledge machinery for real-time human interaction.

  • ENI6MA Witness Complexity

    A combinatorial treatment of witness-space size and attacker success probability for interactive ENI6MA proofs. With alphabet size α per challenge state, witness length ν, and ρ chained independent transcripts, the total hypothesis space scales as α^(νρ) while random-guess success falls as α^(-νρ).

Formal note

Stage 1 request hashing binds the received body into the envelope comparison so post-mint mutation fails closed.