]> 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 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. 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 duplex sponge to convert a public-coin interactive protocol between a prover and a verifier into a corresponding non-interactive argument. The term "public-coin" here refers to interactive protocols where all verifier messages are essentially random values sent in the clear. 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 duplex sponge instantiation 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).

Security Considerations The Fiat-Shamir transformation carries over the soundness and witness hiding properties of the interactive proof:

• Completeness: If the statement being proved is true, an honest verifier can be convinced of this fact by an honest prover via the proof.
• Soundness: If the interactive proof is sound, then so is the non-interactive proof. In particular, valid proofs cannot be generated without possession of the corresponding witness.
• Zero-Knowledge: If the interactive proof is honest-verifier zero-knowledge, then so is the non-interactive proof. In particular, the resulting argument string does not reveal any information beyond what can be directly inferred from the statement being valid. This ensures that verifiers gain no knowledge about the witness.

In particular, the Fiat-Shamir transformation of Sigma Protocols is a zero-knowledge and sound argument of knowledge. Note that non-interactive Sigma Protocols do not have deniability, as the non-interactive nature of the protocol implies transferable message authenticity.

The Duplex Sponge Interface The duplex sponge interface defines the space (the Unit) where the duplex sponge operates, 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 duplex 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 duplex 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 Units, - functions that map Units into verifier messages, preserving the uniform distribution A codec provides the following interface. verifier_challenge ]]> Where:

• prover_message(self, state, elements) denotes the absorb operation of the codec. This function takes as input the duplex sponge, and elements with which to mutate the duplex sponge.
• verifier_challenge(self, state) -> verifier_challenge denotes the squeeze operation of the codec. This function takes as input the duplex sponge to produce an unpredictable verifier challenge verifier_challenge.

The verifier_challenge function must generate a challenge from the underlying scalar field that is statistically close to uniform, from the public inputs given to the verifier, as described in .

Initialization of the Duplex Sponge State The duplex sponge state is initialized by sequentially absorbing:

• A protocol_id: the unique identifier for the interactive protocol and the associated relation being proven. This identifier MUST be 64 bytes.
• 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). This identifier is currently generated as 32 zero-bytes concatenated with a 32-byte digest derived using the duplex sponge.
• An instance_label: the instance identifier for the statement being proven.

The session_id is computed as: The protocol instance label is absorbed without an explicit length prefix. Therefore, the encoding used to produce instance_label MUST be prefix-free.

Fiat-Shamir transformation for Sigma Protocols We describe how to construct non-interactive proofs for sigma protocols. The Fiat-Shamir transformation is parameterized 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 duplex sponge for computing challenges.

Upon initialization, the protocol receives as input: - session, 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 duplex sponge (DuplexSpongeInterface). Descriptions of codecs and duplex sponge interfaces 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 extendable-output function based on the Keccak sponge construction . It belongs to the SHA-3 family and is used here to provide a duplex sponge interface.

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.
• OS2IP and I2OSP: Convert a byte string to and from a non-negative integer, as described in . 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

Absorb elements

Decoding random bytes as scalars Given Ns + 16 bytes, it is possible to generate a scalar modulo p that is statistically close to uniform. Interpret the bytes as a big-endian integer, then reduce it modulo p, where p is the order of the group.

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_keccak_duplex_sponge_SHAKE128

test_absorb_empty_before_does_not_break_SHAKE128

test_absorb_empty_after_does_not_break_SHAKE128

test_squeeze_zero_behavior_SHAKE128

test_squeeze_zero_after_behavior_SHAKE128

test_absorb_squeeze_absorb_consistency_SHAKE128

test_associativity_of_absorb_SHAKE128

test_iv_affects_output_SHAKE128

test_multiple_blocks_absorb_squeeze_SHAKE128