{"id":341,"date":"2026-09-05T04:18:06","date_gmt":"2026-09-05T04:18:06","guid":{"rendered":"https:\/\/neodata.com.uy\/labs\/the-statement-must-enter-the-hash\/"},"modified":"2026-09-05T04:20:35","modified_gmt":"2026-09-05T04:20:35","slug":"the-statement-must-enter-the-hash","status":"publish","type":"post","link":"https:\/\/neodata.com.uy\/labs\/the-statement-must-enter-the-hash\/","title":{"rendered":"The statement must enter the hash."},"content":{"rendered":"

<\/p>\n

ZERO-KNOWLEDGE PROOFS<\/p>\n

Why a valid proof can still authorize the wrong statement.<\/h2>\n

A zero-knowledge proof can be correct at the level of its algebra and wrong at the level of its application.<\/p>\n

The verifier may confirm that a prover knows a witness for a relation. If the relation omits a public value, accepts a non-canonical encoding or is bound to the wrong protocol context, the proof can establish something materially weaker than the application assumes.<\/p>\n

The difficult boundary is often not zero knowledge itself. It is the construction of the statement and the transcript that turns an interactive proof into a portable object.<\/p>\n

Commitment, challenge, response<\/h2>\n

A Sigma protocol commonly proceeds in three moves. The prover sends a commitment. The verifier returns a random challenge. The prover computes a response using the witness and the randomness used in the commitment.<\/p>\n

For suitable relations, this structure provides completeness, special soundness and honest-verifier zero knowledge. A verifier learns that the prover knows a witness without learning the witness itself.<\/p>\n

Interaction is inconvenient when a proof must be stored, forwarded or verified later. The Fiat-Shamir transformation replaces the verifier’s random challenge with the output of a cryptographic hash over the protocol transcript.<\/p>\n

The hash becomes the verifier<\/h2>\n

Once the challenge is derived from a hash, the bytes absorbed by that hash define what the proof is bound to. This makes transcript construction a security boundary.<\/p>\n

A correct transcript normally includes the full public instance, every prover message in order, a protocol identifier and the contextual information required to separate this use from other uses of the same proof system.<\/p>\n

If an input is absent, the verifier’s challenge is independent of it. A malicious prover may then choose that input after learning the challenge and satisfy verification for a statement it never knew a witness for.<\/p>\n

The instance is not the witness<\/h2>\n

The witness is secret information whose knowledge is being demonstrated. The instance is the public description of the relation: public keys, commitments, group parameters, roots, limits or other values against which the witness is checked.<\/p>\n

Applications often pay close attention to hiding the witness and much less attention to constructing the instance. That asymmetry is dangerous. The proof system can only enforce the relation it receives.<\/p>\n

If a circuit proves that an amount lies in a range but the asset identifier is not bound into the statement, the proof may be reusable for another asset. If a proof of key possession omits the intended audience, it may be accepted in another protocol. Soundness does not repair missing semantics.<\/p>\n

Domain separation prevents protocol confusion<\/h2>\n

The same hash function, curve and proof machinery may be used by several applications. Without domain separation, a transcript created for one context can collide structurally with a transcript interpreted by another.<\/p>\n

A protocol tag should identify the construction and version. A session identifier can bind the proof to a deployment, role or interaction. These values need unambiguous length and encoding rules.<\/p>\n

Freshness is a separate requirement. A stable domain tag prevents cross-protocol confusion but does not prevent replay. A nonce, counter or session-specific challenge can make one proof unusable in a later ceremony.<\/p>\n

Serialization is part of the proof system<\/h2>\n

The algebra operates on field elements and group points. Networks and storage operate on byte strings. The conversion between them must be canonical.<\/p>\n

A verifier should reject integers outside the permitted range, non-canonical field encodings, malformed points, wrong-subgroup elements, trailing bytes and inconsistent length prefixes. Accepting two encodings for one object can create transcript disagreement between components.<\/p>\n

This is the same general lesson explored in The transcript is the protocol<\/a>: cryptography authenticates an exact representation, so representation rules belong inside the security argument.<\/p>\n

Randomness reuse can reveal the witness<\/h2>\n

Zero knowledge depends on fresh prover randomness. In Schnorr-style proofs, reusing one commitment nonce across different challenges exposes enough linear information to recover the secret witness.<\/p>\n

Randomness failures can arise from snapshots, virtual-machine cloning, faulty deterministic derivation, concurrent access or restoration of an embedded device to an earlier state. The requirement is not merely a good random-number generator at manufacturing time. It is uniqueness and unpredictability across the complete lifecycle of the prover.<\/p>\n

The operational problem resembles nonce management in authenticated encryption<\/a>, but the failure result is different: reuse can disclose the witness itself.<\/p>\n

A sequential API can enforce the transcript<\/h2>\n

An implementation that represents a proof as a freely mutable structure makes it easy to omit or reorder fields. A sequential transcript API can absorb and serialize each prover message in the same operation.<\/p>\n

This creates a useful invariant: if a value appears in the encoded proof, it has entered the hash in the prescribed position. End-of-input checks ensure that appended material is not ignored.<\/p>\n

Typed transcript methods can distinguish scalars, points, byte strings and length-delimited lists while still producing one canonical byte stream. The API becomes part of the implementation’s proof discipline.<\/p>\n

The circuit can be underconstrained<\/h2>\n

General proof systems add another boundary. A circuit or constraint system may fail to enforce that an internal value is Boolean, belongs to a range, corresponds to the public input or follows the intended state transition.<\/p>\n

The prover then supplies a witness that satisfies the written constraints but violates the intended computation. From the proof system’s perspective, nothing has failed. The wrong relation was proven correctly.<\/p>\n

Constraint review should therefore resemble protocol review. Each informal claim needs a traceable constraint, each public input needs an explicit binding and each conversion between native and foreign fields needs range analysis.<\/p>\n

Test vectors prove only the honest path<\/h2>\n

A positive test vector shows that one honestly generated proof verifies. It exercises completeness. It says little about rejection behaviour.<\/p>\n

A useful negative suite changes one element at a time:<\/p>\n