]> CNRS

m@orru.net

Apple, Inc.

cathieyun@gmail.com

IRTF Crypto Forum zero knowledge hash This document describes the Fiat-Shamir transformation, which allows making a public-coin protocol non-interactive by means of a cryptographic hash function. It specifies how the hash function is employed, how prover messages are encoded as hash-function input, and how verifier messages are decoded from the hash function's output, as well as the serialization and deserialization of the non-interactive argument string. 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 turns a public-coin interactive argument into a non-interactive argument by replacing the verifier's random messages with the output of a cryptographic hash function. It is notoriously easy to get the Fiat-Shamir transformation wrong, introducing critical security bugs , , , . This specification provides a non-interactive argument (NARG) prover and verifier, together with security requirements for each component they rely on:

• a duplex sponge, prescribing how to interact with the cryptographic hash function ();
• a set of codecs, describing how each prover and verifier message talks to the duplex sponge ();
• a serialization and deserialization procedure for the NARG string produced by the prover ().

This transformation is also well-suited for recursive proving, since the in-circuit cost of recomputing the Fiat-Shamir challenges is low. It is compatible with arithmetization-friendly hash functions (e.g. Poseidon2 ) that operate natively on field elements. See for the general construction. Other types of non-interactive transformations (with and without random oracles) are possible, but outside the scope of this specification.

Non-interactive prover for the Fiat-Shamir transformation | Init | | | +------+ | | | | | v | | +------------+ +--------+ | | instance ---------------------------->| encode[0] |-->| Absorb | | | +-------------------+ +------------+ +--------+ | | | Interactive Prover| | | | |(instance, witness)| | | | | | prover_msg[1] v | | | | +------------+ +--------+ | | | +---------------->| encode[1] |-->| Absorb | | | | | +------------+ +--------+ | | | | | | | | | verifier_msg[1] v | | | | +------------+ +---------+ | | | |<----------------| decode[1] |<--| Squeeze | | | | | +------------+ +---------+ | | | | | | | | | prover_msg[2] v | | | | +------------+ +--------+ | | | +---------------->| encode[2] |-->| Absorb | | | | | +------------+ +--------+ | | | | | | | | | verifier_msg[2] v | | | | +------------+ +---------+ | | | |<----------------| decode[2] |<--| Squeeze | | | | | +------------+ +---------+ | | | | . . | | | | . . | | | | . . | | | | | | | | | prover_msg[k-1] v | | | | +------------+ +--------+ | | | +---------------->| encode[k-1]|-->| Absorb | | | | | +------------+ +--------+ | | | | | | | | | verifier_msg[k-1] v | | | | +------------+ +---------+ | | | |<----------------| decode[k-1]|<--| Squeeze | | | | | +------------+ +---------+ | | | | prover_msg[k] | | | +----------------> | | +-------------------+ | | | | narg_string := serialize(prover_msg[..]) | +--------------------------------------------------------------------+ ]]>

Non-interactive verifier for the Fiat-Shamir transformation | Init | | | +------+ | | | | | v | | +-----------+ +--------+ | | instance --->| encode[0] |--------->| Absorb | | | +-----------+ +--------+ | | | | | v | |prover_msg[1] +-----------+ +--------+ | |------------->| encode[1] |--------->| Absorb | | | +-----------+ +--------+ | | | | | v | | verifier_msg[1] +-----------+ +---------+ | | <---------------| decode[1] |<------| Squeeze | | | +-----------+ +---------+ | | | | | v | |prover_msg[2] +-----------+ +--------+ | |------------->| encode[2] |--------->| Absorb | | | +-----------+ +--------+ | | | | | v | | verifier_msg[2] +-----------+ +---------+ | | <---------------| decode[2] |<------| Squeeze | | | +-----------+ +---------+ | | . . | | . . | | . . | |prover_msg[k] +-----------+ +--------+ | |-------------->| encode[k] |------>| Absorb | | | +-----------+ +--------+ | | | | | v | | verifier_msg[k] +-----------+ +---------+ | | <-----------------| decode[k] |<--| Squeeze | | | +-----------+ +---------+ | | | | 3. Run the interactive verifier | | | | +------------------------------------------------+ | | | Interactive Verifier | | | | (instance, prover_msg[..], verifier_msg[..]) | | | +------------------------------------------------+ | +-------------------------------------------------------------------+ ]]>

Note that the prover does not need to compute the last verifier message verifier_msg[k]. The security guarantees provided by this transformation are described in . The non-interactive verifier SHOULD be deterministic.

Terminology and conventions in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The algorithms and procedures in this document are specified using Python-like pseudocode. Functions may depend on external parameters, such as the suite (); once selected, these parameters are treated as constants.

Bytes and integers A byte is an 8-bit unsigned integer (an octet), and a byte string is a finite sequence of bytes. An N-byte string is a byte string of length N. The empty byte string is written ""; x || y is the concatenation of the byte strings x and y. len(x) denotes the length in bytes of the byte string x. zeros(N) denotes the N-byte string of zero bytes. Byte strings are indexed from zero. For integers 0 <= i <= j <= len(x), x[i : j] denotes the (j - i)-byte substring of x consisting of the bytes at positions i, i+1, ..., j-1. In particular, x[0 : N] is the first N bytes of x, x[i : i] is the empty byte string "", and x[0 : len(x)] is x itself. A byte string x is a prefix of a byte string y if y == x || z for some byte string z (even empty). An encoding is prefix-free if, for any two distinct values, the encoding of one is never a prefix of the encoding of the other. A simple prefix-free encoding of a byte string b is LE(len(b), 4) || b as described in . LE(n, w) and LE2IP(x) are the integer/byte-string conversion primitives used throughout this document. LE(n, w) converts a non-negative integer n into a w-byte, little-endian byte string, and fails if n >= 256^w. LE2IP(x) converts a byte string x into a non-negative integer using the little-endian byte order. The set of integers between 0 and N-1 is denoted [0, N). For a modulus M, Ns denotes the smallest integer such that 256^Ns >= M.

Duplex sponge interface The Fiat-Shamir transformation relies on a cryptographic hash function, modeled as a random oracle and accessed through a stateful interface called a duplex sponge (), named after the sponge and duplex constructions. A duplex sponge Absorbs prover messages into an evolving internal state and Squeezes from that state the bytes from which verifier messages are decoded. The state consists of a rate, through which bytes are absorbed and squeezed, and a capacity, which is never read or written directly. Security relies on the size of the capacity and on the properties given in .

Proof systems terminology The session identifier is a 32-byte string identifying the non-interactive argument and the application context (see ). The instance is the public input, and the witness is the prover's private input. The session identifier and the instance are held by both the prover and the verifier, whereas the witness is known only to the prover. For an NP language, the instance is a word, the witness is a proof of its membership in the language, and the non-interactive argument proves that the instance is in the language. This claim is also referred to as the statement. Proof systems might support different statements or express the same language in different ways. A prover message is a message sent by the interactive prover, and a verifier message is a message sent by the interactive verifier (a uniformly random value, sometimes called a challenge). The transcript is the ordered sequence of prover and verifier messages. The transcript does not include the instance or the session identifier. The notation in this document is for an interactive argument with k rounds in which the prover moves first (that is, sends the first message) and the verifier moves last. Other types of interactions can be expressed in the same notation: set the first prover message or final verifier message to "" when the protocol omits that message. All messages in rounds 2, ..., k-1 MUST be non-empty. The NARG string (non-interactive argument string) is the serialized output of the non-interactive prover.

Codec and serialization Prover messages are absorbed into the duplex sponge and serialized into the NARG string. This document keeps the two operations separate. A codec is the pair of maps between messages and the hash function's alphabet (bytes, in this document):

• Encoding converts the instance and each prover message into the bytes absorbed by the duplex sponge ().
• Decoding converts the bytes squeezed from the duplex sponge into an approximately uniform verifier message ().

Serialization is concerned with mapping prover messages to and from the NARG string ():

• Serialization writes the prover messages into the NARG string produced by the non-interactive prover.
• Deserialization reads the prover messages back from the NARG string, and returns an error if the message is invalid.

Codecs and serialization serve different purposes. Codecs must maintain the soundness of the transformation, whereas deserialization keeps the NARG string unambiguous and rejects malformed proofs. In this specification, the encoding of a prover message coincides with its serialization (). specifies the decoding, serialization, and deserialization functions for common types, which satisfy the requirements below.

Encoding Encoding maps MUST satisfy the following requirements:

1. They are prefix-free: the encoding of one value is never a prefix of the encoding of another.
2. They have an efficiently computable left inverse, which the knowledge extractor uses (). For the encodings of this document, deserialization is that inverse.

Decoding Decoding maps MUST satisfy the following requirements:

1. They are infallible.
2. They are distribution-preserving: on a uniformly random input, the output is statistically close to uniformly distributed over the verifier message type. The bias adds to the soundness error of the resulting non-interactive argument. An alternative to the decodings of MUST have bias at most the soundness error of the interactive argument, so that the non-interactive soundness error stays within a small multiple of the interactive one.

Decoding maps SHOULD be amenable to straight-line implementations. Unlike deserialization, decoding need not be injective. Each verifier message type fixes the number of bytes to squeeze. Decoding a fixed-length byte string is the identity (), and decoding an integer modulo M reads Ns + 16 squeezed bytes as a little-endian integer and reduces it modulo M ().

Serialization and deserialization Serialization and deserialization MUST jointly satisfy the following requirements:

1. Deserialization inverts serialization and rejects any byte string that is not the serialization of a valid value, enforcing every validity condition of the value's type: for example, an elliptic-curve point lies in the prime-order subgroup, and an integer or field element is in its canonical range.
2. Each value has a unique serialization. Accepting more than one serialization of a value makes proofs malleable.
3. Length indicators and counts read from the NARG string are untrusted and are checked before being used for indexing, allocation, or arithmetic.
4. If any trailing bytes remain in the input after deserializing the last prover message, verification fails. Accepting trailing bytes makes proofs malleable.

Serialization of fixed-length byte strings is the identity; serialization of an integer modulo M writes its canonical representative as an Ns-byte little-endian string. See for the normative serialization requirements for common types.

Duplex sponge

Interface Prover and verifier messages are handled via three operations:

• Init(session_id) -> state: create a new duplex sponge state, seeded by the 32-byte string session_id.
• state.Absorb(x): absorb x into the state.
• state.Squeeze(n) -> buf: produce n elements (bytes, in this document) from the state.

In the duplex sponge interface, messages can be absorbed incrementally, and Absorb inserts no separators: state.Absorb(x) followed by state.Absorb(y) (with no state.Squeeze in between) is equivalent to state.Absorb(x || y). Each state.Squeeze(n) is uniformly distributed, and consecutive state.Squeeze calls continue one output stream. The security requirements for the 32-byte string session_id are given in ; its role in composability and reuse is discussed in .

XOF duplex sponge This section implements the duplex sponge from an eXtendable-Output Function (XOF). XOF(M, L) maps a byte string M to an L-byte string. The suite () fixes the XOF, its rate R (the block size in bytes at which the XOF absorbs input, which MUST satisfy R >= 32), and its security properties (). The state is a pair (M, offset): M is the byte string absorbed so far, and offset is the number of output bytes already squeezed since M last changed. Each verifier message is obtained by decoding the XOF output computed over the session identifier, the encoded instance, and the encoded prover messages up to and including the current round. That is, the i-th verifier message (for 1 <= i <= k) of byte length len_i is computed as:

Init Seed the state by absorbing the session identifier, padded with zeros to fill the rate (the remaining R - 32 bytes).

Absorb Feed a byte string x into the state. Absorbing the empty string leaves the state unchanged.

Squeeze Returns the next n bytes of the XOF output stream computed over the absorbed input. Above, Squeeze re-hashes M on every call, at a cost quadratic in the number of rounds. Implementations SHOULD instead keep an incremental XOF context that absorbs M as it grows, and squeeze from a reader over a copy of that context, continuing from offset. Both approaches produce the same output.

Initialization Before any prover message is processed, both parties start the duplex sponge with the session identifier (), and then the instance (). Session identifier and instance are not part of the NARG string.

Session identifiers The procedure DeriveSessionID below is the RECOMMENDED way to obtain a session identifier from a human-meaningful variable-length tag. The tag is a byte string whose encoding as a sequence of bytes MUST be specified unambiguously, so that every implementation reproduces identical bytes. It is RECOMMENDED that the tag be a US-ASCII string, without byte-order mark at the beginning, nor 0x00 byte termination. When the tag is composed of several fields, those fields MUST be combined unambiguously, so that no two distinct tuples of field values yield the same byte string. Fixed-width fields or a delimiter that cannot occur within a field suffice. For example, plain concatenation maps both ("SV1", "22") and ("SV12", "2") to SV122, so the two tuples would share a session identifier. The tag has the following security requirements:

1. the tag MUST uniquely identify the non-interactive argument used, including the interactive argument, the types of prover and verifier messages, the hash suite, and the language associated with the interactive argument.
2. the tag MUST uniquely identify the codecs used: the order and types of encodings and decodings at each round. For example, implementations that sample verifier messages differently must have different session identifiers.
3. the tag MUST identify the application context in which the non-interactive argument is used, so that a NARG string produced for one application cannot be accepted in another. A namespace string under the application's control is sufficient, such as the URL https://example.com/login/v2. Freshness information, such as an epoch number or timestamp, MAY additionally be included when the application requires proofs not to be replayed within its own context (see ).
4. the tag SHOULD begin with a fixed identification string that is unique to the application.
5. the tag SHOULD include a version number.

An application MAY set the 32-byte session_id by its own means; it MUST then satisfy the same requirements. Above, DS denotes the duplex sponge in use (), instantiated with one of the suites of . The 32-byte string "irtf-cfrg-fiat-shamir/session-id" is a domain separator for this derivation. As an example, consider a fictional application named Foo that implements sigma protocols over elliptic curves for encrypted messages shared during a time epoch tttt. A reasonable choice of tag is: where xx is the two-digit number indicating the version, yy is the two-digit number indicating the elliptic-curve ciphersuite, hashID is the hash identifier, and tttt is the epoch number written in decimal US-ASCII digits. As another example, consider a fictional application named Bar that implements an ad-hoc zero-knowledge virtual machine for correct execution of circuits. A reasonable choice of tag is: where {cc} is the commit hash of the associated version of the cryptographic specification of the protocol. Yet another reasonable choice for the tag is to append a description of the interactive argument together with the length of each prover and verifier message, after the version string. For instance: where xx is the two-digit version number, hashID is the hash identifier, and ff is the two-digit identifier of the finite field over which the proof is computed. The suffix A2round-messageS1challenge describes one sumcheck round where the prover absorbs (A) two field elements round-message, and the verifier squeezes (S) one field element challenge. This is similar to the SAFE API IO pattern.

Instance The prover and verifier MUST absorb encode[0](instance), where encode[0] is the first encoding map. The encoded instance MUST be non-empty. While the session identifier of the previous section fixes the language, the instance selects one of its members. Like every encoding map, encode[0] must be prefix-free (). Otherwise, a malicious prover may be able to produce valid NARG strings on statements it cannot prove. The encoding map encode[0] SHOULD reuse the serialization functions of . As an example, consider the sumcheck relation for multilinear polynomials in N variables over the field of size p^m. For a polynomial committed using the polynomial commitment scheme COM, the relation consists of:

• instance (S, C): C the commitment, and S the target sum;
• witness (F, r): F is the multilinear polynomial in N variables, and r is the commitment opening information.

such that: A valid instance-encoding function is: where COM.Serialize is the commitment-serialization function of the scheme COM. As another example, consider, in the discrete logarithm setting, the Chaum-Pedersen relation over an additive elliptic curve group with generators G, H (for which the relative discrete logarithm is not known). The relation consists of:

• the instance (C, D), a pair of Pedersen commitments;
• the witness (x, r, s), scalar field elements with x the commitment message and r, s independent random commitment openings,

such that: A valid instance-encoding function is: where enc is the group-element serialization function described in . Omitting public statement data from the transformation, such as N in the first example or the group generators G, H in the second, can compromise the soundness of the non-interactive argument. See .

Non-interactive argument string The NARG string is the concatenation of the serializations of the prover messages (). Serialization and deserialization satisfy the requirements of . Deserialization of the NARG string consists of reading the prover messages: each message is read by consuming, from the front of the input, a byte string whose length is determined by its type and the instance. Each deserialization function of returns the deserialized value together with the unread remainder of its input; the remainder is the input to the next read. Verification MUST fail if deserialization of any prover message fails.

Efficiency considerations Init(session_id) (see ) can be precomputed. Implementations can therefore start each prover and verifier execution from a copy of the duplex sponge state, instead of initializing it every time. In the XOF duplex sponge (), the padded session identifier fills exactly one rate block (), saving one invocation of the permutation function per execution. Similarly, DeriveSessionID can be precomputed when the session identifier is derived from a tag. The same observation extends to longer shared prefixes: proofs for the same instance can additionally start from a stored copy of the state obtained after absorbing encode[0](instance). Prefer batch algorithms for codecs and serialization when available. For example, Montgomery’s trick lets point compression share one modular inversion across a batch.

Security considerations

Codecs Decoding guarantees approximately uniform output only for uniformly distributed input. Verifier messages SHOULD therefore be derived from Squeeze output, and never from prover-controlled or non-uniform bytes. An efficiently computable left inverse of the encoding function is required by the knowledge-soundness extractor to recover prover messages from the absorbed bytes . This inverse is used only in the security analysis; neither the prover nor the verifier needs to compute it.

Constant-time requirements In some applications, such as keyed-verification anonymous credentials, the non-interactive verifier builds an instance using the issuer's secret key. The instance, and potentially the prover messages, may contain confidential information. Constant-time implementation of all codec, serialization, and duplex sponge functions is RECOMMENDED to avoid leaking information about these inputs through execution time.

Session identifiers A session identifier names an application context, not an individual proof, and MAY be reused across proofs that share that context. Session identifiers provide domain separation to prevent protocol-confusion attacks and support composability.

Security of the transformation The Fiat-Shamir transformation carries over the soundness and zero-knowledge properties of the interactive argument. The random oracle instantiation MUST be extraction-friendly and simulation-friendly indifferentiable to preserve soundness and zero-knowledge of the transformation. Both properties are stronger than indifferentiability alone . Completeness of the non-interactive argument is preserved: if the instance-witness pair is in the relation, then the resulting non-interactive argument string is valid.

Knowledge soundness If the interactive argument is state-restoration knowledge sound, then so is the non-interactive argument, with a loss quadratic in the number of queries the adversary makes to the random oracle . In particular, valid proofs cannot be generated without the corresponding statement being true (in the random oracle model).

Zero-Knowledge If the interactive argument is honest-verifier zero-knowledge, then the non-interactive argument is zero-knowledge. In particular, the resulting non-interactive argument string does not reveal any information beyond what can be directly inferred from the statement being valid. The additive zero-knowledge loss introduced by the transformation is linear in the number of queries the adversary makes to the random oracle . Zero-knowledge holds only if the prover's randomness is indistinguishable from fresh uniform randomness to any party that does not know the witness. For example, two Schnorr proofs that reuse the same commitment nonce reveal the witness. Prover randomness can be generated using a cryptographically secure random number generator following , or derived using a pseudorandom function with a protocol-specific construction.

Quantum adversaries If the interactive argument is state-restoration sound against quantum adversaries, then the non-interactive argument after the Fiat-Shamir transformation in the random oracle model is also secure against quantum adversaries. The loss introduced by a quantum adversary is polynomial (larger than quadratic) in the number of quantum random-oracle queries.

Instance encoding Incorrect encoding of the instance has historically led to a number of critical security vulnerabilities. These bugs are grouped under the term weak Fiat-Shamir transformation. In these cases, the cryptographic hash function is not provided with the full statement being proven. As an example , a Chaum-Pedersen proof of equality for an instance (G, H, X, Y) proves knowledge of a witness x such that X = x * G and Y = x * H. The prover sends commitments (A, B), obtains a challenge c, and replies with a scalar f. The verifier accepts if the verification equations hold: f * G == A + c * X and f * H == B + c * Y. Suppose the challenge c is derived only by absorbing (A, B) and omitting the instance (G, H, X, Y). A malicious prover can pick A, B, H, and f at random, derive c, and then set X and Y to satisfy the verification equations. Verification passes, yet no single x satisfies both X = x * G and Y = x * H. A false statement has been proven. Other examples are available in . The transformation itself does not validate the instance. The verifier MUST therefore check that the instance is well-formed before use, exactly as it validates prover messages during deserialization (). For example, the verifier checks that each claimed group element lies in the prime-order subgroup and that integers are in their canonical ranges. The prover is not required to validate the instance. However, if the prover is invoked on an instance-witness pair outside the relation, no guarantee is provided on its output. In particular, zero-knowledge may be lost.

Implementation guidance Absorb each prover message in the same function call that writes it to, or reads it from, the NARG string. This keeps hashing and serialization synchronized and helps prevent omitted or reordered messages, which have caused implementation vulnerabilities . Prefer the byte-level interface described in this document over proof data structures whose fields are randomly addressable. The NARG string is untrusted input (). For example, in the 4-byte length prefix read by LE2IP in DeserializeVarLenString is attacker-controlled, and can be as large as 2^32 - 1, so computing 4 + N can overflow 32-bit integers. As another example, a crafted length indicator can make verification checks trivial, or exhaust memory on deserialization before any cryptographic check runs . Negative testing helps check that invalid proofs are rejected. For example, tamper with a valid NARG string by flipping bits, by appending or prepending bytes, or by replacing each prover message in turn with a different value.

Suites The suites defined by this document, and the identifiers used by the test vectors, are: Duplex sponge suites

Identifier	XOF(M, L)	R	Alphabet
SHAKE128	SHAKE128(M, 8 * L)	168	bytes
TurboSHAKE128	TurboSHAKE128(M, 0x1F, L)	168	bytes

SHAKE128 In the SHA-3 family, two XOFs, SHAKE128 and SHAKE256, are defined over the Keccak-f permutation; SHAKE(M, n) outputs an n-bit string. The corresponding collision and second-preimage-resistance for SHAKE128 are min(n/2,128) and min(n,128) bits, respectively (see Appendix A.1 of ). This instantiation targets 128-bit security. The SHAKE128 state is a 200-byte (1600-bit) string, with a capacity of 32 bytes (256 bits).

TurboSHAKE128 TurboSHAKE128 is an XOF built on Keccak-p[1600, 12], the Keccak-f[1600] permutation reduced to its last 12 rounds. Its state is a 200-byte (1600-bit) string, with a capacity of 32 bytes (256 bits). The corresponding collision and second-preimage-resistance are min(n/2,128) and min(n,128) bits for an n-bit output string, respectively. This instantiation targets 128-bit security. The domain-separation byte is fixed to its default value D = 0x1F.

IANA Considerations This document has no IANA actions.

Acknowledgments The authors thank Thomas Pornin, Vishruti Ganesh, Brent Zundel, Hart Montgomery, Opal Wright, Giap Vu, David Wong, Théophile Wallez, and Thomas Coratger for their reviews and contributions to this specification.

References Normative References n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256. All four functions provide efficient and secure hashing primitives, and the last two are able to exploit the parallelism of the implementation in a scalable way. This document is a product of the Crypto Forum Research Group. It builds up on the definitions of the permutations and of the sponge construction in NIST FIPS 202 and is meant to serve as a stable reference and an implementation guide. Informative References National Institute of Standards and Technology (NIST) Trail of Bits Solana Foundation Consensys Consensys Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. GMO CONNECT Inc. GMO CONNECT Inc. Carnegie Mellon University Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and they can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security; however, its security level is estimated at approximately 100 bits due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and consider them at the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. This memo also specifies the serialization and deserialization of the points and scalars that protocols exchange, restating a format that is already in widespread use, and states which of the remaining decisions belong to the calling protocol. 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.

Codecs and serialization This appendix specifies the normative decoding, serialization, and deserialization functions for common types.

Decoding

Byte strings The decoding function for fixed-length byte strings is the identity.

Unsigned integers To sample an approximately uniform element modulo M, squeeze Ns + 16 bytes, interpret them as a little-endian non-negative integer via LE2IP, and reduce modulo M. The 16 extra bytes bound the statistical distance between the reduced value and the uniform distribution over [0, M) to 2^-128. More generally, sampling n extra bytes has bias at most 2^-8n. In three cases this approach is inefficient:

• if M is a power of two, since the decoding bias is always 0;
• if M is only slightly below a power of 256 (for example, the secp256k1 scalar field order) where squeezing just Ns bytes and reducing with a single conditional subtraction already has bias of approximately 2^-128;
• if the soundness error of the interactive argument is much larger than the bias introduced, for example a protocol with 30-bit challenges does not require such a big modular reduction.

In such cases, applications MAY use an alternative decoding function that meets the requirements of . See .

Field elements A field element of a field of order p^m is decoded coordinate by coordinate, via DecodeUint (), starting from the least-significant. This consumes m * (Ns + 16) bytes. A prime field is the case m = 1, where DecodeField is DecodeUint, and applies, including its alternatives. For m > 1, decoding relies on 16 * m additional randomness bytes. Applications with big-integer arithmetic available MAY use a more randomness-efficient decoding algorithm, by instead sampling Nm + 16 bytes, where Nm is the smallest integer with 256^Nm >= p^m, interpreting them as an integer via LE2IP, reducing modulo p^m, and recovering the coordinates (a[0], ..., a[m-1]) as the base-p digits of the result (least-significant digit first), with the same 2^-128 bias bound.

Serialization

Byte strings Serialization of an N-byte string is the identity function. SerializeBytes carries no length information of its own. It MUST NOT be used unless N is fixed by the message's type and the instance, so that prover and verifier agree on N before the NARG string is parsed (see ). On such a fixed-length domain the identity is prefix-free, as required of encodings by . Otherwise, when the length is below 2^32 bytes, a prefix-free serialization is given by

Sequences and tuples A fixed-length array or a tuple is serialized as the concatenation of the serializations of its elements, with no separators.

Unsigned integers An integer modulo M is represented by its unique integer representative in the range [0, M) and serialized via LE.

Field elements This section specifies the default serialization of a finite field of order p^m, where p is the prime characteristic and m >= 1 is the extension degree. Per requirement 2 of , the tag identifies the choice of field serialization. The default is the serialization specified below, which encodes each prime-field coordinate as a fixed-width little-endian integer via SerializeUint (). If the standard the application builds on already fixes a canonical serialization for the field, that serialization SHOULD be pinned in place of the default. A pinned serialization is an encoding map and satisfies . For example, Curve25519 , Ed25519 , ristretto255 serialize field elements as a fixed-width little-endian integer, matching the default. Similarly, in Section 7.1 of , the integer coordinates of lattice vectors are serialized least-significant-byte first. Other standards instead fix a big-endian serialization, such as P-256 and BLS12-381 via I2OSP (). With respect to a fixed basis, a field element is represented by its m coordinates in the prime field, each an integer in [0, p), and serializes to m * Ns bytes, with Ns taken for the modulus p. A prime field is the case m = 1, where SerializeField is SerializeUint.

Elliptic curve group elements A group element is serialized using the group's element-serialization function, into an Ne-byte string, where Ne is fixed by the group. For many prime-order elliptic-curve groups, this is the compressed Elliptic-Curve-Point-to-Octet-String conversion of . This document alters serialization: uncompressed and hybrid encodings are forbidden, so the only accepted initial octets are 0x00, 0x02, and 0x03; the identity is encoded as Ne zero octets instead of 's single 0x00 octet. Restricting the accepted initial octets guarantees unique serialization. Padding the identity element removes branching from the parsing of the NARG string. The ristretto255 and decaf448 encodings of the identity are already fixed-length Ne-byte strings.

Deserialization

Byte strings For an N-byte string whose length is known from the message's type and the instance, deserialization reads N bytes. DeserializeBytes is the inverse of SerializeBytes (). A byte string whose length is not known in advance is deserialized by DeserializeVarLenString, the inverse of SerializeVarLenString ().

Sequences and tuples Deserialize each element in order. Fail if any element fails to deserialize. The number and types of the elements are fixed by the protocol.

Unsigned integers Read the next Ns bytes as a little-endian integer x, and fail if x >= M. This is the inverse of SerializeUint (). = M 4. return (x, input[Ns : len(input)]) ]]>

Field elements A field element of a field of order p^m is deserialized coordinate by coordinate: read m * Ns bytes and deserialize each Ns-byte coordinate as an integer modulo p using the unsigned-integer deserialization above. This is the inverse of SerializeField ().

Elliptic-curve group elements Read the next Ne bytes and convert them to a group element using the group's element-deserialization function.

Example protocol: sumcheck This appendix describes the Fiat-Shamir transformation for the sumcheck protocol. This protocol is not meant for standalone use; it is a toy example where the verifier's final check would still require the evaluation y = f(r[1], ..., r[v]), which is normally obtained via a polynomial commitment scheme opening. The protocol is parameterized by a prime p and a number of variables v. The witness is the table w of the 2^v evaluations of a multilinear polynomial f on the hypercube: entry w[j] is f(j_0, ..., j_{v-1}), where j_0 is the least-significant bit of j. The instance is (v, S): the number of variables and the claimed sum S of all table entries. All field arithmetic below is modulo p. In each round the prover message is the coefficient pair (a0, a1) of the round polynomial g(X) = a0 + a1 * X of the lowest unbound variable: g(0) and g(1) are the even- and odd-indexed half-sums of the table. Each verifier message is one field element, decoded from Ns squeezed bytes as LE2IP(Squeeze(Ns)) mod p. (For the Mersenne31 instantiation below, the bias of the reduction is approximately 2^-31, less than the soundness error of the interactive argument.) After v rounds the single remaining entry w[0] is f(r[1], ..., r[v]), where r[i] is the verifier message of round i. The NARG string is the concatenation of the round messages. The test vectors () instantiate p = 2^31 - 1, v = 4, and the witness w = (1, 2, 4, ..., 2^15), giving S = 65535. They report the NARG string as NargString and f(r[1], ..., r[v]) as FinalEvaluation.

Test Vectors Each test vector in this section is a block of lines of the form Key = Value, with no repeated keys. A value is written inline or on indented lines below its key; wrapped lines are concatenated without a separator. A sequence has one item per line, introduced by - , and an item's continuation lines carry a further two spaces of indentation. Every vector carries Id, a stable name of the form fiat-shamir/<section>/<vector>, and Function, the operation that the remaining keys describe. The suite () is identified with the key Suite. A vector without Suite has the same outcome under every suite. The key ByteOrder marks the vectors exercising a non-default serialization (). A vector carrying Expected is a verifier decision, accept or reject. The prose accompanying each rejected vector states which check fails. Each key has a value of one of the following kinds:

• an integer, written in decimal or in hexadecimal with the prefix 0x;
• a byte string, written in lowercase hexadecimal. The empty byte string is denoted "";
• a name (for Id, Function, Suite, or Expected);
• a sequence of values (one item per line, each introduced by - ), including the duplex sponge operations described in .

A copy of the test vectors below is provided in JSON format as part of this specification's repo.

Duplex sponge Each Operations item is either absorb followed by a byte string, or squeeze followed by a number of bytes. Each vector runs the operations in order after initializing the state with SessionId. Output is the concatenation of all squeezed bytes, written as two hexadecimal characters per byte.

SHAKE128 Squeeze 32 bytes right after initialization. Absorb the byte string hello world, then squeeze 64 bytes. Absorb ab, then c, then squeeze 32 bytes. Absorbs insert no separator, so the output is that of absorbing abc in one call. Absorb abc, squeeze 32 bytes, absorb the empty string, and squeeze 32 more bytes. Absorbing the empty string leaves the state unchanged, so the second squeeze continues the output stream of the first. The 64-byte output begins with the 32-byte output of the previous vector. Interleave non-empty absorbs and squeezes. A non-empty absorb after a squeeze restarts the output stream over all the input absorbed so far. Absorb a 600-byte string, longer than the rate R = 168, then squeeze 600 bytes: Test across the rate boundary: absorb exactly one rate block (R = 168 bytes), then squeeze 167 bytes and 2 bytes. A zero-length squeeze is a no-op. Absorb abc, squeeze 0 bytes, absorb def, and squeeze 32 bytes. The output is that of absorbing abcdef and squeezing 32 bytes.

TurboSHAKE128 Squeeze 32 bytes right after initialization. Absorb the byte string hello world, then squeeze 64 bytes. Absorb ab, then c, then squeeze 32 bytes. Absorbs insert no separator, so the output is that of absorbing abc in one call. Absorb abc, squeeze 32 bytes, absorb the empty string, and squeeze 32 more bytes. Absorbing the empty string leaves the state unchanged, so the second squeeze continues the output stream of the first. The 64-byte output begins with the 32-byte output of the previous vector. Interleave non-empty absorbs and squeezes. A non-empty absorb after a squeeze restarts the output stream over all the input absorbed so far. Absorb a 600-byte string, longer than the rate R = 168, then squeeze 600 bytes: Test across the rate boundary: absorb exactly one rate block (R = 168 bytes), then squeeze 167 bytes and 2 bytes. A zero-length squeeze is a no-op. Absorb abc, squeeze 0 bytes, absorb def, and squeeze 32 bytes. The output is that of absorbing abcdef and squeezing 32 bytes.

Session identifier derivation Derive the session identifier of the application tag interop-test-v00 (). Derive the session identifier of the application tag interop-test-v00 ().

Codecs This section contains vectors for decoding verifier messages (). The encoding of a prover message is its serialization (), covered in . Decoding is infallible and reduces modulo M (): the Ns + 16 = 48-byte little-endian encoding of M itself, the order of the P-256 group, decodes to 0. Deserialization instead rejects non-canonical integers (). Absorb the instance instance, serialized as a variable-length byte string, then squeeze Ns + 16 = 48 bytes and decode them into a scalar of P-256 (). Absorb the instance instance, serialized as a variable-length byte string, then squeeze Ns + 16 = 48 bytes and decode them into a scalar of P-256 ().

Serialization and deserialization This section contains vectors for the serialization and deserialization of prover messages ().

Valid inputs Serialize the byte string proof as a variable-length string: its length in 4 little-endian bytes, then its bytes (). The serialization of the empty byte string as a variable-length string contains only the length prefix. Serialize the integer 0xdeadbeef modulo p = 2^256 - 189 in Ns = 32 little-endian bytes (). Serialize 0xdeadbeef as an element of the scalar field of P-256, whose standard fixes a big-endian serialization (I2OSP, ).

Invalid inputs A payload shorter than the length specified by its prefix is rejected (). The maximal length prefix 2^32 - 1 exceeds the available payload length. The length check must not overflow. An integer modulo p is serialized by its representative in [0, p). The modulus itself is rejected. An integer modulo p = 2^256 - 189 is serialized in exactly Ns = 32 bytes. Deserialization rejects inputs with fewer bytes. Every coordinate of an extension-field element is validated. This degree-2 element is rejected because its second coordinate (2^256 - 1) is non-canonical, even though its first coordinate (p - 1) is canonical.

NARG strings This section contains NARG strings of the sumcheck protocol of , over Mersenne31 (p = 2^31 - 1) with v = 4 variables. Each vector carries the session identifier, the instance (NumVariables and ClaimedSum), and the NARG string. The valid vectors also carry the witness and the evaluation y as FinalEvaluation; the adversarial vectors are rejected before the final check (step 10 of SumcheckVerify), whatever y.

Valid NARG strings The sumcheck protocol of for the witness w = (1, 2, 4, ..., 2^15), with the session identifier derived from the application tag sumcheck. The sumcheck protocol of for the witness w = (1, 2, 4, ..., 2^15), with the session identifier derived from the application tag sumcheck.

Adversarial vectors The coefficient a0 of the first prover message is serialized as p + a0, a non-canonical representative. Deserialization rejects it (step 4 of SumcheckVerify), before the first squeeze. The NARG string carries one trailing zero byte (step 9). The NARG string carries one trailing zero byte (step 9).