Internet-Draft Interactive Sigma Proofs March 2026
Orrù & Yun Expires 14 September 2026 [Page]
Workgroup:
Crypto Forum
Internet-Draft:
draft-irtf-cfrg-sigma-protocols-latest
Published:
Intended Status:
Informational
Expires:
Authors:
M. Orrù
CNRS
C. Yun
Apple, Inc.

Interactive Sigma Proofs

Abstract

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 Section 3.

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

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://mmaker.github.io/draft-irtf-cfrg-sigma-protocols/draft-irtf-cfrg-sigma-protocols.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-irtf-cfrg-sigma-protocols/.

Discussion of this document takes place on the Crypto Forum Research Group mailing list (mailto:cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cfrg. Subscribe at https://www.ietf.org/mailman/listinfo/cfrg/.

Source for this draft and an issue tracker can be found at https://github.com/mmaker/draft-irtf-cfrg-sigma-protocols.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 14 September 2026.

Table of Contents

1. 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 [CramerDS94]. 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 [Cramer97]. However, such compositions must be handled carefully to preserve security properties as discussed in Section 3.

1.1. Core interface

The public functions are obtained relying on an internal structure containing the definition of a Sigma Protocol.

class SigmaProtocol:
   def new(instance) -> 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 Section 1.1.1. 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.

1.1.1. 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.

class CSRNG(ABC):
    def getrandom(self, length: int) -> 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 [FIPS.186-5] for guidance about these methods.

2. 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 Section 2.1.

Valid choices of elliptic curves can be found in Section 2.3.

Traditionally, Sigma Protocols are defined in Camenisch-Stadler [CS97] notation as (for example):

1. DLEQ(G, H, X, Y) = PoK{
2.   (x):        // Secret variables
3.   X = x * G, Y = x * H        // Predicates to satisfy
4. }

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.

2.1. 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 Section 2.3.

2.1.1. 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.

2.1.2. 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 [fiat-shamir].

  • 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.

2.2. Proofs of preimage of a linear map

2.2.1. Witness representation

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

Witness = [Scalar; num_scalars]

2.2.2. 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 Section 2.1.

Since the matrix is oftentimes sparse, it is stored in Yale sparse matrix format.

Here is an example:

class LinearCombination:
    scalar_indices: list[int]
    element_indices: list[int]

The linear map can then be presented as:

class LinearMap:
    Group: groups.Group
    linear_combinations: list[LinearCombination]
    group_elements: list[Group]
    num_scalars: int
    num_elements: int

    def map(self, scalars: list[Group.ScalarField; num_scalars]) -> list[Group; num_elements]
2.2.2.1. Initialization

The linear map LinearMap is initialized with

linear_combinations = []
group_elements = []
num_scalars = 0
num_elements = 0
2.2.2.2. Linear map evaluation

A witness can be mapped to a vector of group elements via:

map(self, scalars: [Scalar; num_scalars]) -> 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

2.2.3. 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. Section 2.2.2) and an image (an array of num_elements Group elements).

class LinearRelation:
    Domain = group.ScalarField
    Image = group.Group

    linear_map = LinearMap
    image = list[group.Group]

def allocate_scalars(self, n: int) -> 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
2.2.3.1. Element and scalar variables allocation

Two functions allow to allocate the new scalars (the witness) and group elements (the instance).

allocate_scalars(self, n)

Inputs:
    - self, the current state of the LinearRelation
    - n, the number of scalars to allocate
Outputs:
    - indices, a list of integers each pointing to the new allocated scalars

Procedure:

1. indices = range(self.num_scalars, self.num_scalars + n)
2. self.num_scalars += n
3. return indices

and below the allocation of group elements

allocate_elements(self, n)

Inputs:
    - self, the current state of the LinearRelation
    - n, the number of elements to allocate
Outputs:
    - indices, a list of integers each pointing to the new allocated elements

Procedure:

1. indices = range(self.num_elements, self.num_elements + n)
2. self.num_elements += n
3. return indices

Group elements, being part of the instance, can later be set using the function set_elements

set_elements(self, elements)

Inputs:
    - self, the current state of the LinearRelation
    - elements, a list of pairs of indices and group elements to be set

Procedure:

1. for index, element in elements:
2.   self.linear_map.group_elements[index] = element
2.2.3.2. Constraint enforcing
append_equation(self, lhs, rhs)

Inputs:

- self, the current state of the constraint system
- lhs, the left-hand side of the equation
- rhs, the right-hand side of the equation (a list of (ScalarIndex, GroupEltIndex) pairs)

Outputs:

- An Equation instance that enforces the desired relation

Procedure:

1. linear_combination = LinearMap.LinearCombination(scalar_indices=[x[0] for x in rhs], element_indices=[x[1] for x in rhs])
2. self.linear_map.append(linear_combination)
3. self._image.append(lhs)

2.2.4. Core protocol

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

2.2.5. Prover procedures

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

2.2.5.1. Prover commitment
prover_commit(self, witness, rng)

Inputs:

- witness, an array of scalars
- rng, a cryptographically secure random number generator

Outputs:

- A (private) prover state, holding the information of the interactive prover necessary for producing the protocol response
- A (public) commitment message, an element of the linear map image, that is, a vector of group elements.

Procedure:

1. nonces = [rng.random_scalar() for _ in range(self.instance.linear_map.num_scalars)]
2. prover_state = self.ProverState(witness, nonces)
3. commitment = self.instance.linear_map(nonces)
4. return (prover_state, commitment)
2.2.5.2. Prover response
prover_response(self, prover_state, challenge)

Inputs:

    - prover_state, the current state of the prover
    - challenge, the verifier challenge scalar

Outputs:

    - An array of scalar elements composing the response

Procedure:

1. witness, nonces = prover_state
2. return [nonces[i] + witness[i] * challenge for i in range(self.instance.linear_map.num_scalars)]

2.2.6. Verifier

verify(self, commitment, challenge, response)

Inputs:

- self, the current state of the SigmaProtocol
- commitment, the commitment generated by the prover
- challenge, the challenge generated by the verifier
- response, the response generated by the prover

Outputs:

- A boolean indicating whether the verification succeeded

Procedure:

1. assert len(commitment) == self.instance.linear_map.num_constraints and len(response) == self.instance.linear_map.num_scalars
2. expected = self.instance.linear_map(response)
3. got = [commitment[i] + self.instance.image[i] * challenge for i in range(self.instance.linear_map.num_constraints)]
4. return got == expected

2.2.7. Example: Schnorr proofs

The statement represented in Section 2 can be written as:

statement = LinearRelation(group)
[var_x] = statement.allocate_scalars(1)
[var_G, var_X] = statement.allocate_elements(2)
statement.append_equation(var_X, [(var_x, var_G)])

At which point it is possible to set var_G and var_X whenever the group elements are at disposal.

G = group.generator()
statement.set_elements([(var_G, G), (var_X, X)])

It is worth noting that in the above example, [X] == statement.linear_map.map([x]).

2.2.8. Example: DLEQ proofs

A DLEQ proof proves a statement:

    DLEQ(G, H, X, Y) = PoK{(x): X = x * G, Y = x * H}

Given group elements G, H and X, Y such that x * G = X and x * H = Y, then the statement is generated as:

1. statement = LinearRelation()
2. [var_x] = statement.allocate_scalars(1)
3. [var_G, var_X, var_H, var_Y] = statement.allocate_elements(4)
4. statement.set_elements([(var_G, G), (var_H, H), (var_X, X), (var_Y, Y)])
5. statement.append_equation(X, [(var_x, G)])
6. statement.append_equation(Y, [(var_x, H)])

2.2.9. Example: Pedersen commitments

A representation proof proves a statement

    REPR(G, H, C) = PoK{(x, r): C = x * G + r * H}

Given group elements G, H such that C = x * G + r * H, then the statement is generated as:

1. statement = LinearRelation()
2. var_x, var_r = statement.allocate_scalars(2)
3. [var_G, var_H, var_C] = statement.allocate_elements(3)
4. statement.set_elements([(var_G, G), (var_H, H), (var_C, C)])
5. statement.append_equation(C, [(var_x, G), (var_r, H)])

2.3. Ciphersuites

We consider ciphersuites of prime-order elliptic curve groups.

2.3.1. P-256 (secp256r1)

This ciphersuite uses P-256 [SP800] for the Group.

2.3.1.1. Elliptic curve group of P-256 (secp256r1) [SP800]
  • order(): Return the integer 115792089210356248762697446949407573529996955224135760342422259061068512044369.

  • serialize([A]): Implemented using the compressed Elliptic-Curve-Point-to-Octet-String method according to [SEC1]; 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 [SEC1], and then performs partial public-key validation as defined in section 5.6.2.3.4 of [KEYAGREEMENT]. 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.

2.3.1.2. Scalar Field of P-256
  • serialize(s): Relies on the Field-Element-to-Octet-String conversion according to [SEC1]; Ns = 32.

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

3. Security Considerations

Interactive Sigma Protocols have the following properties:

3.1. 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.

3.2. 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.

4. 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.

4.1. 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.

4.2. 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 Section 2.3. 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:

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 [BonehS23].

5. 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.

6. 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

[KEYAGREEMENT]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-56ar3, , <https://doi.org/10.6028/nist.sp.800-56ar3>.

Informative References

[AttemaCK21]
Attema, T., Cramer, R., and L. Kohl, "A Compressed Sigma-Protocol Theory for Lattices", <https://dl.acm.org/doi/10.1007/978-3-030-84245-1_19>.
[BonehS23]
Boneh, D. and V. Shoup, "A Graduate Course in Applied Cryptography", n.d., <https://toc.cryptobook.us/>.
[Cramer97]
Cramer, R., "Modular Design of Secure yet Practical Cryptographic Protocols", , <https://ir.cwi.nl/pub/21438>.
[CramerDS94]
Cramer, R., Damgaard, I., and B. Schoenmakers, "Proofs of Partial Knowledge and Simplified Design of Witness Hiding Protocols", , <https://ir.cwi.nl/pub/1456/1456D.pdf>.
[CS97]
Camenisch, J. and M. Stadler, "Proof Systems for General Statements about Discrete Logarithms", n.d., <https://crypto.ethz.ch/publications/files/CamSta97b.pdf>.
[fiat-shamir]
"draft-irtf-cfrg-fiat-shamir", <https://mmaker.github.io/draft-irtf-cfrg-sigma-protocols/draft-irtf-cfrg-fiat-shamir.html>.
[FIPS-202]
"SHA-3 standard :: permutation-based hash and extendable-output functions", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.202, , <https://doi.org/10.6028/nist.fips.202>.
[FIPS.186-5]
"Digital Signature Standard (DSS)", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.186-5, , <https://doi.org/10.6028/nist.fips.186-5>.
[GiacomelliMO16]
Giacomelli, I., Madsen, J., and C. Orlandi, "ZKBoo: Faster Zero-Knowledge for Boolean Circuits", <https://eprint.iacr.org/2016/163.pdf>.
[SEC1]
Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", <https://www.secg.org/sec1-v2.pdf>.
[SP800]
"Recommendations for Discrete Logarithm-based Cryptography", n.d., <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf>.
[Stern93]
Stern, J., "A New Identification Scheme Based on Syndrome Decoding", , <https://link.springer.com/chapter/10.1007/3-540-48329-2_2>.

Appendix A. Test Vectors

A.1. 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 [fiat-shamir], 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 [fiat-shamir].

class SeededPRNG:
    def __init__(self, seed: bytes, order: int):
        assert(len(seed) == 32)
        self.order = order
        self.hash_state = SHAKE128(b"sigma-proofs/TestDRNG/SHAKE128".ljust(64, b"\x00"))
        self.hash_state.absorb(seed)

    def random_scalar(self) -> 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.

The test vectors are grouped by ciphersuite. Each vector includes a Relation field naming the relation being proved and a Ciphersuite field identifying the non-interactive instantiation used to generate the proof bytes.

A.2. sigma-proofs(P-256, SHAKE128)

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

A.3. discrete_logarithm

Relation = discrete_logarithm
Ciphersuite = sigma-proofs_Shake128_P256
SessionId = 64697363726574655f6c6f6761726974686d
Statement = 0100000001000000010000000000000000000000036b17d1f2e12c42
47f8bce6e563a440f277037d812deb33a0f4a13945d898c29602bd6f9ee95eae1bc3
4fa4c48d08e87bc9c6393ae536b21a055a8773678d323425
Witness = cd94f2512f4901f6d91cc8645cec273e44d9ced56709fa8ba7f071af8e
226541
Proof = 89629aeeac1e3600028e2b73a6790675dccaa2c489adc30543fdec782bca
6718dd7c56ecad1eef1ba13c9a850df8ef9c0546797a638c718b01145383c41081cf
Batchable Proof = 03c96531225d9ebf39a42a5ad2c8efe9e2f979e705cce15828
8c05b1c90ecb3d87927e278193b9e71d4daaac5c1a2bec6d348c53ab5949338bcb0d
b445ed1b9c8e

A.4. dleq

Relation = dleq
Ciphersuite = sigma-proofs_Shake128_P256
SessionId = 646c6571
Statement = 02000000010000000100000000000000000000000300000001000000
0000000002000000036b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4
a13945d898c296038246b3bd00714116c8e219f8edc58ca32e0325f5772ee139d734
b039a1a7ba8202bd6f9ee95eae1bc34fa4c48d08e87bc9c6393ae536b21a055a8773
678d3234250257da48a9240814e0d8afe4dfc9a41d13019b1a51f9886c3def34e022
bc8726f8
Witness = 80e9110d93d39b6dc377f7bee6f864816eb334ea2dc480351cb4bd83f5
951a26
Proof = 5dae5df3d20a5f330800f11020924b1799c0c9b8e93dc3db04b6012db0b1
f1c29fcc4d3353f3217e170b679400cb1605711c209252bb8d3d9151478a59a198b7
Batchable Proof = 03c96531225d9ebf39a42a5ad2c8efe9e2f979e705cce15828
8c05b1c90ecb3d870202725c950483665c5718a4c87ca618929473fb9d35cb0adcf5
ae904500bede8044b55322d2bcb25f5c1658fb3c81e34203de37a8dcd7f260a1d8ca
d376aa6836

A.5. pedersen_commitment

Relation = pedersen_commitment
Ciphersuite = sigma-proofs_Shake128_P256
SessionId = 706564657273656e5f636f6d6d69746d656e74
Statement = 01000000020000000200000000000000000000000100000001000000
036b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c29602
bd6f9ee95eae1bc34fa4c48d08e87bc9c6393ae536b21a055a8773678d323425027f
84d3d29e58788a4a35b331d26a9e03ae70c2d12d40de6efafaba93c8d8306a
Witness = 80e9110d93d39b6dc377f7bee6f864816eb334ea2dc480351cb4bd83f5
951a26ac27e0d760b5bb6b0362c5ec512b9d2284b21340880405cb7ef333e304fa08
d6
Proof = 3d90a3ed5d1b3bc4f70b78e8f4f5dbe3caf4a80b6f1e39b1c38d9f5247fb
63136e20dd1b19df78e97c6244e360b8ff3bc1502674a8b83ddf013dc0f5fabd476f
c7945b191e5d4dc4a529753296bc703a1994bb2dedef715c2f68c6aaa905e9d1
Batchable Proof = 03777ae6d50cca648269f7d2ace923005a66fcecd50bf85e7c
6be26ecadcf5823b01e8106b8c2734cfc8a08c4997e8fa4c35807cd20a8f48c2f93b
0c8f5cbdc1dfd8ab23e89a9368837abbb24879eab608a57470109cbe958567276587
899827fb

A.6. pedersen_commitment_dleq

Relation = pedersen_commitment_dleq
Ciphersuite = sigma-proofs_Shake128_P256
SessionId = 706564657273656e5f636f6d6d69746d656e745f646c6571
Statement = 02000000020000000200000000000000000000000100000001000000
05000000020000000000000003000000010000000400000002bd6f9ee95eae1bc34f
a4c48d08e87bc9c6393ae536b21a055a8773678d323425038246b3bd00714116c8e2
19f8edc58ca32e0325f5772ee139d734b039a1a7ba8202209d335481e1958744a21e
31e5864e74c1a6b8961017b33b58907dfcd454f5d903c9c89ace9fc570dfbda4eb1f
9d697fff9b16ee5945cc028aae70230fd1df207d026b12d00779cbdf1ada5906a03e
9f0a53b8bf1ab45f705ee249b916b32e35a00f03b5ad7c6c7c458febeaa58d5bd064
03813422f76f97cdaaad7a3fb5d5973d528f
Witness = 9c4207ebad42d717aa783c9e181fc0186df5d912ce82c37943ae865fdb
51c1ff4144dc0567a4251d42cbfbdccd8945f58173126113869acf0654f63fba199e
a3
Proof = 21c0c75d59b34cdab6feddb419de608e995628ffff46394b6ac9d4d87783
6e7708751cab1ba2829d42cabe2e5c38c82f9c547a20b2b260486834e213a07365be
925d63d533de16c0523865d993947c17653bbb43aaafb8a2908d05cbd29a1d47
Batchable Proof = 03f986008ec0a0afe4e868b8b776fcc6faec09d632d1eb8a10
20b54050d8319f06034a2ea605bd9d70a6f6aa6b57436f574ba98cdcbb6422cd7555
6ec20df8a1e9acb8ce213de8c96ca52572ff4f92ba4fa9c592477687e27a9ba56cfb
32dcac5cf7461dd5002fbabb6f8a6ec3de8415974160d04329bc12301eb35d732eb5
ae29f9

A.7. bbs_blind_commitment_computation

Relation = bbs_blind_commitment_computation
Ciphersuite = sigma-proofs_Shake128_P256
SessionId = 6262735f626c696e645f636f6d6d69746d656e745f636f6d70757461
74696f6e
Statement = 01000000040000000400000000000000000000000100000001000000
0200000002000000030000000300000002bd6f9ee95eae1bc34fa4c48d08e87bc9c6
393ae536b21a055a8773678d323425038246b3bd00714116c8e219f8edc58ca32e03
25f5772ee139d734b039a1a7ba8203c9c89ace9fc570dfbda4eb1f9d697fff9b16ee
5945cc028aae70230fd1df207d026b12d00779cbdf1ada5906a03e9f0a53b8bf1ab4
5f705ee249b916b32e35a00f035048dd622ecebf6c31077ff12921ecf3cb9fe45b90
c682ffe6e528725ce174f4
Witness = 0f3c983cfeaac7eb522895bae245ce5b91c2e33f950bed7c216bfc05cb
bf93e69c4207ebad42d717aa783c9e181fc0186df5d912ce82c37943ae865fdb51c1
ff4144dc0567a4251d42cbfbdccd8945f58173126113869acf0654f63fba199ea3ba
7883061efe0e0b2dee84d3636867f5ee0f44bb55da18bc86b3dfee2af2020e
Proof = 4aa499c1b6f2f13fc38305021e211b2a8d7c26e3d8736ab6e0a0bfdccee0
4b762c43456ae18d7d32556467e55f58b4fa4cb370e4fd94b13b1d074e01d04ec8f1
7110258a443bfcb519605860d6b8810ed47294f333c48a710924e5e4f807ef47a694
1fee8eeb559c7269b6f11734dd7c9f281fc64759a8d5e31555ab56cddfe258b542eb
aedef80fb8973c1cba2b286c6814f3b17cd15653afb56bcc5a5ee36f
Batchable Proof = 0353f1b573b9668ec86796bc59f37ae422252faa19a4b29eeb
9fdaf24255ebaf99aa0b343f2f58f1b6940fafcd99128421f182c8cba6b60173baf2
2cda93f344a4024b91591472dd0bf71c5b80703e73c0624a178069e7ca2ab54b6ae4
ea39241cc1dec9aa31676d8474ca67dcddf67408d9fb7089f69c787a763c7cbdf6ec
1ea4c8f233455889561ed42093be7c5d5f2c51367823af6e5f09e7be66164c30154e

A.8. sigma-proofs(BLS12-381, SHAKE128)

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

A.9. discrete_logarithm

Relation = discrete_logarithm
Ciphersuite = sigma-proofs_Shake128_BLS12381
SessionId = 64697363726574655f6c6f6761726974686d
Statement = 010000000100000001000000000000000000000097f1d3a73197d794
2695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3a
f00adb22c6bbb2fa861063d133109d361486d5105a7e9c676a7831f8707b940cde05
514a18ca60f09d5d253c4b7b1b4b349d8a8c108f
Witness = 14de3306fc5f57e5d9e2e89caaf03a261f668b621093c17da407ee7462
43a421
Proof = 6a9cfa9ea0f40879271e3e317e72248504db5c1bdc062cb9c8fb7a4790f2
a252681631a3e6c665add0a97f079060935ae7651e10f43eda51f36bffb717134951
Batchable Proof = 936241c2ed1da3b385294db75a499e96ffc71b5014a01db263
b993b718a901259f0d97700216c683fd97edb99ecac9e8405651a5f1be6c7ad9a048
8b6520da73a6b04e621508d6fb0fc8a6b3c191c24c

A.10. dleq

Relation = dleq
Ciphersuite = sigma-proofs_Shake128_BLS12381
SessionId = 646c6571
Statement = 02000000010000000100000000000000000000000300000001000000
000000000200000097f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e
3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bbb24cff92be94ce84df8a18bd
8f9c7e2f271bc9091002ff1196a7281283c87b563d9c3cf55173d30f57cac60e7683
0fe4b2fa861063d133109d361486d5105a7e9c676a7831f8707b940cde05514a18ca
60f09d5d253c4b7b1b4b349d8a8c108f81eba50cd26d9e72c32af73e57f9f201b76b
6c19061210eba4018d488830508c15d8862e09d24b19008a91c85d0aab2b
Witness = 054b258f4428690087c110387c5a27b3036847c4eb3021dacf604bbb69
7ec4a6
Proof = 36e59df2992caf551eafa38504a5ba02c470c5a1c13d66a5dbe3f7ffc606
79e76bdff19c20d305609252ebe75f3ac59ac9f46421a7cdaf3bd4a9f76e1d877ca0
Batchable Proof = 936241c2ed1da3b385294db75a499e96ffc71b5014a01db263
b993b718a901259f0d97700216c683fd97edb99ecac9e8b6ed99afa6262bb161ee5e
e7a9c1ac4d63adb6aa983af069ee60b1c48927f6e4a5609d4a982f35c9cf69aecc3d
8f93996dc046998c44c1b66b4413665cbfabe772d380ea44df8b97416e07a09e284e
bc

A.11. pedersen_commitment

Relation = pedersen_commitment
Ciphersuite = sigma-proofs_Shake128_BLS12381
SessionId = 706564657273656e5f636f6d6d69746d656e74
Statement = 01000000020000000200000000000000000000000100000001000000
97f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55
e83ff97a1aeffb3af00adb22c6bbb2fa861063d133109d361486d5105a7e9c676a78
31f8707b940cde05514a18ca60f09d5d253c4b7b1b4b349d8a8c108fb40c3e47aae4
5fa96715c58ddf5715c96c0765d7fdb919dc08c9fc0b3649b5054d71706a5bf1980d
f11e5e70390d20d6
Witness = 054b258f4428690087c110387c5a27b3036847c4eb3021dacf604bbb69
7ec4a628b20b5b8bbc7e534ac549882000877da9b475cc0725b403998a139355ab8a
f6
Proof = 3d08972cab89f982fecbf31ed6d2c9199eb0bf4043b4548147f5fcc88d42
e2ed02b3b7e395c543ef2b9bb843bf864902a858feff424c3500b721498e4c461329
725a68f2b70225cc28aa6b029aac508a904c156dc2a95343b6ea012e80164b6e
Batchable Proof = b277abf8285d0c764f8b57cb326399bf9bed4224d698832dd4
20d63080db3cea5d8e4b5fbd2417c88b76969b344c9afe41836f36b59b9a911d6f99
26e6be362279a1948c1f281a07c6b9b27b7647697a341108473284d4b6ff4c097768
e8fd92f4c906f8d1167f068a048998abb58954

A.12. pedersen_commitment_dleq

Relation = pedersen_commitment_dleq
Ciphersuite = sigma-proofs_Shake128_BLS12381
SessionId = 706564657273656e5f636f6d6d69746d656e745f646c6571
Statement = 02000000020000000200000000000000000000000100000001000000
050000000200000000000000030000000100000004000000b2fa861063d133109d36
1486d5105a7e9c676a7831f8707b940cde05514a18ca60f09d5d253c4b7b1b4b349d
8a8c108fb24cff92be94ce84df8a18bd8f9c7e2f271bc9091002ff1196a7281283c8
7b563d9c3cf55173d30f57cac60e76830fe498be754a4ad6f66dedcfca7e23f5d47f
4f913da328c25dd4506ac0ae3744115b2b3fca2dd3ef851faa74a4fdd82e947c8997
75bf2f7af10a80c0ad6cd35a2646bc2e9c8be292111073cc781d483e7eee325aba7b
e547ce566b071e5d463aca55b003bc4efdafcb4717d5b0ea62db9380edb54c6dd905
788216b21d4f3341dd82a038fe2d59bfca0ec4b8cfa801a4d76db289a73c5a7406c2
7d17f398edad6729f29ba1323b978b00e90abf824e0134e0f113ca9d04375df36caf
d59d51aa5437
Witness = 33c24a45ec7c5d15db45372751862cbd11487a6acc8599e1d4b09d85a5
32262f1baffc5c29eef8881343a7d0950a1ee46a39605e63f7cebf0fb2420385527f
53
Proof = 65e43e13e05bc5189f0ec77fc5775e6a68e36ffde0ddb17f5c528723f14b
b90a50ee69f51862aa494d1eb61a4de75ea8d43fcc0d890e573d4ab0d7d4e248ca59
526376837edc26da714918545b63ad8c6574e02ed4cf1b1825428f22528542b7
Batchable Proof = 81c544e0ef1984f63a1b0b51f112d9f51af2bf76d1b5ecf32e
edaebab1ee9a97d63817756a61c3389331c1cf17ac7eb8823c7e780bad136e99c825
a0992b6d34e2b0c79ea945af382a5cde5596959df8127f58f39a4f1050a49aa94945
bb0c3e55b6e821c6973468c9c385156389b46d5ee4635c014efd3e1fce1c0e9a0b2b
31530bea4cd4492cf694bb369d715ff44ca2fb0bcd5bf116794001b51dfe0aba49

A.13. bbs_blind_commitment_computation

Relation = bbs_blind_commitment_computation
Ciphersuite = sigma-proofs_Shake128_BLS12381
SessionId = 6262735f626c696e645f636f6d6d69746d656e745f636f6d70757461
74696f6e
Statement = 01000000040000000400000000000000000000000100000001000000
02000000020000000300000003000000b2fa861063d133109d361486d5105a7e9c67
6a7831f8707b940cde05514a18ca60f09d5d253c4b7b1b4b349d8a8c108fb24cff92
be94ce84df8a18bd8f9c7e2f271bc9091002ff1196a7281283c87b563d9c3cf55173
d30f57cac60e76830fe4899775bf2f7af10a80c0ad6cd35a2646bc2e9c8be2921110
73cc781d483e7eee325aba7be547ce566b071e5d463aca55b003bc4efdafcb4717d5
b0ea62db9380edb54c6dd905788216b21d4f3341dd82a038fe2d59bfca0ec4b8cfa8
01a4d76d8789e9517c935cc3f345bec16dfbdf0777273de701583f2098c3020a10ca
1f3f93c07f45fd64bb932423317e5a1e74e8
Witness = 479b2e7e7b15a1d4118e1c887fe73fc4c7938cdd7d88422302b2c61794
6b4bb633c24a45ec7c5d15db45372751862cbd11487a6acc8599e1d4b09d85a53226
2f1baffc5c29eef8881343a7d0950a1ee46a39605e63f7cebf0fb2420385527f533b
7e5ed38fe5ce6cf2dd67fb59e7739981a80aa62b7bc1abf6880346db4f28de
Proof = 228d4317faa63188b8084b6beda27eb9db5937f73dcc78d93309bd2994b9
5ab61c716b18ba68a08f8da725ae20979dc39b20f0126bdfae186fbb6863889cdcca
1d8f6ff520ac2af53f0f010415106dfdd009d2a2a9d5e5021247d3ba4c58a2f965c4
56c195c9e150823ea30c2a2f8901ca491211c9bd43a3625bb60f714a0b7c661c133d
b5cbdd746483b7bf6f53bd5e40881d17cbd6b71db3d098dc7ee0393d
Batchable Proof = b123897f9ff891e048b0c83eb3d3dc45b8e1d4c5a29941b3a4
727990ee1dd1028596f66fb5ef2934a7e6e083f0dd15e925abd00ff5a910fe95bbd7
bde3a56e6ef6bd48ed0c617ddeaa0c311dde982860318216c6fd6d1938c13260cc4d
0fd34cf6a78c0fecbb248a5eb2e9712e82def362c8dda9836fd3947b33185d873bd9
ef8965a58547ee20aa7622d1dd5583bbf116fc49fb5dc10338d4704c0c8738067024
8b13ed88d657a14ec27d9f77137f01

Authors' Addresses

Michele Orrù
CNRS
Cathie Yun
Apple, Inc.