]> 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 A duplex sponge operates over an abstract Unit type and 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 32-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 provides the following interface. Codec def prover_message(self, prover_message) def verifier_challenge(self) -> verifier_challenge ]]> Where:

• init(iv: bytes) -> DuplexSponge denotes the initialization function. This function takes as input a 32-byte initialization vector iv and initializes the state of the codec.
• prover_message(self, prover_message) -> self denotes the absorb operation of the codec. This function takes as input a prover message prover_message and mutates the codec's internal state.
• verifier_challenge(self) -> verifier_challenge denotes the squeeze operation of the codec. This function takes no inputs and uses the codec's internal state to produce an unpredictable verifier challenge verifier_challenge.

Generation of the Initialization Vector The initialization vector is a 32-bytes 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 Codec, which specifies how to absorb prover messages and how to squeeze verifier challenges;
• a SigmaProtocol, which specifies an interactive 3-message protocol.

Upon initialization, the protocol receives as input an iv of 32-bytes which uniquely identifies the protocol and the session being proven and (optionally) pre-processes some information about the protocol using the instance.

Codec for Linear maps We describe a codec for Schnorr proofs over groups of prime order p that is intended for duplex sponges where Unit = u8.

Ciphersuites

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