]> CNRS

m@orru.net

IRTF Crypto Forum zero knowledge hash 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 hash object that provides a duplex sponge interface. 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 sponge's internal hash state, while the squeeze operation produces variable-length, unpredictable outputs. This interface can be instantiated with various hash functions based on permutation or compression functions. This specification also defines codecs to securely map elements from the prover into the duplex sponge domain, and from the duplex sponge domain into verifier messages. 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 The Fiat-Shamir transformation is a technique that uses a hash function to convert a public-coin interactive protocol between a prover and a verifier into a corresponding non-interactive protocol. It depends on:

• An initialization vector (IV) uniquely identifying the protocol, the session, and the statement being proven.
• An interactive protocol supporting a family of statements to be proven.
• A hash function implementing the duplex sponge interface, capable of absorbing inputs incrementally and squeezing variable-length unpredictable messages.
• A codec, which securely remaps prover elements into the base alphabet, and outputs of the duplex sponge into verifier messages (preserving the distribution).

The Duplex Sponge Interface The duplex sponge interface defines the space (the Unit) where the hash function operates in, plus a function for absorbing and squeezing prover messages. It provides the following interface. DuplexSponge def absorb(self, x: list[Unit]) def squeeze(self, length: int) -> list[Unit] ]]> Where:

• init(iv: bytes) -> DuplexSponge denotes the initialization function. This function takes as input a 64-byte initialization vector iv and initializes the state of the duplex sponge.
• absorb(self, values: list[Unit]) denotes the absorb operation of the sponge. This function takes as input a list of Unit elements and mutates the DuplexSponge internal state.
• squeeze(self, length: int) denotes the squeeze operation of the sponge. This function takes as input an integral length and squeezes a list of Unit elements of length length.

The Codec interface A codec is a collection of: - functions that map prover messages into the hash function domain, - functions that map hash outputs into a message output by the verifier in the Sigma protocol In addition, the "init" function initializes the hash state with a session ID and an instance label. For byte-oriented codecs, this is just the concatenation of the two prefixed by their lengths. A codec provides the following interface. hash_state def prover_message(self, hash_state, elements) def verifier_challenge(self, hash_state) -> verifier_challenge ]]> Where:

• init(session_id, instance_label) -> hash_state denotes the initialization function. This function takes as input a session ID and an instance label, and returns the initial hash state.
• prover_message(self, hash_state, elements) -> self denotes the absorb operation of the codec. This function takes as input the hash state, and elements with which to mutate the hash state.
• verifier_challenge(self, hash_state) -> verifier_challenge denotes the squeeze operation of the codec. This function takes as input the hash state to produce an unpredictable verifier challenge verifier_challenge.

The verifier_challenge function must generate a challenge uniformly from the underlying scalar field, from the public inputs given to the verifier. The default way to generate the challenge is by sampling a random (|log_2(p)| + 128)-bit string, parsing it as a big integer, and reducing it modulo the prime order of the group p.

Generation of the Initialization Vector The initialization vector is a 64-byte string that embeds:

• A protocol_id: the unique identifier for the interactive protocol and the associated relation being proven.
• A session_id: the session identifier, for user-provided contextual information about the context where the proof is made (e.g. a URL, or a timestamp).
• An instance_label: the instance identifier for the statement being proven.

It is implemented as follows. This will be expanded in future versions of this specification.

Fiat-Shamir transformation for Sigma Protocols We describe how to construct non-interactive proofs for sigma protocols. The Fiat-Shamir transformation is parametrized by:

• a SigmaProtocol, which specifies an interactive 3-message protocol as defined in ;
• a Codec, which specifies how to absorb prover messages and how to squeeze verifier challenges;
• a DuplexSpongeInterface, which specifies a hash function for computing challenges.

Upon initialization, the protocol receives as input: - session_id, which identifies the session being proven - instance, the sigma protocol instance for proving or verifying Serialization and deserialization of scalars and group elements are defined by the ciphersuite chosen in the Sigma Protocol. In particular, serialize_challenge, deserialize_challenge, serialize_response, and deserialize_response call into the scalar serialize and deserialize functions. Likewise, serialize_commitment and deserialize_commitment call into the group element serialize and deserialize functions.

NISigmaProtocol instances (ciphersuites) We describe noninteractive sigma protocol instances for combinations of protocols (SigmaProtocol), codec (Codec), and hash fuction (DuplexSpongeInterface). Descriptions of codecs and hash functions are in the following sections.

Codec for Schnorr proofs We describe a codec for Schnorr proofs over groups of prime order p where Unit = u8. We describe a codec for the P256 curve.

Duplex Sponge Interfaces

SHAKE128 SHAKE128 is a variable-length hash function based on the Keccak sponge construction . It belongs to the SHA-3 family but offers a flexible output length, and provides 128 bits of security against collision attacks, regardless of the output length requested.

Initialization

SHAKE128 Absorb

SHAKE128 Squeeze

Duplex Sponge A duplex sponge in overwrite mode is based on a permutation function that operates on a state vector. It implements the DuplexSpongeInterface and maintains internal state to support incremental absorption and variable-length output generation.

Initialization This is the constructor for a duplex sponge object. It is initialized with a 64-byte initialization vector.

Absorb The absorb function incorporates data into the duplex sponge state using overwrite mode.

Squeeze The squeeze operation extracts output elements from the sponge state, which are uniformly distributed and can be used as a digest, key stream, or other cryptographic material.

Keccak-f[1600] Implementation Keccak-f is the permutation function underlying . KeccakDuplexSponge instantiates DuplexSponge with Keccak-f[1600], using rate R = 136 bytes and capacity C = 64 bytes.

Codecs registry

Elliptic curves

Notation and Terminology For an elliptic curve, we consider two fields, the coordinate fields, which indicates the base field, the field over which the elliptic curve equation is defined, and the scalar field, over which the scalar operations are performed. The following functions and notation are used throughout the document.

• concat(x0, ..., xN): Concatenation of byte strings.
• bytes_to_int and scalar_to_bytes: Convert a byte string to and from a non-negative integer. bytes_to_int and scalar_to_bytes are implemented as OS2IP and I2OSP as described in , respectively. Note that these functions operate on byte strings in big-endian byte order.
• The function ecpoint_to_bytes converts an elliptic curve point in affine-form into an array string of length ceil(ceil(log2(coordinate_field_order))/ 8) + 1 using int_to_bytes prepended by one byte. This is defined as

Absorb scalars Where the function scalar_to_bytes is defined in

Absorb elements

Squeeze scalars

References Normative References CNRS Apple, Inc. This document describes interactive sigma protocols, a class of secure, general-purpose zero-knowledge proofs of knowledge consisting of three moves: commitment, challenge, and response. Concretely, the protocol allows one to prove knowledge of a secret witness without revealing any information about it. 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. Informative References n.d.

Test Vectors Test vectors will be made available in future versions of this specification. They are currently developed in the proof-of-concept implementation.