]> CNRS

m@orru.net

Apple, Inc.

cathieyun@gmail.com

IRTF Crypto Forum zero-knowledge sigma protocols cryptography proofs of knowledge A Sigma Protocol is an interactive zero-knowledge proof of knowledge that allows a prover to convince a verifier of the validity of a statement. It satisfies the properties of completeness, soundness, and zero-knowledge, as described in . This document describes Sigma Protocols for proving knowledge of pre-images of linear maps in prime-order elliptic curve groups. 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 Any Sigma Protocol must define a commitment (computed by the prover), a challenge (randomly sampled from a specific distribution), and a response (computed by the prover). One of the advantages of Sigma Protocols is their composability, which enables the construction of more complex protocols. A classic example is the OR composition . Given a Sigma Protocol for N relations, it is possible to prove knowledge of one of N witnesses for those relations . The composed sigma protocols can be made non-interactive using the Fiat-Shamir transformation . However, such compositions must be handled carefully to preserve security properties as discussed in .

Core interface The public functions are obtained relying on an internal structure containing the definition of a Sigma Protocol. SigmaProtocol def prover_commit(self, witness, rng) -> (commitment, prover_state) def prover_response(self, prover_state, challenge) -> response def verifier(self, commitment, challenge, response) -> bool def serialize_commitment(self, commitment) -> bytes def serialize_response(self, response) -> bytes def deserialize_commitment(self, data: bytes) -> commitment def deserialize_response(self, data: bytes) -> response # optional def simulate_response(self, rng) -> response # optional def simulate_commitment(self, response, challenge) -> commitment ]]> Where:

• new(instance) -> SigmaProtocol, denoting the initialization function. This function takes as input an instance generated via a LinearRelation, the public information shared between prover and verifier.
• prover_commit(self, witness: Witness, rng) -> (commitment, prover_state), denoting the commitment phase, that is, the computation of the first message sent by the prover in a Sigma Protocol. This method outputs a new commitment together with its associated prover state, depending on the witness known to the prover, the statement to be proven, and a random number generator rng as defined in . This step generally requires access to a high-quality entropy source to perform the commitment. Leakage of even just a few bits of the commitment could allow for the complete recovery of the witness. The commitment is meant to be shared, while prover_state must be kept secret.
• prover_response(self, prover_state, challenge) -> response, denoting the response phase, that is, the computation of the second message sent by the prover, depending on the witness, the statement, the challenge received from the verifier, and the internal state prover_state. The return value response is a public value and is transmitted to the verifier.
• verifier(self, commitment, challenge, response) -> bool, denoting the verifier algorithm. This method checks that the protocol transcript is valid for the given statement. The verifier algorithm outputs true if verification succeeds, or false if verification fails.
• serialize_commitment(self, commitment) -> bytes, serializes the commitment into a canonical byte representation.
• serialize_response(self, response) -> bytes, serializes the response into a canonical byte representation.
• deserialize_commitment(self, data: bytes) -> commitment, deserializes a byte array into a commitment. This function can raise a DeserializeError if deserialization fails.
• deserialize_response(self, data: bytes) -> response, deserializes a byte array into a response. This function can raise a DeserializeError if deserialization fails.

The final two algorithms describe the zero-knowledge simulator. In particular, they may be used for proof composition (e.g. OR-composition). The function simulate_commitment is also used when verifying short proofs. We have:

• simulate_response(self, rng) -> response, denoting the first stage of the simulator.
• simulate_commitment(self, response, challenge) -> commitment, returning a simulated commitment -- the second phase of the zero-knowledge simulator.

The simulated transcript (commitment, challenge, response) must be indistinguishable from the one generated using the prover algorithms. The abstraction SigmaProtocol allows implementing different types of statements and combiners of those, such as OR statements, validity of t-out-of-n statements, and more.

Randomized algorithms The generation of proofs involves randomized algorithms that take as input a source of randomness, denoted as rng. The functionality required in this document is a secure way to sample non-zero scalars uniformly at random. Algorithms access this functionality through the following interface. bytes: pass def random_scalar(self) -> groups.Scalar: pass ]]> Implementations MUST use a cryptographically secure pseudorandom number generator (CSPRNG) to sample non-zero scalars either by using rejection sampling methods or reducing a large bitstring modulo the group order. Refer to Section A.4 of for guidance about these methods.

Sigma Protocols over prime-order groups The following sub-section presents concrete instantiations of Sigma Protocols over prime-order elliptic curve groups. It relies on a prime-order elliptic-curve group as described in . Valid choices of elliptic curves can be found in . Traditionally, Sigma Protocols are defined in Camenisch-Stadler notation as (for example): In the above, line 1 declares that the proof name is "DLEQ", the public information (the instance) consists of the group elements (G, X, H, Y) denoted in upper-case. Line 2 states that the private information (the witness) consists of the scalar x. Finally, line 3 states that the linear relation that needs to be proven is x * G = X and x * H = Y.

Group abstraction Because of their dominance, the presentation in the following focuses on proof goals over elliptic curves, therefore leveraging additive notation. For prime-order subgroups of residue classes, all notation needs to be changed to multiplicative, and references to elliptic curves (e.g., curve) need to be replaced by their respective counterparts over residue classes. We detail the functions that can be invoked on these objects. Example choices can be found in .

Group

• identity(), returns the neutral element in the group.
• generator(), returns the generator of the prime-order elliptic-curve subgroup used for cryptographic operations.
• order(): returns the order of the group p.
• serialize(elements: [Group; N]), serializes a list of group elements and returns a canonical byte array buf of fixed length Ne * N.
• deserialize(buffer), attempts to map a byte array buffer of size Ne * N into [Group; N], fails if the input is not the valid canonical byte representation of an array of elements of the group. This function can raise a DeserializeError if deserialization fails.
• add(element: Group), implements elliptic curve addition for the two group elements.
• equal(element: Group), returns true if the two elements are the same and false otherwise.
• scalar_mul(scalar: Scalar), implements scalar multiplication for a group element by an element in its respective scalar field.

In this spec, instead of add we will use + with infix notation; instead of equal we will use ==, and instead of scalar_mul we will use *. A similar behavior can be achieved using operator overloading.

Scalar

• identity(): outputs the (additive) identity element in the scalar field.
• add(scalar: Scalar): implements field addition for the elements in the field.
• mul(scalar: Scalar), implements field multiplication.
• random(rng): samples a scalar from the RNG. Securely decoding random bytes into a random scalar is described in Section 9.1.4 of .
• serialize(scalars: list[Scalar; N]): serializes a list of scalars and returns their canonical representation of fixed length Ns * N.
• deserialize(buffer), attempts to map a byte array buffer of size Ns * N into [Scalar; N], and fails if the input is not the valid canonical byte representation of an array of elements of the scalar field. This function can raise a DeserializeError if deserialization fails.

In this spec, instead of add we will use + with infix notation; instead of equal we will use ==, and instead of mul we will use *. A similar behavior can be achieved using operator overloading.

Proofs of preimage of a linear map

Witness representation A witness is an array of scalar elements. The length of the array is denoted num_scalars.

Linear map A linear map takes a Witness (an array of num_scalars in the scalar field) and maps it to an array of group elements. The length of the image is denoted num_elements. Linear maps can be represented as matrix-vector multiplications, where the multiplication is the elliptic curve scalar multiplication defined in . Since the matrix is oftentimes sparse, it is stored in Yale sparse matrix format. Here is an example: The linear map can then be presented as: list[Group; num_elements] ]]>

Initialization The linear map LinearMap is initialized with

Linear map evaluation A witness can be mapped to a vector of group elements via: list[Group; num_elements] Inputs: - self, the current state of the constraint system - witness, 1. image = [] 2. for linear_combination in self.linear_combinations: 3. coefficients = [scalars[i] for i in linear_combination.scalar_indices] 4. elements = [self.group_elements[i] for i in linear_combination.element_indices] 5. image.append(self.Group.msm(coefficients, elements)) 6. return image ]]>

Statements for linear relations A LinearRelation encodes a proof statement of the form linear_map(witness) = image, and is used to prove knowledge of a witness that produces image under linear map. It internally stores linear_map (cf. ) and an image (an array of num_elements Group elements). list[int] def allocate_elements(self, n: int) -> list[int] def append_equation(self, lhs: int, rhs: list[(int, int)]) -> None def set_elements(self, elements: list[(int, Group)]) -> None ]]>

Element and scalar variables allocation Two functions allow to allocate the new scalars (the witness) and group elements (the instance). and below the allocation of group elements Group elements, being part of the instance, can later be set using the function set_elements

Constraint enforcing

Core protocol This defines the object SchnorrProof. The initialization function takes as input the statement, and pre-processes it.

Prover procedures The prover of a Sigma Protocol is stateful and will send two messages, a "commitment" and a "response" message, described below.

Prover commitment

Prover response

Verifier

Example: Schnorr proofs The statement represented in can be written as: At which point it is possible to set var_G and var_X whenever the group elements are at disposal. It is worth noting that in the above example, [X] == statement.linear_map.map([x]).

Example: DLEQ proofs A DLEQ proof proves a statement: Given group elements G, H and X, Y such that x * G = X and x * H = Y, then the statement is generated as:

Example: Pedersen commitments A representation proof proves a statement Given group elements G, H such that C = x * G + r * H, then the statement is generated as:

Ciphersuites We consider ciphersuites of prime-order elliptic curve groups.

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

Elliptic curve group of P-256 (secp256r1)

• order(): Return the integer 115792089210356248762697446949407573529996955224135760342422259061068512044369.
• serialize([A]): Implemented using the compressed Elliptic-Curve-Point-to-Octet-String method according to ; Ne = 33.
• deserialize(buf): Implemented by attempting to read buf into chunks of 33-byte arrays and convert them using the compressed Octet-String-to-Elliptic-Curve-Point method according to , and then performs partial public-key validation as defined in section 5.6.2.3.4 of . This includes checking that the coordinates of the resulting point are in the correct range, that the point is on the curve, and that the point is not the point at infinity.

Scalar Field of P-256

• serialize(s): Relies on the Field-Element-to-Octet-String conversion according to ; Ns = 32.
• deserialize(buf): Reads the byte array buf in chunks of 32 bytes using Octet-String-to-Field-Element from . This function can fail if the input does not represent a Scalar in the range [0, G.Order() - 1].

Security Considerations Interactive Sigma Protocols have the following properties:

• Knowledge soundness: If the proof is valid, the prover must have knowledge of a secret witness satisfying the proof statement. This property ensures that valid proofs cannot be generated without possession of the corresponding witness.
• Honest verifier zero-knowledge: The proof string produced by the prove function does not reveal any information beyond what can be directly inferred from the statement itself. This ensures that honest verifiers gain no knowledge about the witness.
• Completeness: If the statement being proved is true, an honest verifier can be convinced of this fact by an honest prover via the proof.
• Deniable: Because Interactive Sigma Protocols don't have transferable message authenticity, a third party (not the prover or verifier) cannot be convinced that the prover made the proof. This means that the Sigma Protocol interaction is not transferable as evidence to a third party.

Privacy Considerations Sigma Protocols are insecure against malicious verifiers and should not be used. The non-interactive Fiat-Shamir transformation leads to publicly verifiable (transferable) proofs that are statistically zero-knowledge.

Constant-Time Requirements The prover's control flow and memory access patterns are typically influenced by the witness. To prevent side-channel leakage of witness information, which may reveal private values, it is important that the implementation of underlying group and field operations are constant-time. Operations such as modular reduction, scalar multiplication, random value generation, and all other group and field operations are required to be constant-time especially when working with inputs which are private to prevent side-channel attacks which may reveal their values. In some cases, such as keyed-verification credentials, also the verifier must be constant-time. Implementations MUST securely delete prover state as soon as it is no longer needed, and SHOULD minimize the lifetime of sensitive material (witness and instance), explicitly zeroize temporary buffers after proof generation, use secure de-allocation mechanisms when available, and reduce exposure in crash dumps, swap/page files, and diagnostic logging.

Post-Quantum Security Considerations The zero-knowledge proofs described in this document provide statistical zero-knowledge and statistical soundness properties when modeled in the random oracle model.

Privacy Considerations These proofs offer zero-knowledge guarantees, meaning they do not leak any information about the prover's witness beyond what can be inferred from the proven statement itself. This property holds even against quantum adversaries with unbounded computational power. Specifically, these proofs can be used to protect privacy against post-quantum adversaries, in applications demanding:

• Post-quantum anonymity
• Post-quantum unlinkability
• Post-quantum blindness
• Protection against "harvest now, decrypt later" attacks.

Soundness Considerations While the proofs themselves offer privacy protections against quantum adversaries, the hardness of the relation being proven depends (at best) on the hardness of the discrete logarithm problem over the elliptic curves specified in . Since this problem is known to be efficiently solvable by quantum computers using Shor's algorithm, these proofs MUST NOT be relied upon for post-quantum soundness guarantees. Implementations requiring post-quantum soundness SHOULD transition to alternative proof systems such as:

• MPC-in-the-Head approaches as described in
• Lattice-based approaches as described in
• Code-based approaches as described in

Implementations should consider the timeline for quantum computing advances when planning migration to post-quantum sound alternatives. Implementers MAY adopt a hybrid approach during migration to post-quantum security by using AND composition of proofs. This approach enables gradual migration while maintaining security against classical adversaries. This composition retains soundness if both problems remain hard. AND composition of proofs is NOT described in this specification, but examples may be found in the proof-of-concept implementation and in .

Generation of the protocol identifier As of now, it is responsibility of the user to pick a unique protocol identifier that identifies the proof system. This will be expanded in future versions of this specification.

Generation of the instance identifier As of now, it is responsibility of the user to pick a unique instance identifier that identifies the statement being proven.

Acknowledgments The authors thank Jan Bobolz, Vishruti Ganesh, Stephan Krenn, Mary Maller, Ivan Visconti, Yuwen Zhang for reviewing a previous edition of this specification.

References Normative References National Institute of Standards and Technology Informative References n.d. n.d. n.d. National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.)

Test Vectors

Seeded PRNG For interoperability, the random number generator used for test vectors is implemented using the duplex sponge SHAKE128 instantiation in Section 8.1 of , absorbing a seed of 32 bytes. The Seeded PRNG is for reproducible test vectors; production implementations MUST use a CSPRNG. Random scalars are generated squeezing Ns + 16 bytes, seen as a big-endian positive integer and reduced modulo p, as in Section 9.1.4 of . Scalar: Ns = (self.order.bit_length() + 7) // 8 random_integer = OS2IP(self.hash_state.squeeze(Ns + 16)) return Scalar(random_integer % self.order) ]]> The following sections contain test vectors for the Sigma Protocols specified in this document.

discrete_logarithm

dleq

pedersen_commitment

pedersen_commitment_dleq

bbs_blind_commitment_computation