]> CNRS

m@orru.net

Apple, Inc.

cathieyun@gmail.com

IRTF Crypto Forum zero-knowledge sigma protocols cryptography proofs of knowledge This document describes Sigma Protocols for proving knowledge of preimages of linear maps in prime-order elliptic curve groups. These are sometimes also called Maurer Proofs, or proofs of knowledge of a preimage of a group homomorphism. Examples include zero-knowledge proofs for discrete logarithm relations, ElGamal encryptions, Pedersen commitments, and range proofs. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Crypto Forum Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Zero-knowledge proofs of knowledge allow a prover to convince a verifier that a statement is true, without revealing anything other than what is already revealed by the statement itself. Sigma Protocols are an essential component of a number of cryptographic constructions, such as anonymous credentials , verifiable random functions , anonymous tokens , blind signatures , and proofs of knowledge of the opening of a Pedersen commitment . This document specifies a single Sigma Protocol for proving knowledge of a preimage of a linear map over a prime-order group , , . A linear relation is a system of equations among group elements that is linear in the secret scalars; affine relations with constant terms (e.g. verifiable encryption) and quadratic equations (e.g. range proofs) can also be expressed as the preimage of a linear map (). A Sigma Protocol is an interactive proof with the following three-message flow:

Flow of an interactive sigma protocol. | | | | challenge | |<----------------------------------------------------| | | | ProverResponse(prover_state, challenge) | | response | |---------------------------------------------------->| | | | Verifier(instance, commitment, challenge, response) | | accept or reject | ]]>

The messages are respectively called commitment (computed by the prover), challenge (randomly sampled by the verifier), and response (computed by the prover). The prover is stateful and maintains a single-use private state between the first and third messages. The transcript (commitment, challenge, response) is checked by the verifier. Sigma Protocols can compose: several statements can be proven simultaneously (AND composition), disjunctively (OR composition ), or thresholded. AND composition of linear relations is immediate in this document (); OR and threshold composition, and composition across heterogeneous proof systems, are not part of this document, but possible via the Sigma Protocol interface. Composition carries soundness and zero-knowledge caveats; see and .

Terminology and conventions in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The algorithms and procedures in this document are specified using Python-like pseudocode. Each function accepts defined inputs and parameters and returns one or more output values. Once a protocol variant and ciphersuite are selected, all associated parameters are treated as constants. The following notation is used throughout this document.

Bytes and integers A byte is an 8-bit unsigned integer (an octet), and a byte string is a finite sequence of bytes. The empty byte string is written "", and x || y is the concatenation of the byte strings x and y. For any finite sequence x, len(x) is the number of elements in x; for a byte string, this is its length in bytes. Byte strings are indexed from zero: for integers 0 <= i <= j <= len(x), x[i : j] denotes the (j - i)-byte substring of x at positions i, i+1, ..., j-1, so that x[0 : N] is the first N bytes of x and x[i : i] is "". I2OSP(n, w) and OS2IP(x) are the integer/byte-string conversion primitives used throughout this document, in big-endian byte order, as defined in . I2OSP(n, w) converts a non-negative integer n with 0 <= n < 256^w into a w-byte, big-endian byte string, and fails if n >= 256^w; OS2IP(x) is its inverse, mapping a w-byte string to the integer in [0, 256^w) that it represents. LE(n, w) is the little-endian counterpart defined in . LE2IP(x), also defined in , converts a little-endian byte string back into a non-negative integer. Byte order and length of the scalar and group-element encodings are fixed by each ciphersuite ().

Randomized algorithms The prover commitment algorithm requires fresh, single-use randomness for zero-knowledge. This document denotes with rng a cryptographically secure random number generator (CSPRNG), and uses Group.random_scalar(rng) to denote sampling a uniformly random element of the scalar field, similarly to RandomScalar() of . Sampling a random scalar takes two steps: obtaining high-quality entropy via a CSPRNG (e.g., getrandom(); see for randomness requirements), and reducing the resulting bytes to a scalar. It is RECOMMENDED that the latter be done via DecodeField as in . Different sampling mechanisms, such as the wide reduction of hash_to_field () and the integer conversion of Appendix A.4.1 of do not affect interoperability of proofs.

Group abstraction Elliptic curves are presented using additive notation. Group elements are upper-case (G, X, M) and scalars lower-case (x, s). The name G denotes the group generator Group.generator() (). Pseudocode and interface names are descriptive (e.g. commitment, image, witness) and do not follow this rule.

Group elements identity() is the neutral element, generator() returns the canonical generator of the prime-order subgroup (), and order() returns its order p. Addition, negation, equality, and scalar multiplication by a Scalar are written +, -, ==, and *. serialize(elements: list[Group]) and deserialize(buffer) convert N group elements into a fixed-length Ne * N-byte encoding, where Ne is fixed per ciphersuite (). Group values are assumed to be valid elements of the prime-order group. Deserialization MUST fail on invalid or non-canonical encodings.

Scalars A Scalar is an element of the group's scalar field, the prime field of integers modulo the group order p. Addition and multiplication are written + and * via operator overloading. serialize(scalars: list[Scalar]) and deserialize(buffer) batch convert between N scalars and their canonical, fixed-length Ns * N-byte encoding. Scalar values are assumed to be integers in [0, p). A constructor from an integer MUST fail unless the integer is in this range, and deserialization MUST fail on non-canonical encodings. Arithmetic operations reduce their results modulo p.

Linear relations This section specifies the statement being proven: the preimage of a linear map over a group, also known as the preimage of a group homomorphism. The Sigma Protocol proving knowledge of a preimage is specified in .

Linear map A linear map is a matrix-vector product image = M * witness, where M is a matrix of group elements and witness is a vector of scalars. The relation proven is: M and image together form the instance, while witness is the secret. image is the result of the multi-scalar multiplication of each matrix row with the witness, that is, for i in 0, ..., num_equations - 1 num_scalars is the length of witness (the width of M), and num_equations is the number of group elements in image (the height of M). As an example, Schnorr's identification protocol has num_scalars = num_equations = 1 and M = [[G]], where G is the group generator, proving knowledge of the scalar x such that the group element X satisfies X = x * G . Another example is the Chaum-Pedersen relation : given the group generator G and group elements H, X, Y, the prover shows knowledge of a single scalar x such that X = x * G and Y = x * H. Here num_scalars = 1, num_equations = 2, and: Variants of the Chaum-Pedersen relation are widely used for VRFs and anonymous tokens . Affine equations with constant terms can be expressed directly through image terms and coefficients (). More elaborate relations, such as quadratic equations, reduce to this same form by letting instance elements themselves serve as bases (). Computationally-independent bases, sometimes also called auxiliary generators, or nothing up my sleeve (NUMS) generators, may be computed via hash to the curve ().

Representation The linear relations proven with Sigma Protocols are typically sparse: most entries of M are zero. This document handles and serializes them in a sparse, symbolic form rather than as a 2-dimensional vector of group elements. A LinearRelation is the instance for the Sigma Protocol. It fixes the linear map M and the image, that is, the instance (M, image) of the relation R (). The word relation is used here in the linear-algebra sense: a system of linear equations among group elements. A LinearRelation is held and evaluated by both prover and verifier (). The identity and generator have implicit element indices 0 and 1. Each row of M is called an Equation, and consists of two lists of terms. The image terms (the left-hand side) are pairs (element_index, coeff). The image is the sum of coeff * element(instance, element_index). The terms (the right-hand side) are triplets (scalar_index, element_index, coeff). Each coeff is a scalar () fixed by the instance. An empty image or terms list represents the identity element. A constant of the statement (an element carrying no witness scalar) is encoded as an image term (). It MUST NOT be encoded as a right-hand side term whose witness scalar is "fixed" to 1. A coefficient MAY be zero. The instance MUST contain, as individually-indexed elements, every group element on which the statement depends. In particular, all group elements processed by the verifier MUST appear in the statement, else the resulting argument is malleable across its preimages (). For instance, the verifiable-decryption statement M + E1 = x * E0 is encoded with the two image terms (M, 1), (E1, 1), never as the single element F = M + E1. Otherwise, the same proof will verify for any F = M' + E1', even when M' != M. As another example, a statement multiplying a scalar by a sum of elements, such as Y = x * (E0 + E1), is expressed by repeating the scalar index across terms, as terms = [(0, 2, 1), (0, 3, 1)], never as the single element K = E0 + E1. An element may appear multiple times in the same equation, even with the same coefficient and scalar. Every element in instance.elements MUST appear in the terms or image terms of at least one equation. The identity (index 0) and generator (index 1) are available in every instance whether or not an equation uses them. For a valid instance, let: Scalar indices need not be contiguous. Trailing unused scalar variables are not part of the instance. The number of group elements is independent of the number of equations. For instance, Chaum-Pedersen has num_elements = 5, num_equations = 2.

Map evaluation This document writes map(instance, scalars) for the function that evaluates M at scalars: list[Group] 1. out = [] 2. for equation in instance.equations: 3. acc = Group.identity() 4. for (scalar_index, element_index, coeff) in equation.terms: 5. acc = acc + (coeff * scalars[scalar_index]) \ * element(instance, element_index) 6. out.append(acc) 7. return out ]]> With image(instance) we denote the evaluation of each equation's left-hand side.

Specifying the relation This section defines a symbolic notation in the spirit of for declaring scalars, elements, and equations. The notation is a specification convention, not a wire format. Prover and verifier must agree on the compiled LinearRelation () and its serialization (). The notation of this section is the RECOMMENDED way to present a relation. A linear relation is declared as a US-ASCII block: = ... ]]> As a first example, the Chaum-Pedersen relation of is: The relation parameters are the public values of the statement. A parameter whose name begins with an upper-case letter is a group element, and one whose name begins with a lower-case letter is a public scalar (following ); the names under Witness: are the secret scalars. G denotes the group generator at element index 1, and MUST NOT appear among the relation parameters. Every other name used in Equations: is declared exactly once, as a parameter or under Witness:. A declaration MUST compile to a valid instance (). Each equation is an equality between two linear combinations. Each term is the product of an optional coefficient, an optional witness scalar, and exactly one element name. Every equation MUST be linear in the witness. A coefficient is a public constant of the statement evaluated in the scalar field before compilation. An omitted coefficient is 1, and a leading - on a term negates its coefficient. Expressions in parentheses distribute before the term rules apply: 2 * r * (X1 - X2) denotes 2 * r * X1 - 2 * r * X2. As an example with two witness scalars in a single equation, the Okamoto-Schnorr proof proves knowledge of the opening of a Pedersen commitment : ChaumPedersen compiles to elements = [H, X, Y] and equations = [Equation(image=[(3, 1)], terms=[(0, 1, 1)]), Equation(image=[(4, 1)], terms=[(0, 2, 1)])], while PedersenOpening is compiled to a LinearRelation with elements = [H, C] and equations = [Equation(image=[(3, 1)], terms=[(0, 1, 1), (1, 2, 1)])]. The compiled LinearRelation assigns indices in declaration order. Vectors of names (for example, C_0, ..., C_{n-1}) and families of equations stated over an index range unroll, in index order, to names and equations of the ordinary form. Terms compile to the two lists of . A term carrying a witness scalar compiles to the right-hand side term (homomorphism) (scalar_index, element_index, coeff), with its coefficient negated when the term is written on the left-hand side; a term without one (a constant term) compiles to the left-hand side term (image) (element_index, coeff), with its coefficient negated when the term is written on the right-hand side. Terms appear in the order written, left-hand side first; equations compile in the order they are written under Equations:. Indices attach to names: every occurrence of a name, within or across equations, denotes the same scalar or element index, and every occurrence of a scalar parameter denotes the same public value. As an example with a public scalar parameter, below is the relation stating that C opens to the public value m, that is, C - m * G = r * H: m is now a scalar parameter, so m * G is a constant term. The relation compiles to elements = [H, C] and equations = [Equation(image=[(3, 1), (1, -m)], terms=[(0, 2, 1)])]. As an example with a constant term crossing sides, correct ElGamal decryption states that the ciphertext (E0, E1), with E1 = r * X - M, decrypts to M under the decryption key x of X: The constant term - E1 crosses to the image with its coefficient negated: the second equation compiles to Equation(image=[(5, 1), (4, 1)], terms=[(0, 3, 1)]), identically to the spelling M + E1 = x * E0, and both M and E1 are bound individually by the serialization of . As yet another example with a distributed scalar, the following proves correct encryption of a public message M under the aggregate key X1 + X2, as arises in threshold decryption: the ciphertext is (E0, E1), with E0 = r * G and E1 = r * (X1 + X2) - M: The scalar r distributes over the parenthesized sum, so the second equation compiles to Equation(image=[(4, 1), (6, 1)], terms=[(0, 2, 1), (0, 3, 1)]). As a last example, the following proves that the value committed by C is a bit, the building block of range proofs: Bit compiles to elements = [H, C] and equations = [Equation(image=[(3, 1)], terms=[(0, 1, 1), (1, 2, 1)]), Equation(image=[(3, 1)], terms=[(0, 3, 1), (2, 2, 1)])]: the element index 3 (the commitment C) appears both in each equation's image and among the bases of the second equation. AND composition comes for free for this relation family. To do so, concatenate the parameter lists, Witness:, and Equations: of each sub-relation. Under concatenation, a name kept in common should denote the same scalar or element in every sub-relation, and is declared exactly once in the combined declaration. Names not intended to be shared MUST be renamed apart before concatenating.

Instance validation For an instance to be valid, it MUST satisfy all below conditions:

1. Every scalar_index and every element_index is a non-negative integer less than 2^32; so are num_equations(instance), and each equation's term count and image-term count.
2. Every element index is less than num_elements(instance). In other words, every index references a group element.
3. Every element index other than 0 and 1 appears in the terms or image terms of at least one equation; the identity (index 0) and generator (index 1) are present in every instance whether or not an equation uses them (). Together with check 2, this ensures either num_elements(instance) == 2 or num_elements(instance)-1 is the largest referenced element index.

The prover SHOULD reject an invalid instance, and MAY additionally check that image == map(instance, witness) before proving. When parts of the instance come from another party, see and . The verifier MUST fail on an invalid instance (, ), either when the instance is constructed or during verification itself. These checks admit identity images and columns, including M * x = Y with M = 0 and Y = 0, or with M != 0 and Y = 0. ValidateInstance(instance) denotes the function returning true if all above predicates are met. Instance validation cannot tell how a group element was obtained, and so does not detect violations of ().

Serialization A LinearRelation is serialized as a sparse matrix encoded in row-major order. Serialization involves serializing each equation's image terms, then its right-hand side terms, each preceded by its count (). At the end, instance.elements are serialized (identity and generator are implicit). Counts and indices are encoded in 4 bytes via LE (). Coefficients are encoded with the scalar serialization function (Ns bytes each, ). For example, the compiled ChaumPedersen relation of serializes to The same relation expressed in two different ways (for example, swapping two rows of M) will yield different serializations.

The Sigma Protocol This section specifies the proof of knowledge for the preimage of a linear map (). These proofs are sometimes also called Maurer proofs .

Interface A Sigma Protocol provides the following interface:

• ProverCommitment(instance, witness, rng): produces a pair (commitment, prover_state) consisting of the commitment message, and a private prover_state. The prover state MUST be used at most once. The random number generator rng is defined in .
• ProverResponse(prover_state, challenge) produces the response.
• Verifier(instance, commitment, challenge, response), the verification algorithm.

These are the interactive protocol's building blocks. Implementations MAY also provide the zero-knowledge simulator:

• SimulateResponse(instance, rng) -> (response, state), which returns a simulated response, and a simulator state.
• SimulateCommitment(state, response, challenge) -> simulated_commitment, which returns the simulated_commitment such that Verifier(instance, simulated_commitment, challenge, response) accepts.

Both are specified concretely for the linear-map Sigma Protocol in . The simulator is useful for proof composition (e.g. OR-composition ) and for compact serialization . This interface allows for composition, and SHOULD NOT be exposed directly to consumers of the non-interactive argument. In particular, ProverResponse MUST NOT be invoked with a challenge that was not either sent by an honest interactive verifier or derived from the instance and commitment via the Fiat-Shamir transformation (). Supplying an invalid challenge or an arbitrary prover state will compromise soundness and zero-knowledge.

Prover

Prover commitment The prover MAY produce an output (and not fail) if the witness is not valid for the instance provided. The prover MUST fail if the witness length does not match num_scalars(instance): a mismatch cannot yield a valid proof.

Prover response The prover MUST fail if the lengths of witness and nonces mismatch.

Verifier The challenge is a scalar drawn uniformly at random from the scalar field. Non-interactive Sigma Protocols derive the challenge via the Fiat-Shamir transformation (). The verification equation is as follows: The verifier MUST enforce instance validity (Step 1, see ), and that the shape of the transcript matches that of the instance.

Simulator SimulateResponse(instance, rng) returns as simulated response a vector of num_scalars(instance) uniformly random scalars, and as simulator state the instance itself. SimulateCommitment(state, response, challenge) solves the verification equation () for the commitment, returning the vector of num_equations(state) group elements Drawing response uniformly at random with SimulateResponse and then computing commitment with SimulateCommitment yields a transcript (commitment, challenge, response) with the same distribution as an honest one. This is the honest-verifier zero-knowledge property ().

Non-interactive Sigma Protocols The Fiat-Shamir transformation applied to Sigma Protocols yields a non-interactive zero-knowledge argument of knowledge. describes how to instantiate the transformation, for the group and field codecs given. This section specifies how to select the session identifier (), how to produce a challenge (), two flavors of non-interactive argument (NARG) string serialization (), and batch verification ().

Tag and session identifier The session identifier session_id is a 32-byte string. It SHOULD be derived from a string tag using DeriveSessionID of . The tag is a byte string following the security requirements on the session identifier in . It MUST contain, verbatim, the flavor marker, DSFS (duplex sponge Fiat-Shamir) for batchable NARG strings or CMPT for compact NARG strings, and the ciphersuite identifier (). As an example, a reasonable choice of tag for a fictional application named Foo is: where xx is the two-digit number indicating the version, tttt is the four-digit number identifying the epoch, flavor is the serialization flavor marker, and ciphersuiteID is the ciphersuite identifier of . For instance, for batchable NARG strings: The prover and the verifier each construct the tag (or session identifier). Neither should accept a session identifier supplied by an untrusted third party. An adversary who controls the entire session identifier can cause a proof to be accepted where it was never intended.

Challenge derivation The prover and verifier derive the challenge as follows: DS, DeriveSessionID, and DecodeField are defined in ; Ns + 16 is the input length DecodeField requires over a prime field ().

Non-interactive argument string serialization Two serialization flavors are possible:

• A batchable NARG string serializes the prover messages (commitment, response), as in , and it permits amortized verification costs ().
• A compact NARG string serializes (challenge, response). It is preferable in the common case, whenever the commitment (num_equations group elements) is larger than a single challenge scalar.

A batchable NARG string is a (Ne * num_equations + Ns * num_scalars)-byte string, while a compact NARG string is a (Ns * (num_scalars + 1))-byte string. A NARG string verifies only under the flavor it was produced for: the flavor marker is a mandatory tag component (). Both flavors have the same soundness guarantees. NARG strings are not deterministic, and so applications MUST NOT rely on the uniqueness of the NARG string for replay protection or as a nullifier.

Batchable NARG strings A batchable NARG string is the NARG string of , consisting of the concatenation of the serialized prover messages using their respective serialization functions: ProveBatchable and VerifyBatchable are the NARG prover and verifier of instantiated with the Sigma Protocol of . ProveBatchable(tag, instance, witness, rng) computes the commitment message with ProverCommitment, derives the challenge as DeriveChallenge(tag, instance, Group.serialize(commitment)) (), computes the response with ProverResponse(prover_state, challenge), and outputs the NARG string above. VerifyBatchable(tag, instance, narg_string) accepts the proof only if:

1. len(narg_string) is exactly Ne * num_equations(instance) + Ns * num_scalars(instance)
2. deserialization succeeds
3. Verifier(instance, commitment, challenge, response) accepts.

Compact NARG strings A compact NARG string serializes serialize(challenge) || serialize(response). The verifier recomputes the commitment from the challenge and response via SimulateCommitment (), which always returns an accepting transcript, then recomputes the challenge from that commitment and accepts only if it matches the one in the NARG string.

Batch verification Batch verification MAY verify multiple batchable NARG strings more efficiently than individual verification. It can also improve efficiency for a single instance with several equations. Batch verification does not affect the prover or the NARG string. It checks a single random linear combination of the verification equations. See , , and . The verification equation for Nt transcripts (commitment, challenge, response) of preimages of linear relations is: for each transcript index i and each equation index j. Batch verification consists of sampling uniformly random scalars batching_randomness[i][j] (for i = 0, ..., Nt - 1 and j = 0, ..., num_equations(instances[i]) - 1) and checking the single equation: For batching_randomness elements drawn uniformly from a set of 2^t scalars, a false NARG string is accepted with probability at most 2^-t, as in batch verification of Ed25519 signatures ; below, t = 128. The following procedure derives batching randomness deterministically. Alternatively, batching randomness MAY be sampled from a cryptographically secure random number generator. Below, session_ids[i] is the 32-byte session identifier of the i-th NARG string being verified (). The session identifier has fixed length, and the length of each NARG string is determined by the respective instance. Omitting any of the instances or NARG strings (i.e., prover messages) will compromise soundness of batch verification . When sampled, the batching randomness MUST be drawn only after every NARG string in the batch is received, and MUST NOT be reused across batches. The batch verification procedure MUST NOT reuse the duplex sponge of a NARG verifier. The squeezed output is read in row-major order (for example, the second batching randomness corresponds to the second equation of the first transcript). Each 16-byte chunk is interpreted as a little-endian integer via LE2IP (). The batching randomness elements are uniform in [0, 2^128) and are used as scalars without further reduction. The batch verifier MUST perform instance validation for each instance, and MUST compute each of the verifier challenges with DeriveChallenge (). Empty batches are accepted as valid; the batch size MUST be less than 2^32. Upon failure, batch verification does not identify the offending NARG string, and an application may fall back to verifying the NARG strings individually. The batching randomness elements MAY be replaced by the successive powers 1, mu, mu^2, ... of a single random scalar mu, assigned in row-major order (transcripts, then equations) to the pairs (i, j) and computed in the scalar field. Step 7 then squeezes 16 bytes instead of 16 * K, where K = sum(num_equations(instances[i]) for i in 0, ..., Nt - 1) is the total number of batched equations, and mu is their LE2IP value. An invalid batch is then accepted with probability at most (K - 1)/2^128, rather than 2^-128.

Efficiency Considerations Constant arithmetic operations MAY be preprocessed, provided the security requirements of hold. For example, implementations may use fixed-base multiplication tables or skip arithmetic for unused scalar variables and zero-coefficient terms (e.g., 0 * x * G). Because num_scalars(instance) is determined by the largest scalar index, a sparse high index can make responses and NARG strings very large. Implementations SHOULD enforce application-specific limits before allocating resources. Multi-scalar multiplication (MSM) algorithms can help evaluate map(instance, scalars) () and the verification equation. For example, the verifier of is specified as the equality map(instance, response) == commitment + challenge * image(instance), evaluated as two separate vectors for clarity. Implementations MAY instead verify each equation i by checking that commitment[i] + challenge * image(instance)[i] - sum(response[j] * M[i][j] for j in 0, ..., num_scalars(instance) - 1) is identity(), accumulating all terms in a single MSM per equation. Prioritizing field operations, by evaluating expressions over terms and scalar coefficients, will be faster than computing and summing each term individually. The fastest MSM algorithms, such as Pippenger's bucket method or windowed non-adjacent forms, run in time that depends on the scalars. This is safe, for instance, in the verification equation above, for image computation image(instance), and in SimulateCommitment (): there, every scalar is public. The efficiency considerations of apply here too. Implementations that produce or verify many proofs for the same instance can precompute and reuse the duplex sponge state after the instance is absorbed (steps 1-3 of DeriveChallenge, ) across proofs. ValidateInstance () likewise depends only on the instance, and can be checked once per instance rather than once per proof.

Security Considerations A Sigma Protocol run interactively provides the guarantees of . In practice, however, Sigma Protocols are almost always deployed non-interactively via the Fiat-Shamir transformation (); describes how these guarantees carry over and what additional care the non-interactive setting requires. In either setting, every guarantee is relative to the instance: collects the obligations on how prover and verifier construct it and agree on it. The security considerations of apply throughout.

Interactive security properties The interactive Sigma Protocol of has special soundness : two accepting transcripts with the same commitment and distinct challenges yield a witness, so a prover that convinces the verifier must know a witness satisfying the proof statement. Knowledge of a witness is meaningful only when the relation is computationally hard: if witnesses are easy to find, the proof conveys nothing. The interactive Sigma Protocol of is honest-verifier zero knowledge: the prover messages do not reveal any information beyond what can be directly inferred from the statement itself, so an honest verifier gains no knowledge about the witness . Because interactive Sigma Protocols do not have transferable message authenticity, a third party (neither the prover nor the verifier) cannot be convinced that the prover made the proof. The interaction is thus not transferable as evidence to a third party .

Fiat-Shamir transformation Soundness holds only if the encoded instance contains the entire statement being proven (). Omitting any statement element will compromise knowledge soundness of the resulting non-interactive argument . For example, consider the verifiable-decryption statement M + E1 = x * E0. Encoding only the image element F = M + E1 omits M and E1. The resulting NARG string verifies unchanged for every pair (M', E1') with M' + E1' = F. An attacker can therefore reuse a proof for a different plaintext-ciphertext pair. Likewise, encoding Y = x * (E0 + E1) with the single base K = E0 + E1, instead of the two terms x * E0 + x * E1, lets the same NARG string verify for every pair (E0', E1') with E0' + E1' = K. Both encodings pass instance validation () but violate . The challenge set C is the full scalar field (, ), so 1/|C| < 2^-250 for the ciphersuites of . Compositions of Sigma Protocols (out of scope for this document) MAY restrict the challenge to a smaller C. Knowledge extraction in the random oracle model requires rewinding the adversary: by the Forking Lemma , an adversary that outputs an accepting proof with probability epsilon after q hash queries yields a witness with probability about epsilon^2/q, a quadratic loss. In the algebraic group model (with a random oracle), extraction is instead straight-line (when, for each row of M, finding a non-trivial linear relation among its elements is computationally hard) with total extraction error on the order of q/|C| (Section 9 of ).

NARG string validation For group elements, deserialization MUST verify that each point is valid, lies on the curve, and in the prime-order (sub-)group suited for cryptographic use. Uncompressed or hybrid forms of MUST be rejected . Skipping the on-curve or subgroup check enables invalid-curve attacks . Accepting non-canonical field elements will compromise soundness . For scalars, deserialization MUST reject any value that is not the canonical representative in [0, p) .

Instance security The prover and verifier construct the instance from values they independently hold and trust, such as the group generator. Often, one party will supply elements or scalars to the other (). These are untrusted input, and MUST be checked (). For the verifier, those checks are part of verification. The prover MUST NOT produce a proof over an instance without validating well-formedness of all group elements and scalars first. An instance may have many valid witnesses. For example, X = x * G + 5 * y * G collapses to X = (x + 5 * y) * G, and has p distinct witnesses [x, y] trivial from one another. Likewise, x * H - x * H is valid for any x. In general, the witnesses of an instance form a coset of the kernel of M, and a proof establishes knowledge of a witness only up to that kernel. It is the caller's responsibility to choose relations whose kernel is trivial, or for which finding a non-zero kernel element is computationally hard. The same holds for specific requirements on individual elements. For example, when H is the auxiliary generator of a Pedersen commitment, the caller must ensure that H is not the identity and that the committer knows no discrete-logarithm relation between H and G.

Privacy Considerations The NARG string discloses nothing beyond the truth of the statement the instance encodes. However, if the instance is chosen by the adversary the privacy guarantee might be vacuous. Untrusted inputs to the instance need to be validated by the caller. Instance validation () checks only the structure of the result; a well-formed instance may encode an attacker-chosen linear map. ProverCommitment MUST draw fresh nonces on every invocation, even for the same instance and witness. A re-used nonce reveals the witness . (This is the extractor: given different challenges c1 != c2, the witness is (s1 - s2) / (c1 - c2), where s1, s2 are the corresponding responses). ProverCommitment and ProverResponse SHOULD NOT be used interactively with an untrusted verifier: interactive Sigma Protocols only guarantee zero-knowledge against honest verifiers (). For verification, VerifyBatchable and VerifyCompact SHOULD be used. The non-interactive Fiat-Shamir transformation yields statistically zero-knowledge arguments of knowledge. Implementations SHOULD securely delete prover state as soon as it is no longer needed (witness and nonces), and put in place safeguards to prevent re-use of the prover state. Private witness information should not be part of crash dumps and diagnostic logging.

Constant-Time Requirements All group and field operations whose inputs include secret values SHOULD be constant-time in those values. The secret values are the witness, the nonces, and the prover state that carries them. The NARG string is public, and the instance usually is too. Randomness SHOULD be derived using implementations that are constant-time with respect to the entropy drawn (). Implementations MAY skip multiplications by coefficient 1, or test instance coefficients for zero in variable time. The multi-scalar multiplication map(instance, nonces) in ProverCommitment SHOULD be constant-time with respect to its secret scalars. Its bases are public instance elements. Group libraries typically provide a separate interface for this guarantee. The variable-time algorithms of leak scalar bits through window sizes and iteration counts; partial knowledge of the nonces will compromise the witness . Keyed-verification credentials also require constant-time verification because the instance depends on the issuer's secret key. The secret enters the verification equation through the group elements. An MSM that is constant-time only with respect to the scalars is therefore insufficient: point arithmetic must not branch on exceptional cases, and the comparison of the two sides of the verification equation must be constant-time. For OR composition, the witness determines which clause is simulated (). Real and simulated clauses SHOULD follow the same code path, with constant-time selection of the desired transcript.

Post-Quantum Considerations Sigma Protocols are unconditionally sound and honest-verifier zero-knowledge. What breaks in the post-quantum setting are the statements themselves. They are preimages of linear maps in groups where the discrete logarithm problem is assumed hard, and they are meaningful only while computing discrete logarithms remains infeasible. Therefore, relations of SHOULD NOT be used in the presence of quantum adversaries. For instance, in the statement C = m * G + r * H, R = r * G, the witness m is only computationally hidden. The NARG string does not leak the witness. Yet, a quantum adversary may recover r from R and then m from C - r * H, with two discrete logarithm computations. As another example, the statement C = m * G + r * H, D = m * G + s * H, asserting that two commitments open to the same value, is meaningless to a quantum adversary: the commitments bind m only computationally, and an adversary that computes the discrete logarithm of H to the base G can open either of them to any value of its choice. The quantum random-oracle model (QROM) , where the adversary may query the hash function in superposition, is not considered in this document. An analysis of the Fiat-Shamir transformation in the QROM can be found in . Other families of Sigma Protocols, e.g. MPC-in-the-Head , lattice-based , or code-based approaches, can provide post-quantum guarantees, but are not specified in this document. The generic AND composition with a post-quantum-sound Sigma Protocol does not upgrade security. For example, the binding of a Pedersen commitment fails against a quantum adversary regardless of the strength of the conjunct statement, so the combined statement is meaningful only while both underlying problems remain hard. See .

Ciphersuites A ciphersuite for the non-interactive Sigma Protocol () is composed of the following parameters:

• an elliptic curve group, over which the Sigma Protocol of is run,
• a duplex sponge .

The ciphersuites defined by this document, and the identifiers used by the test vectors, are: Non-interactive Sigma Protocol ciphersuites

Identifier	Group	Ne	Ns	Duplex Sponge	Security
sigma-proofs_Shake128_P256	P-256 (secp256r1)	33	32	SHAKE128	128-bit pre-quantum
sigma-proofs_Shake128_BLS12381	BLS12-381 (G1)	48	32	SHAKE128	about 120-bit pre-quantum

Ne and Ns are the byte lengths of a serialized group element and scalar. The ciphersuite identifier fixes the group, the codecs, and the hash instantiation. For all ciphersuites, the scalar serialization length Ns = 32 equals the smallest integer such that 256^Ns >= p, so each challenge consumes Ns + 16 = 48 squeezed bytes (). Note that DecodeField interprets the squeezed bytes as a little-endian integer. The groups are prime-order elliptic curve groups, defined as follows.

P-256 (secp256r1) This ciphersuite uses P-256 for the Group.

Elliptic curve group of P-256 (secp256r1)

• order(): 115792089210356248762697446949407573529996955224135760342422259061068512044369.
• generator(): the base point G specified in ; its compressed serialization is 036b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296.
• serialize([A]): the group element serialization function for (Ne = 33).
• deserialize(buf): the group element deserialization function of , which inverts the conversion above. Every non-identity point MUST perform all checks of Section 5.6.2.3.4 of . Deserialization MUST accept only compressed form, an Ne-byte string that begins with 0x00, 0x02, or 0x03, as specified in .

Scalar Field of P-256

• serialize(s): the big-endian fixed-length integer encoding I2OSP () (Ns = 32).
• deserialize(buf): OS2IP (); it MUST fail unless the result is in [0, order()).

BLS12-381 (G1) This ciphersuite uses the prime-order subgroup G1 of the BLS12-381 elliptic curve .

Elliptic curve group of BLS12-381 (G1)

• order(): 52435875175126190479447740508185965837690552500527637822603658699938581184513.
• generator(): the generator of G1 specified in Section 4.2.1 of : 97f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb.
• serialize([A]): the compressed G1 serialization of Appendix C of (Ne = 48).
• deserialize(buf): inverts the serialization above and MUST perform full point validation.

Scalar Field of BLS12-381

• serialize(s): the big-endian fixed-length integer encoding I2OSP () (Ns = 32).
• deserialize(buf): OS2IP (); it MUST fail unless the result is in [0, order()).

IANA Considerations This document has no IANA actions. The ciphersuite identifiers of are defined by this document and enter the protocol only as components of the tag (); no registry is established.

Acknowledgments The authors thank Jan Bobolz, Vishruti Ganesh, Stephan Krenn, Mary Maller, Ivan Visconti, and Yuwen Zhang for reviewing a previous edition of this specification. The authors thank Giap Vu and David Wong (zkSecurity) for their help and contributions.

References Normative References CNRS Apple, Inc. This document describes the Fiat-Shamir transformation, which allows making a public-coin protocol non-interactive by means of a cryptographic hash function. It specifies how the hash function is employed, how prover messages are encoded as hash-function input, and how verifier messages are decoded from the hash function's output, as well as the serialization and deserialization of the non-interactive argument string. National Institute of Standards and Technology (NIST) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. National Institute of Standards and Technology GMO CONNECT Inc. GMO CONNECT Inc. Carnegie Mellon University Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and they can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security; however, its security level is estimated at approximately 100 bits due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and consider them at the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. This memo also specifies the serialization and deserialization of the points and scalars that protocols exchange, restating a format that is already in widespread use, and states which of the remaining decisions belong to the calling protocol. Informative References National Institute of Standards and Technology (NIST) MATTR MATTR Portage CryptID Grotto Networking This document describes the BBS Signature scheme, a secure, multi- message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs of knowledge of a signature, while selectively disclosing subsets of the signed messages. Being zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature itself, while at the same time, guaranteeing the authenticity and integrity of the disclosed messages. MATTR Grotto Networking This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. Solana Foundation A Verifiable Random Function (VRF) is the public key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the Schnorr non-interactive zero-knowledge (NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly. This document specifies the Schnorr NIZK proof in both the finite field and the elliptic curve settings. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.

Test Vectors This appendix contains test vectors for the non-interactive Sigma Protocols specified in this document, one section per ciphersuite (, ). Each ciphersuite section has two subsections: valid proofs, and adversarial vectors. pins the randomness used, so that the vectors are reproducible from this document alone. The vectors follow the format specified in the Test Vectors appendix of : a block of Key = Value lines, no key repeated, values inline or indented under their key, and sequences written one - item per line. Every vector carries Id, its stable name, and Function, which is SigmaProof throughout this document. Where identifies the duplex sponge suite with Suite, these vectors carry Ciphersuite, which fixes the group and the hash together (). Every vector also carries Expected, which is accept or reject: unlike the functional vectors of , each vector here is a verifier decision. The remaining keys are those of the protocol. Relation names the relation of and Flavor is batchable or compact; one vector covers one flavor, so Tag, SessionId and NargString are unambiguous. Tag is a name: its value is the US-ASCII tag itself, not its hexadecimal encoding. The Witness field, which never appears on the wire, is encoded as the concatenation of Scalar.serialize of the witness scalars, in the order given by each relation. Every adversarial vector carries BaseId, naming the valid vector it is derived from: it re-verifies that transcript under a different tag, statement, or encoding, and a conformant verifier MUST reject it while accepting its baseline. Testing only that the adversarial vectors are rejected is therefore not sufficient; an implementation that rejects every input passes no accept/reject pair. The prose accompanying each vector states which check fails; where the rejection step depends on the implementation's check order, any of the stated rejection points is conformant. Batch verification () can be tested on any subset of these vectors: a batch of valid batchable proofs MUST verify, and a batch containing any invalid batchable proof MUST be rejected.

Seeded PRNG The randomness for these vectors is drawn from a seeded PRNG, instantiated via a duplex sponge initialized with the session identifier DeriveSessionID(prng_tag). The US-ASCII tag: Yields the scalars that build the instance and witness, in the order given by each relation. The tag: Provides the randomness for the prover in the batchable NARG string. That is, it is used to sample num_scalars(instance) commitment nonces of the batchable proof. Finally, the tag: Provides the randomness for the prover in the compact NARG strings. Applications MUST NOT use this deterministic pseudorandom generator. The prover's randomness MUST be seeded from operating-system entropy ().

sigma-proofs_Shake128_P256 This section contains vectors for the ciphersuite identified as sigma-proofs_Shake128_P256.

Valid proofs Knowledge of a discrete logarithm, X = x * G: the Schnorr relation given as example in . Knowledge of a discrete logarithm, X = x * G: the Schnorr relation given as example in . Discrete-logarithm equality, X = x * G and Y = x * H (). Discrete-logarithm equality, X = x * G and Y = x * H (). Knowledge of the opening of a Pedersen commitment, C = m * G + r * H (). Knowledge of the opening of a Pedersen commitment, C = m * G + r * H (). Two Pedersen-form equations sharing both witness scalars, X = x0 * G0 + x1 * G1 and Y = x0 * G2 + x1 * G3 (). Two Pedersen-form equations sharing both witness scalars, X = x0 * G0 + x1 * G1 and Y = x0 * G2 + x1 * G3 (). The blind commitment computation of , C = blind * Q2 + msg_1 * J1 + msg_2 * J2 + msg_3 * J3. The blind commitment computation of , C = blind * Q2 + msg_1 * J1 + msg_2 * J2 + msg_3 * J3. Correct ElGamal decryption, X = x * G and M = x * E0 - E1 (). Correct ElGamal decryption, X = x * G and M = x * E0 - E1 (). The ChaumPedersen relation of again, with Y = x * H derived by the prover from its witness rather than received: the compiled instance matches dleq, and only the tag (hence the proof bytes) differs. The ChaumPedersen relation of again, with Y = x * H derived by the prover from its witness rather than received: the compiled instance matches dleq, and only the tag (hence the proof bytes) differs.

Adversarial vectors Deserialization fails on the SEC1 uncompressed prefix 0x04. Deserialization fails on the SEC1 hybrid prefix 0x06. Deserialization fails on the SEC1 hybrid prefix 0x07. Deserialization fails if the x-coordinate is lifted by the field characteristic (x = 5, encoded as x + p): the coordinate is non-canonical. The padded identity commitment decodes successfully, but the verification equation fails. Deserialization fails on x = 1, which has no square root for y. Deserialization fails if response[0] is set to order + 1. Deserialization fails if challenge is set to order + 1. Verification fails if one trailing 0x00 byte is appended to a valid proof. Verification fails if a valid proof is truncated by one byte. Verification fails if one trailing 0x00 byte is appended to a valid proof. Verification fails if a valid proof is truncated by one byte. Verification fails on the all-zero compact proof: challenge and response are zero. The empty relation, with no equations and no image, is valid. The instance and proof are accepted even though scalar index 1 appears in no equation. Because scalar index 1 is unconstrained, changing response[1] in a valid proof produces another valid proof. The instance and proof are accepted when the image terms X + (-X) sum to the identity. An instance containing the identity element is accepted. Instance validation fails if a term references element index 3 while a single element follows; parsers may instead reject on length. A valid NARG string verifies under the tag it was produced for. Verification fails under a different tag. A valid NARG string verifies under the tag it was produced for. Verification fails under a different tag. A valid NARG string verifies against the statement it was produced for. Verification fails if the statement's two equations are swapped. A valid NARG string verifies against the statement it was produced for. Verification fails if the statement's two equations are swapped. Verification fails if a statement element is changed after proving. Verification fails if a statement element is changed after proving. Verification fails if the batchable proof's transcript is re-encoded as a compact NARG string. Verification fails if the compact proof's transcript is re-encoded as a batchable NARG string: the challenge derived under the batchable tag differs. Verification fails if response[0] is increased by 1. Verification fails if commitment[0] is replaced by a different valid group element. Verification fails if challenge is replaced by a different scalar.

sigma-proofs_Shake128_BLS12381 This section contains vectors for the ciphersuite identified as sigma-proofs_Shake128_BLS12381.

Valid proofs Knowledge of a discrete logarithm, X = x * G: the Schnorr relation given as example in . Knowledge of a discrete logarithm, X = x * G: the Schnorr relation given as example in . Discrete-logarithm equality, X = x * G and Y = x * H (). Discrete-logarithm equality, X = x * G and Y = x * H (). Knowledge of the opening of a Pedersen commitment, C = m * G + r * H (). Knowledge of the opening of a Pedersen commitment, C = m * G + r * H (). Two Pedersen-form equations sharing both witness scalars, X = x0 * G0 + x1 * G1 and Y = x0 * G2 + x1 * G3 (). Two Pedersen-form equations sharing both witness scalars, X = x0 * G0 + x1 * G1 and Y = x0 * G2 + x1 * G3 (). The blind commitment computation of , C = blind * Q2 + msg_1 * J1 + msg_2 * J2 + msg_3 * J3. The blind commitment computation of , C = blind * Q2 + msg_1 * J1 + msg_2 * J2 + msg_3 * J3. Correct ElGamal decryption, X = x * G and M = x * E0 - E1 (). Correct ElGamal decryption, X = x * G and M = x * E0 - E1 (). The ChaumPedersen relation of again, with Y = x * H derived by the prover from its witness rather than received: the compiled instance matches dleq, and only the tag (hence the proof bytes) differs. The ChaumPedersen relation of again, with Y = x * H derived by the prover from its witness rather than received: the compiled instance matches dleq, and only the tag (hence the proof bytes) differs.

Adversarial vectors Deserialization fails if the compression bit is cleared. Deserialization fails if the x-coordinate is lifted by the field characteristic (x = 4, encoded as x + p). The identity commitment decodes successfully, but the verification equation fails. Deserialization fails on a point (x = 0) on the curve but outside the prime-order subgroup G1. Deserialization fails on x = 1, which is not on the curve (x^3 + 4 is a non-residue). Deserialization fails if response[0] is re-encoded as s + order: same value mod p, non-canonical bytes. Reducing instead of rejecting yields malleability. Deserialization fails if challenge is re-encoded as c + order (non-canonical bytes). Verification fails if one trailing 0x00 byte is appended to a valid proof. Verification fails if a valid proof is truncated by one byte. Verification fails if one trailing 0x00 byte is appended to a valid proof. Verification fails if a valid proof is truncated by one byte. Verification fails on the all-zero compact proof: challenge and response are zero. The empty relation, with no equations and no image, is valid. The instance and proof are accepted even though scalar index 1 appears in no equation. Because scalar index 1 is unconstrained, changing response[1] in a valid proof produces another valid proof. The instance and proof are accepted when the image terms X + (-X) sum to the identity. An instance containing the identity element is accepted. Instance validation fails if a term references element index 3 while a single element follows; parsers may instead reject on length. A valid NARG string verifies under the tag it was produced for. Verification fails under a different tag. A valid NARG string verifies under the tag it was produced for. Verification fails under a different tag. A valid NARG string verifies against the statement it was produced for. Verification fails if the statement's two equations are swapped. A valid NARG string verifies against the statement it was produced for. Verification fails if the statement's two equations are swapped. Verification fails if a statement element is changed after proving. Verification fails if a statement element is changed after proving. Verification fails if the batchable proof's transcript is re-encoded as a compact NARG string. Verification fails if the compact proof's transcript is re-encoded as a batchable NARG string: the challenge derived under the batchable tag differs. Verification fails if response[0] is increased by 1. Verification fails if commitment[0] is replaced by a different valid group element. Verification fails if challenge is replaced by a different scalar.