]> 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 to ensure privacy of the witness. 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 .

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 non-neutral group elements into a fixed-length Ne * N-byte encoding, where Ne is fixed per ciphersuite (). Both serialize and deserialize are defined only on non-neutral elements. Serialization MUST fail on the identity element, and deserialization MUST fail for invalid encodings, including on the encoding of the identity. An honest prover statistically hits this event only with negligible probability. See , Appendix C of , , .

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. 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. The "discard method" of Appendix A.4.2 of SHOULD NOT be used .

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. M and image together form the statement (the instance), while witness is the secret. The relation (the set of instance-witness pairs of which knowledge is proven) is: image is the result of the multi-scalar multiplication of each matrix row with the witness. 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 . Proofs of knowledge of the opening (m, r) of a Pedersen commitment C = m * G + r * H are Okamoto-Schnorr proofs . 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 (). The group Group, and its generator, are provided by the ciphersuite . The statement author has the responsibility to select the appropriate M, and this requires care. 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 (). There might be multiple witnesses for the same (M, image), or no valid witness. 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 (). A LinearRelation holds a set of group elements (each corresponding to an element_index) and a list of equations. 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 * elements[element_index]. The terms (the right-hand side) are triplets (scalar_index, element_index, coeff). Each coeff is a scalar () fixed by the instance. A LinearRelation MUST have at least one equation, and every equation's image and terms MUST be non-empty. 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, 1, 1), (0, 2, 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 group element index MUST have an associated group element. Every element MUST appear in the terms or image terms of at least one equation, except for the generator (index 0), which is present in every instance whether or not an equation uses it. Every scalar index MUST appear in at least one term, else the corresponding response is accepted unchecked. For a valid instance, let: The number of group elements is independent of the number of equations. For instance, Chaum-Pedersen has num_elements = 4, 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]) \ * instance.elements[element_index] 6. out.append(acc) 7. return out ]]> image(instance) denotes the evaluation of each equation's left-hand side: the list of num_equations(instance) group elements whose i-th entry is the sum of coeff * instance.elements[element_index] over the image terms of the i-th equation.

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 0, 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 (). All elements and witness scalars MUST be used (). 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 = [G, H, X, Y] and equations = [Equation(image=[(2, 1)], terms=[(0, 0, 1)]), Equation(image=[(3, 1)], terms=[(0, 1, 1)])], while PedersenOpening is compiled to a LinearRelation with elements = [G, H, C] and equations = [Equation(image=[(2, 1)], terms=[(0, 0, 1), (1, 1, 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); 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 = [G, H, C] and equations = [Equation(image=[(2, 1), (0, -m)], terms=[(0, 1, 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=[(4, 1), (3, 1)], terms=[(0, 2, 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=[(3, 1), (5, 1)], terms=[(0, 1, 1), (0, 2, 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 = [G, H, C] and equations = [Equation(image=[(2, 1)], terms=[(0, 0, 1), (1, 1, 1)]), Equation(image=[(2, 1)], terms=[(0, 2, 1), (2, 1, 1)])]: the element index 2 (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. The instance has at least one equation: num_equations(instance) > 0.
2. Every equation in instance.equations has a non-empty terms list and a non-empty image list.
3. 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.
4. Every element index is less than num_elements(instance). In other words, every index references a group element.
5. Every element index other than 0 appears in the terms or image terms of at least one equation; the generator (index 0) is present in every instance whether or not an equation uses it (). Together with check 4, this ensures num_elements(instance)-1 is the largest referenced element index.
6. Every scalar index appears in the terms of at least one equation.
7. num_elements(instance) > 0, and instance.elements[0] is the group generator Group.generator() ().
8. No element of instance.elements is the identity element.
9. No element of image(instance) is the identity element: an equation whose image evaluates to the identity is satisfied by the all-zero witness, so a proof of it attests nothing.
10. No column of the matrix M is the identity. That is, for every scalar index, there is at least one equation for which the sum of coeff * elements[element_index] over the terms carrying that scalar index is not the identity.

The prover SHOULD reject an invalid instance, and MAY additionally check that image == map(instance, witness) before proving; and state when this check, or a stronger precaution, is required. The verifier MUST fail on an invalid instance (, ), either when the instance is constructed or during verification itself. ValidateInstance(instance) denotes the function returning true if all above predicates are met. Instance validation won't flag all violations of (for instance, a registered element obtained as a precomputed linear combination from one obtained independently) because the instance generation can't know how a group element is obtained. A structurally valid instance may still yield an unsound argument.

Serialization A LinearRelation is serialized as a sparse matrix encoded in row-major order: each equation's image terms, then its right-hand side terms, each list preceded by its count (), followed by the group elements at indices 1 onwards. Counts and indices are encoded in 4 bytes via LE (). Coefficients are encoded with the scalar serialization function (Ns bytes each, ). The encoding is unambiguous and prefix-free. For example, the compiled ChaumPedersen relation of serializes to SerializeLinearRelation operates on a LinearRelation as compiled from its declaration, following its equation and term order (). 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 The prover of a Sigma Protocol is stateful and will send two messages, described below.

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 Implementations that expose the zero-knowledge simulator () provide the two algorithms below; they are also what the compact verifier () relies on to recover the prover's commitment from (challenge, response). 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 the session identifier binding a proof to its application (), the challenge derivation shared by prover and verifier (), the two non-interactive argument (NARG) string serializations (), 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 prover and verifier initialize their duplex sponge state from it (). The tag is a byte string following the security requirements on the session identifier in . It MUST contain, verbatim, the flavor (DSFS for batchable NARG strings, CMPT for compact NARG strings), and the ciphersuite identifier (). Following the domain-separation conventions of , an application concatenates its own name, version, and epoch with these two components. 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 corresponding tag for compact NARG strings replaces the flavor marker DSFS (duplex sponge Fiat-Shamir) with CMPT. The prover and the verifier each construct the tag (or session identifier). Neither should accept a session identifier supplied by a 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 derives the challenge from the tag (), the instance being proven, and the serialized commitment message; the verifier re-derives it from the same values, exactly as the prover does. Both compute DeriveChallenge, which outputs the challenge, a scalar: DS, DeriveSessionID, and DecodeField are defined in ; Ns + 16 is the input length DecodeField requires over a prime field, and the choices of DecodeField for the ciphersuites of this document are discussed in . The challenge is drawn from the full scalar 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) checks:
  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 Sigma Protocol transcript is recovered by invoking the simulator. The verifier recomputes the commitment from the challenge and response via SimulateCommitment (), then recomputes the challenge from that commitment and accepts only if it matches the one in the NARG string. Step 7 maintains consistency with Group.deserialize, which rejects the identity element. Since the simulator always outputs accepting transcripts, there is no need to run Verifier in this case.

Batch verification Verification of multiple batchable NARG strings MAY be done more efficiently than verifying each NARG string on its own, via batch verification. Batch verification can be more efficient even in the presence of a single instance, provided the instance has at least a few equations. Batch verification is a local verifier-side optimization, which affects neither the prover nor the NARG string. Batch verification is done by re-computing the verifier challenge of each NARG string individually (), and then checking a single random linear combination of the verification equations of the whole batch. 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: Similarly to batch verification of Ed25519 signatures , a false NARG string will be accepted with probability at most 2^-128, which is negligible. In general, for batching_randomness elements drawn uniformly from a set of 2^t scalars, a false NARG string will be accepted with probability at most 2^-t. It is RECOMMENDED that the batching randomness be generated deterministically, with the duplex sponge of as follows; it MAY instead be freshly 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. 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; an application may fall back to verifying the NARG strings individually. Batch verification is sound only if the prover(s) cannot choose their messages as a function of the batching randomness. When derived deterministically, the batching randomness MUST therefore absorb every value in the batched equation before squeezing. In particular, this includes the response message. Omitting prover messages from the derivation 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 batching randomness elements MAY be replaced by the successive powers 1, mu, mu^2, ... of a single uniformly random scalar mu, assigned in row-major order (transcripts, then equations) to the pairs (i, j) and computed in the scalar field. In this case, step 7 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 the little-endian integer they encode, read via LE2IP (), uniformly distributed in [0, 2^128). In this case, an invalid batch is accepted with probability at most (K - 1)/2^128, rather than the 2^-128 achieved by independent sampling.

Efficiency Considerations Constant arithmetic operations MAY be preprocessed, provided the security requirements of hold: evaluation-time precomputation, such as fixed-base multiplication tables, is safe; registering a precomputed linear combination as a new instance element is not. 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.

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 The security considerations of apply here as well. 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. If encoded with the single image element F = M + E1, then M and E1 never enter the instance encoding function, and the resulting NARG string is malleable across statements: it verifies (unchanged) for every pair (M', E1') with M' + E1' = F. An attacker can thus present a NARG string generated for one plaintext-ciphertext pair as valid for a different one. Another example: encoding Y = x * (E0 + E1) with the single element K = E0 + E1 as base instead of the two terms x * E0 + x * E1 verifies unchanged for every pair (E0', E1') with E0' + E1' = K. requires the instance to contain, individually, every group element on which the application's acceptance depends; both examples above violate that requirement while remaining structurally valid (). The challenge is drawn uniformly at random from the scalar field (), and the non-interactive instantiations of always derive full-field challenges. Writing C for the set the challenge is drawn from, 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 challenge set 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 The security considerations of apply here too. In particular, 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 . The identity element MUST be rejected in any deserialized prover messages and instance elements (). For scalars, deserialization MUST reject any value that is not the canonical representative in [0, p) . For compact NARG strings, the verifier MUST recompute the challenge and compare it before accepting.

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. Some equations pin down no specific scalars. For example, the equation X = x * G + 5 * y * G collapses to X = (x + 5 * y) * G, and has p distinct witnesses [x, y], each trivial to derive from any other. Similarly, the pair of terms x * H - x * H cancels for every value of x, and constrains nothing. It is the responsibility of the caller to provide non-trivial relations. Some effort in this direction is made in (such as rejection of trivial images), however this will not cover all cases. Applications MUST handle degenerate equations before calling the prover and verifier.

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. The entropy source of ProverCommitment MUST provide different scalars for every different input. 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). The Verifier procedure 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 instance), 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 The secret values of this document are the witness, the nonces, and the prover state that carries them. The instance and the NARG string are public. All group and field operations whose inputs include secret values SHOULD be constant-time in those values, and randomness SHOULD be derived with straight-line code, avoiding rejection sampling and other methods whose iteration count depends on the entropy drawn (). Implementations MAY skip multiplications by coefficient 1, or test instance coefficients for zero in variable time. The dominant secret-dependent operation is the multi-scalar multiplication map(instance, nonces) in ProverCommitment, whose scalars are secret and whose bases are public instance elements: it SHOULD be constant-time with respect to the scalars, a guarantee group libraries typically offer as an interface separate from their variable-time MSM. The variable-time algorithms of leak scalar bits through window sizes and iteration counts, and partial knowledge of the nonces will compromise the witness . In some applications, such as keyed-verification credentials, constant-time implementations are required for the verifier too: there, the instance itself depends on the issuer's secret key. The secret then enters the verification equation through the group elements rather than the scalars, and an MSM that is constant-time only with respect to the scalars is not sufficient: the point arithmetic must not branch on exceptional cases, and the comparison of the two sides of the verification equation must be constant-time. The constant-time requirements of apply here, and extend to the encoding of the instance during challenge derivation. Implementations that expose the simulator () for OR composition should note that which clause is simulated is itself determined by the witness. 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

Each row uses the Sigma Protocol of over the named group. Ne and Ns are the element and scalar byte lengths of that group. The ciphersuite identifier fixes the group, the codecs, and the hash instantiation, and is included verbatim in the tag (). For every ciphersuite in this document, the verifier challenge is derived with DecodeField(buf, p, 1) exactly as specified in : the scalar field is prime, and its serialization length Ns = 32 equals the smallest integer such that 256^Ns >= p, so provers and verifiers squeeze exactly Ns + 16 = 48 bytes per challenge (). 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. It is the group element at index 0 of every instance ().
• serialize([A]): the compressed Elliptic-Curve-Point-to-Octet-String conversion of (Ne = 33).
• deserialize(buf): inverts the conversion above; only the compressed form is a valid encoding (each Ne-byte slice begins with 0x02 or 0x03). It MUST perform partial public-key validation as defined in Section 5.6.2.3.4 of and MUST fail otherwise.

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 for the Group.

Elliptic curve group of BLS12-381 (G1)

• order(): 52435875175126190479447740508185965837690552500527637822603658699938581184513.
• generator(): the generator of G1 specified in Section 4.2.1 of ; its compressed serialization is 97f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb. It is the group element at index 0 of every instance ().
• serialize([A]): the compressed G1 serialization of Appendix C of (Ne = 48). The point-at-infinity encoding of that format (I_bit set) is neither produced () nor accepted.
• deserialize(buf): inverts the serialization above. It MUST perform full point validation and MUST reject the point at infinity.

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 This document describes how to construct a non-interactive proof via the Fiat–Shamir transformation, using a generic procedure that compiles an interactive proof into a non-interactive one by relying on a stateful duplex sponge object. The duplex sponge interface requires two methods: absorb and squeeze, which respectively read and write elements of a specified base type. The absorb operation incrementally updates the duplex sponge's internal state, while the squeeze operation produces variable-length, unpredictable outputs. This interface can be instantiated with different constructions based on permutation or compression functions. This specification also defines codecs to securely map prover messages into the duplex sponge domain, from the duplex sponge domain into verifier messages. It also establishes how the non-interactive argument string should be serialized. 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. Stanford 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 it 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, it ensures no more than the 100-bit security level 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 classify them in 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. Informative References National Institute of Standards and Technology (NIST) Apple, Inc. Apple, Inc. Cloudflare This document specifies the Anonymous Rate-Limited Credential (ARC) protocol, a specialization of keyed-verification anonymous credentials with support for rate limiting. ARC credentials can be presented from client to server up to some fixed number of times, where each presentation is cryptographically bound to client secrets and application-specific public information, such that each presentation is unlinkable from the others as well as the original credential creation. ARC is useful in applications where a server needs to throttle or rate-limit access from anonymous clients. MATTR MATTR Portage CryptID 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. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cfrg. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures. 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 hash suite with Hash, 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. 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. Deserialization fails on 0x00 padded to Ne bytes. 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. Instance validation fails if scalar index 1 appears in no equation (check 6); the proof satisfies the verification equations, so rejection must come from instance validation. Instance validation fails on the same instance, here with the unconstrained response[1] perturbed. Instance validation fails if the image terms X + (-X) sum to the identity (check 9). Instance validation fails if a statement element is the identity (check 8), here at index 1, encoded as stand-in bytes (P-256 has no identity encoding); parsers may instead reject at group deserialization. Instance validation fails if a term references element index 2 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). Deserialization fails on the canonical compressed encoding of the point at infinity: the identity is invalid in prover messages. 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. Instance validation fails if scalar index 1 appears in no equation (check 6); the proof satisfies the verification equations, so rejection must come from instance validation. Instance validation fails on the same instance, here with the unconstrained response[1] perturbed. Instance validation fails if the image terms X + (-X) sum to the identity (check 9). Instance validation fails if a statement element is the identity (check 8), here at index 1, encoded as the canonical compressed encoding of infinity; parsers may instead reject at group deserialization. Instance validation fails if a term references element index 2 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.