3.1.Prime-Order Group

FROST depends on an abelian group of prime orderp. We represent thisgroup as the objectG that additionally defines helper functions described below. The group operationforG is addition+ with identity elementI. For any elementsA andB of the groupG,A + B = B + A is also a member ofG. Also, for anyA inG, there exists an element-A such thatA + (-A) = (-A) + A = I. For convenience, we use- to denotesubtraction, e.g.,A - B = A + (-B). Integers, taken modulo the group orderp, are called"Scalars"; arithmetic operations on Scalars are implicitly performed modulop. Sincep is prime,Scalars form a finite field. Scalar multiplication is equivalent to the repeatedapplication of the group operation on an elementA with itselfr-1 times, denoted asScalarMult(A, r). We denote the sum, difference, and product of two Scalars using the+,-,and* operators, respectively. (Note that this means+ may refer to group element addition orScalar addition, depending on the type of the operands.) For any elementA,ScalarMult(A, p) = I.We denoteB as a fixed generator of the group. Scalar base multiplication is equivalent to the repeated applicationof the group operation onB with itselfr-1 times, denoted asScalarBaseMult(r). The set ofScalars corresponds toGF(p), which we refer to as the Scalar field. It is assumed thatgroup element addition, negation, and equality comparison can be efficiently computed forarbitrary group elements.¶

This document uses typesElement andScalar to denote elements of the groupG andits set of Scalars, respectively. We denote Scalar(x) as the conversion of integer inputxto the corresponding Scalar value with the same numeric value. For example, Scalar(1) yieldsa Scalar representing the value 1. Moreover, we use the typeNonZeroScalar to denote aScalarvalue that is not equal to zero, i.e., Scalar(0). We denote equality comparison of these typesas== and assignment of values by=. When comparing Scalar values, e.g., for the purposesof sorting lists of Scalar values, the least nonnegative representation modp is used.¶

We now detail a number of member functions that can be invoked onG.¶

Order():

Outputs the order ofG (i.e.,p).¶

Identity():

Outputs the identityElement of the group (i.e.,I).¶

RandomScalar():

Outputs a randomScalar element in GF(p), i.e., a random Scalar in [0, p - 1].¶

ScalarMult(A, k):

Outputs the Scalar multiplication between ElementA and Scalark.¶

ScalarBaseMult(k):

Outputs the Scalar multiplication between Scalark and the group generatorB.¶

SerializeElement(A):

Maps anElementA to a canonical byte arraybuf of fixed lengthNe. Thisfunction raises an error ifA is the identity element of the group.¶

DeserializeElement(buf):

Attempts to map a byte arraybuf to anElementAand fails if the input is not the valid canonical byte representation of an element ofthe group. This function raises an error if deserialization failsor ifA is the identity element of the group; seeSection 6 for group-specificinput validation steps.¶

SerializeScalar(s):

Maps a Scalars to a canonical byte arraybuf of fixed lengthNs.¶

DeserializeScalar(buf):

Attempts to map a byte arraybuf to aScalars.This function raises an error if deserialization fails; seeSection 6 for group-specific input validation steps.¶

3.2.Cryptographic Hash Function

FROST requires the use of a cryptographically secure hash function, generically written as H, which is modeled as a random oracle in security proofs for the protocol (see[FROST20] and[StrongerSec22]). For concrete recommendations on hash functions thatSHOULD be used in practice, seeSection 6. Using H, we introduce distinct domain-separated hashes H1, H2, H3, H4, and H5:¶

• H1, H2, and H3 map arbitrary byte strings to Scalar elements associated with the prime-order group.¶
• H4 and H5 are aliases for H with distinct domain separators.¶

The details of H1, H2, H3, H4, and H5 vary based on the ciphersuite used. SeeSection 6for more details about each.¶

4.1.Nonce Generation

To hedge against a bad random number generator (RNG) that outputs predictable values, nonces aregenerated with thenonce_generate function by combining fresh randomnesswith the secret key as input to a domain-separated hash function builtfrom the ciphersuite hash functionH. This domain-separated hash functionis denoted asH3. This function always samples 32 bytes of fresh randomnessto ensure that the probability of nonce reuse is at most 2^-128as long as no more than 2⁶⁴ signatures are computed by a givensigning participant.¶

Inputs:- secret, a Scalar.Outputs:- nonce, a Scalar.def nonce_generate(secret):  random_bytes = random_bytes(32)  secret_enc = G.SerializeScalar(secret)  return H3(random_bytes || secret_enc)

4.2.Polynomials

This section defines polynomials over Scalars that are used in the main protocol.A polynomial of maximum degree t is represented as a list of t+1 coefficients,where the constant term of the polynomial is in the first position and thehighest-degree coefficient is in the last position. For example, the polynomialx2 + 2x + 3 has degree 2 and is represented as a list of three coefficients[3, 2, 1].A point on the polynomialf is a tuple (x, y), wherey = f(x).¶

The functionderive_interpolating_value derives a value that is used for polynomialinterpolation. It is provided a list of x-coordinates as input, each of whichcannot equal 0.¶

Inputs:- L, the list of x-coordinates, each a NonZeroScalar.- x_i, an x-coordinate contained in L, a NonZeroScalar.Outputs:- value, a Scalar.Errors:- "invalid parameters", if 1) x_i is not in L, or if 2) any  x-coordinate is represented more than once in L.def derive_interpolating_value(L, x_i):  if x_i not in L:    raise "invalid parameters"  for x_j in L:    if count(x_j, L) > 1:      raise "invalid parameters"  numerator = Scalar(1)  denominator = Scalar(1)  for x_j in L:    if x_j == x_i: continue    numerator *= x_j    denominator *= x_j - x_i  value = numerator / denominator  return value

4.3.List Operations

This section describes helper functions that work on lists of values producedduring the FROST protocol. The following function encodes a list of participantcommitments into a byte string for use in the FROST protocol.¶

Inputs:- commitment_list = [(i, hiding_nonce_commitment_i,  binding_nonce_commitment_i), ...], a list of commitments issued by  each participant, where each element in the list indicates a  NonZeroScalar identifier i and two commitment Element values  (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list  MUST be sorted in ascending order by identifier.Outputs:- encoded_group_commitment, the serialized representation of  commitment_list, a byte string.def encode_group_commitment_list(commitment_list):  encoded_group_commitment = nil  for (identifier, hiding_nonce_commitment,       binding_nonce_commitment) in commitment_list:    encoded_commitment = (        G.SerializeScalar(identifier) ||        G.SerializeElement(hiding_nonce_commitment) ||        G.SerializeElement(binding_nonce_commitment))    encoded_group_commitment = (        encoded_group_commitment ||        encoded_commitment)  return encoded_group_commitment

The following function is used to extract identifiers from a commitment list.¶

Inputs:- commitment_list = [(i, hiding_nonce_commitment_i,  binding_nonce_commitment_i), ...], a list of commitments issued by  each participant, where each element in the list indicates a  NonZeroScalar identifier i and two commitment Element values  (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list  MUST be sorted in ascending order by identifier.Outputs:- identifiers, a list of NonZeroScalar values.def participants_from_commitment_list(commitment_list):  identifiers = []  for (identifier, _, _) in commitment_list:    identifiers.append(identifier)  return identifiers

The following function is used to extract a binding factor from a list of binding factors.¶

Inputs:- binding_factor_list = [(i, binding_factor), ...],  a list of binding factors for each participant, where each element  in the list indicates a NonZeroScalar identifier i and Scalar  binding factor.- identifier, participant identifier, a NonZeroScalar.Outputs:- binding_factor, a Scalar.Errors:- "invalid participant", when the designated participant is  not known.def binding_factor_for_participant(binding_factor_list, identifier):  for (i, binding_factor) in binding_factor_list:    if identifier == i:      return binding_factor  raise "invalid participant"

4.4.Binding Factors Computation

This section describes the subroutine for computing binding factors based on the participant commitment list, message to be signed, and group public key.¶

Inputs:- group_public_key, the public key corresponding to the group signing  key, an Element.- commitment_list = [(i, hiding_nonce_commitment_i,  binding_nonce_commitment_i), ...], a list of commitments issued by  each participant, where each element in the list indicates a  NonZeroScalar identifier i and two commitment Element values  (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list  MUST be sorted in ascending order by identifier.- msg, the message to be signed.Outputs:- binding_factor_list, a list of (NonZeroScalar, Scalar) tuples  representing the binding factors.def compute_binding_factors(group_public_key, commitment_list, msg):  group_public_key_enc = G.SerializeElement(group_public_key)  // Hashed to a fixed length.  msg_hash = H4(msg)  // Hashed to a fixed length.  encoded_commitment_hash =      H5(encode_group_commitment_list(commitment_list))  // The encoding of the group public key is a fixed length  // within a ciphersuite.  rho_input_prefix = group_public_key_enc || msg_hash ||   encoded_commitment_hash  binding_factor_list = []  for (identifier, hiding_nonce_commitment,       binding_nonce_commitment) in commitment_list:    rho_input = rho_input_prefix || G.SerializeScalar(identifier)    binding_factor = H1(rho_input)    binding_factor_list.append((identifier, binding_factor))  return binding_factor_list

4.5.Group Commitment Computation

This section describes the subroutine for creating the group commitmentfrom a commitment list.¶

Inputs:- commitment_list = [(i, hiding_nonce_commitment_i,  binding_nonce_commitment_i), ...], a list of commitments issued by  each participant, where each element in the list indicates a  NonZeroScalar identifier i and two commitment Element values  (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list  MUST be sorted in ascending order by identifier.- binding_factor_list = [(i, binding_factor), ...],  a list of (NonZeroScalar, Scalar) tuples representing the binding  factor Scalar for the given identifier.Outputs:- group_commitment, an Element.def compute_group_commitment(commitment_list, binding_factor_list):  group_commitment = G.Identity()  for (identifier, hiding_nonce_commitment,       binding_nonce_commitment) in commitment_list:    binding_factor = binding_factor_for_participant(        binding_factor_list, identifier)    binding_nonce = G.ScalarMult(        binding_nonce_commitment,        binding_factor)    group_commitment = (        group_commitment +        hiding_nonce_commitment +        binding_nonce)  return group_commitment

Note that the performance of this algorithm is definednaively and scales linearly relative to the number of signers. For improvedperformance, the group commitment can be computed using multi-exponentiationtechniques such as Pippinger's algorithm; see[MultExp] for more details.¶

4.6.Signature Challenge Computation

This section describes the subroutine for creating the per-message challenge.¶

Inputs:- group_commitment, the group commitment, an Element.- group_public_key, the public key corresponding to the group signing  key, an Element.- msg, the message to be signed, a byte string.Outputs:- challenge, a Scalar.def compute_challenge(group_commitment, group_public_key, msg):  group_comm_enc = G.SerializeElement(group_commitment)  group_public_key_enc = G.SerializeElement(group_public_key)  challenge_input = group_comm_enc || group_public_key_enc || msg  challenge = H2(challenge_input)  return challenge

5.1.Round One - Commitment

Round one involves each participant generating nonces and their corresponding public commitments.A nonce is a pair of Scalar values, and a commitment is a pair of Element values. Each participant's behavior in this round is described by thecommit function below. Note that this function invokesnonce_generate twice, once for each type of nonce produced. The output of this function is a pair of secret nonces(hiding_nonce, binding_nonce) and their corresponding public commitments(hiding_nonce_commitment, binding_nonce_commitment).¶

Inputs:- sk_i, the secret key share, a Scalar.Outputs:- (nonce, comm), a tuple of nonce and nonce commitment pairs,  where each value in the nonce pair is a Scalar and each value in  the nonce commitment pair is an Element.def commit(sk_i):  hiding_nonce = nonce_generate(sk_i)  binding_nonce = nonce_generate(sk_i)  hiding_nonce_commitment = G.ScalarBaseMult(hiding_nonce)  binding_nonce_commitment = G.ScalarBaseMult(binding_nonce)  nonces = (hiding_nonce, binding_nonce)  comms = (hiding_nonce_commitment, binding_nonce_commitment)  return (nonces, comms)

The outputsnonce andcomm from participantP_i are both stored locally andkept for use in the second round. Thenonce value is secret andMUST NOT be shared, whereasthe public outputcomm is sent to the Coordinator. The nonce values produced by this functionMUST NOT be used in more than one invocation ofsign, and the noncesMUST be generatedfrom a source of secure randomness.¶

5.2.Round Two - Signature Share Generation

In round two, the Coordinator is responsible for sending the message to be signed and choosing the participants that will participate (a number of at least MIN_PARTICIPANTS). Signersadditionally require locally held data, specifically their private key and thenonces corresponding to their commitment issued in round one.¶

The Coordinator begins by sending each participant the message to be signed along with the set of signing commitments for all participants in the participant list. Each participantMUST validate the inputs before processing the Coordinator's request. In particular,the signerMUST validate commitment_list, deserializing each group Element in thelist using DeserializeElement fromSection 3.1. If deserialization fails, the signerMUST abort the protocol. Moreover, each participantMUST ensure thatits identifier and commitments (from the first round) appear in commitment_list.Applications that restrict participants from processing arbitrary inputmessages are also required to perform relevant application-layer inputvalidation checks; seeSection 7.7 for moredetails.¶

Upon receipt and successful input validation, each signer then runs the followingprocedure to produce its own signature share.¶

Inputs:- identifier, identifier i of the participant, a NonZeroScalar.- sk_i, signer secret key share, a Scalar.- group_public_key, public key corresponding to the group signing  key, an Element.- nonce_i, pair of Scalar values (hiding_nonce, binding_nonce)  generated in round one.- msg, the message to be signed, a byte string.- commitment_list = [(i, hiding_nonce_commitment_i,  binding_nonce_commitment_i), ...], a list of commitments issued by  each participant, where each element in the list indicates a  NonZeroScalar identifier i and two commitment Element values  (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list  MUST be sorted in ascending order by identifier.Outputs:- sig_share, a signature share, a Scalar.def sign(identifier, sk_i, group_public_key,         nonce_i, msg, commitment_list):  # Compute the binding factor(s)  binding_factor_list = compute_binding_factors(group_public_key,   commitment_list, msg)  binding_factor = binding_factor_for_participant(      binding_factor_list, identifier)  # Compute the group commitment  group_commitment = compute_group_commitment(      commitment_list, binding_factor_list)  # Compute the interpolating value  participant_list = participants_from_commitment_list(      commitment_list)  lambda_i = derive_interpolating_value(participant_list, identifier)  # Compute the per-message challenge  challenge = compute_challenge(      group_commitment, group_public_key, msg)  # Compute the signature share  (hiding_nonce, binding_nonce) = nonce_i  sig_share = hiding_nonce + (binding_nonce * binding_factor) +      (lambda_i * sk_i * challenge)  return sig_share

The output of this procedure is a signature share. Each participant sendsthese shares back to the Coordinator. Each participantMUST delete the nonce andcorresponding commitment after completingsign andMUST NOT use the nonceas input more than once tosign.¶

Note that thelambda_i value derived during this procedure does not changeacross FROST signing operations for the same signing group. As such, participantscan compute it once and store it for reuse across signing sessions.¶

5.3.Signature Share Aggregation

After participants perform round two and send their signature shares to the Coordinator,the Coordinator aggregates each share to produce a final signature. Before aggregating,the CoordinatorMUST validate each signature share using DeserializeScalar. If validationfails, the CoordinatorMUST abort the protocol, as the resulting signature will be invalid.If all signature shares are valid, the Coordinator aggregates them to produce the finalsignature using the following procedure.¶

Inputs:- commitment_list = [(i, hiding_nonce_commitment_i,  binding_nonce_commitment_i), ...], a list of commitments issued by  each participant, where each element in the list indicates a  NonZeroScalar identifier i and two commitment Element values  (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list  MUST be sorted in ascending order by identifier.- msg, the message to be signed, a byte string.- group_public_key, public key corresponding to the group signing  key, an Element.- sig_shares, a set of signature shares z_i, Scalar values, for each  participant, of length NUM_PARTICIPANTS, where  MIN_PARTICIPANTS <= NUM_PARTICIPANTS <= MAX_PARTICIPANTS.Outputs:- (R, z), a Schnorr signature consisting of an Element R and  Scalar z.def aggregate(commitment_list, msg, group_public_key, sig_shares):  # Compute the binding factors  binding_factor_list = compute_binding_factors(group_public_key,   commitment_list, msg)  # Compute the group commitment  group_commitment = compute_group_commitment(      commitment_list, binding_factor_list)  # Compute aggregated signature  z = Scalar(0)  for z_i in sig_shares:    z = z + z_i  return (group_commitment, z)

The output from the aggregation step is the output signature (R, z). The canonical encodingof this signature is specified inSection 6.¶

The CoordinatorSHOULD verify this signature using the group public key before publishing orreleasing the signature. Signature verification is as specified for the correspondingciphersuite; seeSection 6 for details. The aggregate signature will verify successfullyif all signature shares are valid. Moreover, subsets of valid signature shares will not yielda valid aggregate signature themselves.¶

If the aggregate signature verification fails, the CoordinatorMAY verify each signatureshare individually to identify and act on misbehaving participants. The mechanism for acting ona misbehaving participant is out of scope for this specification; seeSection 5.4 for more informationabout dealing with invalid signatures and misbehaving participants.¶

The function for verifying a signature share, denoted asverify_signature_share, is described below.Recall that the Coordinator is configured with "group info" that containsthe group public keyPK and public keysPK_i for each participant. Thegroup_public_key andPK_i function argumentsMUST come from that previously stored group info.¶

Inputs:- identifier, identifier i of the participant, a NonZeroScalar.- PK_i, the public key for the i-th participant, where  PK_i = G.ScalarBaseMult(sk_i), an Element.- comm_i, pair of Element values in G  (hiding_nonce_commitment, binding_nonce_commitment) generated in  round one from the i-th participant.- sig_share_i, a Scalar value indicating the signature share as  produced in round two from the i-th participant.- commitment_list = [(i, hiding_nonce_commitment_i,  binding_nonce_commitment_i), ...], a list of commitments issued by  each participant, where each element in the list indicates a  NonZeroScalar identifier i and two commitment Element values  (hiding_nonce_commitment_i, binding_nonce_commitment_i). This list  MUST be sorted in ascending order by identifier.- group_public_key, public key corresponding to the group signing  key, an Element.- msg, the message to be signed, a byte string.Outputs:- True if the signature share is valid, and False otherwise.def verify_signature_share(        identifier, PK_i, comm_i, sig_share_i, commitment_list,        group_public_key, msg):  # Compute the binding factors  binding_factor_list = compute_binding_factors(group_public_key,   commitment_list, msg)  binding_factor = binding_factor_for_participant(      binding_factor_list, identifier)  # Compute the group commitment  group_commitment = compute_group_commitment(      commitment_list, binding_factor_list)  # Compute the commitment share  (hiding_nonce_commitment, binding_nonce_commitment) = comm_i  comm_share = hiding_nonce_commitment + G.ScalarMult(      binding_nonce_commitment, binding_factor)  # Compute the challenge  challenge = compute_challenge(      group_commitment, group_public_key, msg)  # Compute the interpolating value  participant_list = participants_from_commitment_list(      commitment_list)  lambda_i = derive_interpolating_value(participant_list, identifier)  # Compute relation values  l = G.ScalarBaseMult(sig_share_i)  r = comm_share + G.ScalarMult(PK_i, challenge * lambda_i)  return l == r

The Coordinator can verify each signature share before aggregating andverifying the signature under the group public key. However, since theaggregate signature is valid if all signature shares are valid, this order ofoperations is more expensive if the signature is valid.¶

5.4.Identifiable Abort

FROST does not provide robustness; i.e, all participants are required to complete theprotocol honestly in order to generate a valid signature. When the signing protocoldoes not produce a valid signature, the CoordinatorSHOULD abort; seeSection 7for more information about FROST's security properties and the threat model.¶

As a result of this property, a misbehaving participant can cause a denial of service (DoS) onthe signing protocol by contributing malformed signature shares or refusing to participate.Identifying misbehaving participants that produce invalid shares can be done by checkingsignature shares from each participant usingverify_signature_share as described inSection 5.3.FROST assumes the network channel is authenticated to identify the signer that misbehaved.FROST allows for identifying misbehaving participants that produce invalid signature sharesas described inSection 5.3. FROST does not provide accommodations for identifyingparticipants that refuse to participate, though applications are assumed to detect when participantsfail to engage in the signing protocol.¶

In both cases, preventing this type of attack requires the Coordinator to identifymisbehaving participants such that applications can take corrective action. The mechanismfor acting on misbehaving participants is out of scope for this specification. However,one reasonable approach would be to remove the misbehaving participant from the set of allowedparticipants in future runs of FROST.¶

6.1.FROST(Ed25519, SHA-512)

This ciphersuite uses edwards25519 for the Group and SHA-512 for the hash functionHmeant to produce Ed25519-compliant signatures as specified inSection 5.1 of [RFC8032].The value of the contextString parameter is "FROST-ED25519-SHA512-v1".¶

Group:

edwards25519[RFC8032], where Ne = 32 and Ns = 32.¶

Order():

Return 2²⁵² + 27742317777372353535851937790883648493 (see[RFC7748]).¶

Identity():

As defined in[RFC7748].¶

RandomScalar():

Implemented by returning a uniformly random Scalar in the range[0,G.Order() - 1]. Refer toAppendix D for implementation guidance.¶

SerializeElement(A):

Implemented as specified in[RFC8032],Section 5.1.2.Additionally, this function validates that the input element is not the groupidentity element.¶

DeserializeElement(buf):

Implemented as specified in[RFC8032],Section 5.1.3.Additionally, this function validates that the resulting element is not the groupidentity element and is in the prime-order subgroup. If any of these checks fail,deserialization returns an error. The latter check canbe implemented by multiplying the resulting point by the order of the group andchecking that the result is the identity element. Note that optimizations forthis check exist; see[Pornin22].¶

SerializeScalar(s):

Implemented by outputting the little-endian 32-byte encoding ofthe Scalar value with the top three bits set to zero.¶

DeserializeScalar(buf):

Implemented by attempting to deserialize a Scalar from alittle-endian 32-byte string. This function can fail if the input does notrepresent a Scalar in the range [0,G.Order() - 1]. Note that this means thetop three bits of the inputMUST be zero.¶

Hash (H):

SHA-512, which has an output of 64 bytes.¶

H1(m):

Implemented by computing H(contextString || "rho" || m), interpreting the 64-byte digestas a little-endian integer, and reducing the resulting integer modulo2²⁵² + 27742317777372353535851937790883648493.¶

H2(m):

Implemented by computing H(m), interpreting the 64-byte digestas a little-endian integer, and reducing the resulting integer modulo2²⁵² + 27742317777372353535851937790883648493.¶

H3(m):

Implemented by computing H(contextString || "nonce" || m), interpreting the 64-byte digestas a little-endian integer, and reducing the resulting integer modulo2²⁵² + 27742317777372353535851937790883648493.¶

H4(m):

Implemented by computing H(contextString || "msg" || m).¶

H5(m):

Implemented by computing H(contextString || "com" || m).¶

Normally, H2 would also include a domain separator; however, for compatibility with[RFC8032], it is omitted.¶

Signature verification is as specified inSection 5.1.7 of [RFC8032] with theconstraint that implementationsMUST check the group equation[8][z]B = [8]R + [8][c]PK(changed to use the notation in this document).¶

Canonical signature encoding is as specified inAppendix A.¶

6.2.FROST(ristretto255, SHA-512)

This ciphersuite uses ristretto255 for the Group and SHA-512 for the hash functionH.The value of the contextString parameter is "FROST-RISTRETTO255-SHA512-v1".¶

Group:

ristretto255[RISTRETTO], where Ne = 32 and Ns = 32.¶

Order():

Return 2²⁵² + 27742317777372353535851937790883648493 (see[RISTRETTO]).¶

Identity():

As defined in[RISTRETTO].¶

RandomScalar():

Implemented by returning a uniformly random Scalar in the range[0,G.Order() - 1]. Refer toAppendix D for implementation guidance.¶

SerializeElement(A):

Implemented using the "Encode" function from[RISTRETTO].Additionally, this function validates that the input element is not the groupidentity element.¶

DeserializeElement(buf):

Implemented using the "Decode" function from[RISTRETTO].Additionally, this function validates that the resulting element is not the groupidentity element. If either the "Decode" function or the check fails, deserialization returns an error.¶

SerializeScalar(s):

Implemented by outputting the little-endian 32-byte encoding ofthe Scalar value with the top three bits set to zero.¶

DeserializeScalar(buf):

Implemented by attempting to deserialize a Scalar from alittle-endian 32-byte string. This function can fail if the input does notrepresent a Scalar in the range [0,G.Order() - 1]. Note that this means thetop three bits of the inputMUST be zero.¶

Hash (H):

SHA-512, which has 64 bytes of output.¶

H1(m):

Implemented by computing H(contextString || "rho" || m) and mapping theoutput to a Scalar as described in[RISTRETTO],Section 4.4.¶

H2(m):

Implemented by computing H(contextString || "chal" || m) and mapping theoutput to a Scalar as described in[RISTRETTO],Section 4.4.¶

H3(m):

Implemented by computing H(contextString || "nonce" || m) and mapping theoutput to a Scalar as described in[RISTRETTO],Section 4.4.¶

H4(m):

Implemented by computing H(contextString || "msg" || m).¶

H5(m):

Implemented by computing H(contextString || "com" || m).¶

Signature verification is as specified inAppendix B.¶

Canonical signature encoding is as specified inAppendix A.¶

6.3.FROST(Ed448, SHAKE256)

This ciphersuite uses edwards448 for the Group and SHAKE256 for the hash functionH meant to produce Ed448-compliant signatures as specified inSection 5.2 of [RFC8032]. Unlike Ed448 in[RFC8032], this ciphersuite does not allow applications to specify a context string and always sets the context of[RFC8032] to the empty string.Note that this ciphersuite does not allow applications to specify a contextstring as is allowed for Ed448 in[RFC8032], and always setsthe[RFC8032] context string to the empty string. The value ofthe (internal to FROST) contextString parameter is"FROST-ED448-SHAKE256-v1".¶

Group:

edwards448[RFC8032], where Ne = 57 and Ns = 57.¶

Order():

Return 2⁴⁴⁶ - 13818066809895115352007386748515426880336692474882178609894547503885.¶

Identity():

As defined in[RFC7748].¶

RandomScalar():

Implemented by returning a uniformly random Scalar in the range[0,G.Order() - 1]. Refer toAppendix D for implementation guidance.¶

SerializeElement(A):

Implemented as specified in[RFC8032],Section 5.2.2.Additionally, this function validates that the input element is not the groupidentity element.¶

DeserializeElement(buf):

Implemented as specified in[RFC8032],Section 5.2.3.Additionally, this function validates that the resulting element is not the groupidentity element and is in the prime-order subgroup. If any of these checks fail,deserialization returns an error. The latter check canbe implemented by multiplying the resulting point by the order of the group andchecking that the result is the identity element. Note that optimizations forthis check exist; see[Pornin22].¶

SerializeScalar(s):

Implemented by outputting the little-endian 57-byte encoding ofthe Scalar value.¶

DeserializeScalar(buf):

Implemented by attempting to deserialize a Scalar from alittle-endian 57-byte string. This function can fail if the input does notrepresent a Scalar in the range [0,G.Order() - 1].¶

Hash (H):

SHAKE256 with 114 bytes of output.¶

H1(m):

Implemented by computing H(contextString || "rho" || m), interpreting the114-byte digest as a little-endian integer, and reducing the resulting integer modulo2⁴⁴⁶ - 13818066809895115352007386748515426880336692474882178609894547503885.¶

H2(m):

Implemented by computing H("SigEd448" || 0 || 0 || m), interpretingthe 114-byte digest as a little-endian integer, and reducing the resulting integermodulo 2⁴⁴⁶ - 13818066809895115352007386748515426880336692474882178609894547503885.¶

H3(m):

Implemented by computing H(contextString || "nonce" || m), interpreting the114-byte digest as a little-endian integer, and reducing the resulting integer modulo2⁴⁴⁶ - 13818066809895115352007386748515426880336692474882178609894547503885.¶

H4(m):

Implemented by computing H(contextString || "msg" || m).¶

H5(m):

Implemented by computing H(contextString || "com" || m).¶

Normally, H2 would also include a domain separator. However, it is omitted for compatibility with[RFC8032].¶

Signature verification is as specified inSection 5.2.7 of [RFC8032] with theconstraint that implementationsMUST check the group equation[4][z]B = [4]R + [4][c]PK(changed to use the notation in this document).¶

Canonical signature encoding is as specified inAppendix A.¶

6.4.FROST(P-256, SHA-256)

This ciphersuite uses P-256 for the Group and SHA-256 for the hash functionH.The value of the contextString parameter is "FROST-P256-SHA256-v1".¶

Group:

P-256 (secp256r1)[x9.62], where Ne = 33 and Ns = 32.¶

Order():

Return 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551.¶

Identity():

As defined in[x9.62].¶

RandomScalar():

Implemented by returning a uniformly random Scalar in the range[0,G.Order() - 1]. Refer toAppendix D for implementation guidance.¶

SerializeElement(A):

Implemented using the compressed Elliptic-Curve-Point-to-Octet-Stringmethod according to[SEC1], yielding a 33-byte output. Additionally, this function validatesthat the input element is not the group identity element.¶

DeserializeElement(buf):

Implemented by attempting to deserialize a 33-byte input string toa public key using the compressed Octet-String-to-Elliptic-Curve-Point method according to[SEC1] and then performing public key validation as defined in Section 3.2.2.1 of[SEC1].This includes checking that the coordinates of the resulting point arein the correct range, that the point is on the curve, and that the point is notthe point at infinity. (As noted in the specification, validation of the pointorder is not required since the cofactor is 1.) If any of these checks fail,deserialization returns an error.¶

SerializeScalar(s):

Implemented using the Field-Element-to-Octet-String conversionaccording to[SEC1].¶

DeserializeScalar(buf):

Implemented by attempting to deserialize a Scalar from a 32-bytestring using Octet-String-to-Field-Element from[SEC1]. This function can fail if theinput does not represent a Scalar in the range [0,G.Order() - 1].¶

Hash (H):

SHA-256, which has 32 bytes of output.¶

H1(m):

Implemented as hash_to_field(m, 1) (see[HASH-TO-CURVE],Section 5.2)usingexpand_message_xmd with SHA-256 with parameters DST = contextString || "rho",F set to the Scalar field, p set toG.Order(), m = 1, and L = 48.¶

H2(m):

Implemented as hash_to_field(m, 1) (see[HASH-TO-CURVE],Section 5.2)usingexpand_message_xmd with SHA-256 with parameters DST = contextString || "chal",F set to the Scalar field, p set toG.Order(), m = 1, and L = 48.¶

H3(m):

Implemented as hash_to_field(m, 1) (see[HASH-TO-CURVE],Section 5.2)usingexpand_message_xmd with SHA-256 with parameters DST = contextString || "nonce",F set to the Scalar field, p set toG.Order(), m = 1, and L = 48.¶

H4(m):

Implemented by computing H(contextString || "msg" || m).¶

H5(m):

Implemented by computing H(contextString || "com" || m).¶

Signature verification is as specified inAppendix B.¶

Canonical signature encoding is as specified inAppendix A.¶

6.5.FROST(secp256k1, SHA-256)

This ciphersuite uses secp256k1 for the Group and SHA-256 for the hash functionH.The value of the contextString parameter is "FROST-secp256k1-SHA256-v1".¶

Group:

secp256k1[SEC2], where Ne = 33 and Ns = 32.¶

Order():

Return 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141.¶

Identity():

As defined in[SEC2].¶

RandomScalar():

Implemented by returning a uniformly random Scalar in the range[0,G.Order() - 1]. Refer toAppendix D for implementation guidance.¶

SerializeElement(A):

Implemented using the compressed Elliptic-Curve-Point-to-Octet-Stringmethod according to[SEC1], yielding a 33-byte output. Additionally, this function validatesthat the input element is not the group identity element.¶

DeserializeElement(buf):

Implemented by attempting to deserialize a 33-byte input string toa public key using the compressed Octet-String-to-Elliptic-Curve-Point method according to[SEC1] and then performing public key validation as defined in Section 3.2.2.1 of[SEC1].This includes checking that the coordinates of the resulting point arein the correct range, the point is on the curve, and the point is notthe point at infinity. (As noted in the specification, validation of the pointorder is not required since the cofactor is 1.) If any of these checks fail,deserialization returns an error.¶

SerializeScalar(s):

Implemented using the Field-Element-to-Octet-String conversionaccording to[SEC1].¶

DeserializeScalar(buf):

Implemented by attempting to deserialize a Scalar from a 32-bytestring using Octet-String-to-Field-Element from[SEC1]. This function can fail if theinput does not represent a Scalar in the range [0,G.Order() - 1].¶

Hash (H):

SHA-256, which has 32 bytes of output.¶

H1(m):

Implemented as hash_to_field(m, 1) (see[HASH-TO-CURVE],Section 5.2)usingexpand_message_xmd with SHA-256 with parameters DST = contextString || "rho",F set to the Scalar field, p set toG.Order(), m = 1, and L = 48.¶

H2(m):

Implemented as hash_to_field(m, 1) (see[HASH-TO-CURVE],Section 5.2)usingexpand_message_xmd with SHA-256 with parameters DST = contextString || "chal",F set to the Scalar field, p set toG.Order(), m = 1, and L = 48.¶

H3(m):

Implemented as hash_to_field(m, 1) (see[HASH-TO-CURVE],Section 5.2)usingexpand_message_xmd with SHA-256 with parameters DST = contextString || "nonce",F set to the Scalar field, p set toG.Order(), m = 1, and L = 48.¶

H4(m):

Implemented by computing H(contextString || "msg" || m).¶

H5(m):

Implemented by computing H(contextString || "com" || m).¶

Signature verification is as specified inAppendix B.¶

Canonical signature encoding is as specified inAppendix A.¶

6.6.Ciphersuite Requirements

Future documents that introduce new ciphersuitesMUST adhere tothe following requirements.¶

1. H1, H2, and H3 all have output distributions that are close to (indistinguishable from) the uniform distribution.¶
2. All hash functionsMUST be domain-separated with a per-suite context string. Note that the FROST(Ed25519, SHA-512) ciphersuite does not adhere to this requirement for H2 alone in order to maintain compatibility with[RFC8032].¶
3. The groupMUST be of prime order and all deserialization functionsMUST output elements that belong to their respective sets of Elements or Scalars, or else fail.¶
4. The canonical signature encoding details are clearly specified.¶

7.1.Side-Channel Mitigations

Several routines process secret values (nonces, signing keys / shares), and dependingon the implementation and deployment environment, mitigating side-channels may bepertinent. Mitigating these side-channels requires implementingG.ScalarMult(),G.ScalarBaseMult(),G.SerializeScalar(), andG.DeserializeScalar() in constant (value-independent) time.The various ciphersuites lend themselves differently to specific implementation techniquesand ease of achieving side-channel resistance, though ultimately avoiding value-dependentcomputation or branching is the goal.¶

7.2.Optimizations

[StrongerSec22] presented an optimization to FROST that reduces the total number of Scalar multiplicationsfrom linear in the number of signing participants to a constant. However, as described in[StrongerSec22],this optimization removes the guarantee that the set of signer participants that started round one ofthe protocol is the same set of signing participants that produced the signature output by round two.As such, the optimization isNOT RECOMMENDED and is not covered in this document.¶

7.3.Nonce Reuse Attacks

Section 4.1 describes the procedure that participants use to produce nonces duringthe first round of signing. The randomness produced in this procedureMUST be sampleduniformly at random. The resulting nonces produced vianonce_generate are indistinguishablefrom values sampled uniformly at random. This requirement is necessary to avoidreplay attacks initiated by other participants that allow for a complete key-recovery attack.The CoordinatorMAY further hedge against nonce reuse attacks by tracking participant noncecommitments used for a given group key at the cost of additional state.¶

7.4.Protocol Failures

We do not specify what implementations should do when the protocol fails other than requiringthe protocol to abort. Examples of viable failures include when a verification check returns invalid or the underlying transport failed to deliver the required messages.¶

7.5.Removing the Coordinator Role

In some settings, it may be desirable to omit the role of the Coordinator entirely.Doing so does not change the security implications of FROST; instead, it simplyrequires each participant to communicate with all other participants. We looselydescribe how to perform FROST signing among participants without this coordinator role.We assume that every participant receives a message to be signed from an external source as input prior to performing the protocol.¶

Every participant begins by performingcommit() as is done in the settingwhere a Coordinator is used. However, instead of sending the commitmentto the Coordinator, every participant will publish this commitment to every other participant. In the second round, participants will already have sufficient information to perform signing, and they will directly performsign(). All participants will then publish their signature shares to one another. After having received all signature shares from all other participants, each participant will then performverify_signature_share and thenaggregate directly.¶

The requirements for the underlying network channel remain the same in thesetting where all participants play the role of the Coordinator, in that allexchanged messages are public and the channel must be reliable. However, in the settingwhere a player attempts to split the view of all other players by sendingdisjoint values to a subset of players, the signing operation will output aninvalid signature. To avoid this DoS, implementations may wish to define amechanism where messages are authenticated so that cheating players can beidentified and excluded.¶

7.6.Input Message Hashing

FROST signatures do not pre-hash message inputs. This means that the entire message must be known in advance of invoking the signing protocol. Applications can apply pre-hashing in settings where storing the full message is prohibitively expensive. In such cases, pre-hashingMUST use a collision-resistant hash function with a security level commensurate with the security inherent to the ciphersuite chosen. For applications that choose to apply pre-hashing, it isRECOMMENDED that they use the hash function (H) associated with the chosen ciphersuite in a manner similar to howH4 is defined. In particular, a different prefixSHOULD be used to differentiate this pre-hash fromH4. For example, if a fictional protocol Quux decided to pre-hash its input messages, one possible way to do so is viaH(contextString || "Quux-pre-hash" || m).¶

7.7.Input Message Validation

Message validation varies by application. For example, some applications mayrequire that participants only process messages of a certain structure. In digitalcurrency applications, wherein multiple participants may collectively sign a transaction,it is reasonable to require each participant to check that the input message is asyntactically valid transaction.¶

As another example, some applications may require that participants only processmessages with permitted content according to some policy. In digital currencyapplications, this might mean that a transaction being signed is allowed andintended by the relevant stakeholders. Another instance of this type of messagevalidation is in the context of[TLS], wherein implementations mayuse threshold signing protocols to produce signatures of transcript hashes. Inthis setting, signing participants might require the raw TLS handshake messagesto validate before computing the transcript hash that is signed.¶

In general, input message validation is an application-specific considerationthat varies based on the use case and threat model. However, it isRECOMMENDEDthat applications take additional precautions and validate inputs so thatparticipants do not operate as signing oracles for arbitrary messages.¶

C.1.Shamir Secret Sharing

In Shamir secret sharing, a dealer distributes a secretScalars ton participantsin such a way that any cooperating subset of at leastMIN_PARTICIPANTS participants can recover thesecret. There are two basic steps in this scheme: 1) splitting a secret intomultiple shares and 2) combining shares to reveal the resulting secret.¶

This secret sharing scheme works over any fieldF. In this specification,F isthe Scalar field of the prime-order groupG.¶

The procedure for splitting a secret into shares is as follows.The algorithmpolynomial_evaluate is defined inAppendix C.1.1.¶

Inputs:- s, secret value to be shared, a Scalar.- coefficients, an array of size MIN_PARTICIPANTS - 1 with randomly  generated Scalars, not including the 0th coefficient of the  polynomial.- MAX_PARTICIPANTS, the number of shares to generate, an integer less  than the group order.Outputs:- secret_key_shares, A list of MAX_PARTICIPANTS number of secret  shares, each a tuple consisting of the participant identifier  (a NonZeroScalar) and the key share (a Scalar).- coefficients, a vector of MIN_PARTICIPANTS coefficients which  uniquely determine a polynomial f.def secret_share_shard(s, coefficients, MAX_PARTICIPANTS):  # Prepend the secret to the coefficients  coefficients = [s] + coefficients  # Evaluate the polynomial for each point x=1,...,n  secret_key_shares = []  for x_i in range(1, MAX_PARTICIPANTS + 1):    y_i = polynomial_evaluate(Scalar(x_i), coefficients)    secret_key_share_i = (x_i, y_i)    secret_key_shares.append(secret_key_share_i)  return secret_key_shares, coefficients

Letpoints be the output of this function. The i-th element inpoints isthe share for the i-th participant, which is the randomly generated polynomialevaluated at coordinatei. We denote a secret share as the tuple(i, points[i])and the list of these shares asshares.iMUST never equal0; recall thatf(0) = s, wheref is the polynomial defined in a Shamir secret sharing operation.¶

The procedure for combining ashares list of lengthMIN_PARTICIPANTS to recover thesecrets is as follows; the algorithmpolynomial_interpolate_constant is defined inAppendix C.1.1.¶

Inputs:- shares, a list of at minimum MIN_PARTICIPANTS secret shares, each a  tuple (i, f(i)) where i and f(i) are Scalars.Outputs:- s, the resulting secret that was previously split into shares,  a Scalar.Errors:- "invalid parameters", if fewer than MIN_PARTICIPANTS input shares  are provided.def secret_share_combine(shares):  if len(shares) < MIN_PARTICIPANTS:    raise "invalid parameters"  s = polynomial_interpolate_constant(shares)  return s

Inputs:- x, input at which to evaluate the polynomial, a Scalar- coeffs, the polynomial coefficients, a list of ScalarsOutputs: Scalar result of the polynomial evaluated at input xdef polynomial_evaluate(x, coeffs):  value = Scalar(0)  for coeff in reverse(coeffs):    value *= x    value += coeff  return value

Inputs:- points, a set of t points with distinct x coordinates on  a polynomial f, each a tuple of two Scalar values representing the  x and y coordinates.Outputs:- f_zero, the constant term of f, i.e., f(0), a Scalar.def polynomial_interpolate_constant(points):  x_coords = []  for (x, y) in points:    x_coords.append(x)  f_zero = Scalar(0)  for (x, y) in points:    delta = y * derive_interpolating_value(x_coords, x)    f_zero += delta  return f_zero

C.2.Verifiable Secret Sharing

Feldman's Verifiable Secret Sharing (VSS)[FeldmanSecretSharing]builds upon Shamir secret sharing, adding a verification step to demonstrate the consistency of a participant'sshare with a public commitment to the polynomialf for which the secretsis the constant term. This check ensures that all participants have a point(their share) on the same polynomial, ensuring that they can reconstructthe correct secret later.¶

The procedure for committing to a polynomialf of degree at mostMIN_PARTICIPANTS-1 is as follows.¶

Inputs:- coeffs, a vector of the MIN_PARTICIPANTS coefficients that  uniquely determine a polynomial f.Outputs:- vss_commitment, a vector commitment to each of the coefficients in  coeffs, where each item of the vector commitment is an Element.def vss_commit(coeffs):  vss_commitment = []  for coeff in coeffs:    A_i = G.ScalarBaseMult(coeff)    vss_commitment.append(A_i)  return vss_commitment

The procedure for verification of a participant's share is as follows.Ifvss_verify fails, the participantMUST abort the protocol, and the failure should be investigated out of band.¶

Inputs:- share_i: A tuple of the form (i, sk_i), where i indicates the  participant identifier (a NonZeroScalar), and sk_i the  participant's secret key, a secret share of the constant term of f,  where sk_i is a Scalar.- vss_commitment, a VSS commitment to a secret polynomial f, a vector  commitment to each of the coefficients in coeffs, where each  element of the vector commitment is an Element.Outputs:- True if sk_i is valid, and False otherwise.def vss_verify(share_i, vss_commitment)  (i, sk_i) = share_i  S_i = G.ScalarBaseMult(sk_i)  S_i' = G.Identity()  for j in range(0, MIN_PARTICIPANTS):    S_i' += G.ScalarMult(vss_commitment[j], pow(i, j))  return S_i == S_i'

We now define how the Coordinator and participants can derive group info,which is an input into the FROST signing protocol.¶

Inputs:- MAX_PARTICIPANTS, the number of shares to generate, an integer.- MIN_PARTICIPANTS, the threshold of the secret sharing scheme,  an integer.- vss_commitment, a VSS commitment to a secret polynomial f, a vector  commitment to each of the coefficients in coeffs, where each  element of the vector commitment is an Element.Outputs:- PK, the public key representing the group, an Element.- participant_public_keys, a list of MAX_PARTICIPANTS public keys  PK_i for i=1,...,MAX_PARTICIPANTS, where each PK_i is the public  key, an Element, for participant i.def derive_group_info(MAX_PARTICIPANTS, MIN_PARTICIPANTS, vss_commitment):  PK = vss_commitment[0]  participant_public_keys = []  for i in range(1, MAX_PARTICIPANTS+1):    PK_i = G.Identity()    for j in range(0, MIN_PARTICIPANTS):      PK_i += G.ScalarMult(vss_commitment[j], pow(i, j))    participant_public_keys.append(PK_i)  return PK, participant_public_keys

D.1.Rejection Sampling

Generate a random byte array withNs bytes and attempt to map to a Scalarby callingDeserializeScalar in constant time. If it succeeds, return theresult. If it fails, try again with another random byte array, until theprocedure succeeds. Failure to implementDeserializeScalar in constant timecan leak information about the underlying corresponding Scalar.¶

As an optimization, if the group order is very close to a power of2, it is acceptable to omit the rejection test completely. In particular, if the group order is p and there is an integer b such that |p - 2^b| is less than 2^(b/2), thenRandomScalar can simply return a uniformly random integer of atmost b bits.¶

D.2.Wide Reduction

Generate a random byte array withl = ceil(((3 * ceil(log2(G.Order()))) / 2) / 8)bytes and interpret it as an integer; reduce the integer moduloG.Order() and return theresult. SeeSection 5 of [HASH-TO-CURVE] for the underlying derivation ofl.¶

E.1.FROST(Ed25519, SHA-512)

// Configuration informationMAX_PARTICIPANTS: 3MIN_PARTICIPANTS: 2NUM_PARTICIPANTS: 2// Group input parametersparticipant_list: 1,3group_secret_key: 7b1c33d3f5291d85de664833beb1ad469f7fb6025a0ec78b3a790c6e13a98304group_public_key: 15d21ccd7ee42959562fc8aa63224c8851fb3ec85a3faf66040d380fb9738673message: 74657374share_polynomial_coefficients[1]: 178199860edd8c62f5212ee91eff1295d0d670ab4ed4506866bae57e7030b204// Signer input parametersP1 participant_share: 929dcc590407aae7d388761cddb0c0db6f5627aea8e217f4a033f2ec83d93509P2 participant_share: a91e66e012e4364ac9aaa405fcafd370402d9859f7b6685c07eed76bf409e80dP3 participant_share: d3cb090a075eb154e82fdb4b3cb507f110040905468bb9c46da8bdea643a9a02// Signer round one outputsP1 hiding_nonce_randomness: 0fd2e39e111cdc266f6c0f4d0fd45c947761f1f5d3cb583dfcb9bbaf8d4c9fecP1 binding_nonce_randomness: 69cd85f631d5f7f2721ed5e40519b1366f340a87c2f6856363dbdcda348a7501P1 hiding_nonce: 812d6104142944d5a55924de6d49940956206909f2acaeedecda2b726e630407P1 binding_nonce: b1110165fc2334149750b28dd813a39244f315cff14d4e89e6142f262ed83301P1 hiding_nonce_commitment: b5aa8ab305882a6fc69cbee9327e5a45e54c08af61ae77cb8207be3d2ce13de3P1 binding_nonce_commitment: 67e98ab55aa310c3120418e5050c9cf76cf387cb20ac9e4b6fdb6f82a469f932P1 binding_factor_input: 15d21ccd7ee42959562fc8aa63224c8851fb3ec85a3faf66040d380fb9738673504df914fa965023fb75c25ded4bb260f417de6d32e5c442c6ba313791cc9a4948d6273e8d3511f93348ea7a708a9b862bc73ba2a79cfdfe07729a193751cbc973af46d8ac3440e518d4ce440a0e7d4ad5f62ca8940f32de6d8dc00fc12c660b817d587d82f856d277ce6473cae6d2f5763f7da2e8b4d799a3f3e725d4522ec70100000000000000000000000000000000000000000000000000000000000000P1 binding_factor: f2cb9d7dd9beff688da6fcc83fa89046b3479417f47f55600b106760eb3b5603P3 hiding_nonce_randomness: 86d64a260059e495d0fb4fcc17ea3da7452391baa494d4b00321098ed2a0062fP3 binding_nonce_randomness: 13e6b25afb2eba51716a9a7d44130c0dbae0004a9ef8d7b5550c8a0e07c61775P3 hiding_nonce: c256de65476204095ebdc01bd11dc10e57b36bc96284595b8215222374f99c0eP3 binding_nonce: 243d71944d929063bc51205714ae3c2218bd3451d0214dfb5aeec2a90c35180dP3 hiding_nonce_commitment: cfbdb165bd8aad6eb79deb8d287bcc0ab6658ae57fdcc98ed12c0669e90aec91P3 binding_nonce_commitment: 7487bc41a6e712eea2f2af24681b58b1cf1da278ea11fe4e8b78398965f13552P3 binding_factor_input: 15d21ccd7ee42959562fc8aa63224c8851fb3ec85a3faf66040d380fb9738673504df914fa965023fb75c25ded4bb260f417de6d32e5c442c6ba313791cc9a4948d6273e8d3511f93348ea7a708a9b862bc73ba2a79cfdfe07729a193751cbc973af46d8ac3440e518d4ce440a0e7d4ad5f62ca8940f32de6d8dc00fc12c660b817d587d82f856d277ce6473cae6d2f5763f7da2e8b4d799a3f3e725d4522ec70300000000000000000000000000000000000000000000000000000000000000P3 binding_factor: b087686bf35a13f3dc78e780a34b0fe8a77fef1b9938c563f5573d71d8d7890f// Signer round two outputsP1 sig_share: 001719ab5a53ee1a12095cd088fd149702c0720ce5fd2f29dbecf24b7281b603P3 sig_share: bd86125de990acc5e1f13781d8e32c03a9bbd4c53539bbc106058bfd14326007sig: 36282629c383bb820a88b71cae937d41f2f2adfcc3d02e55507e2fb9e2dd3cbebd9d2b0844e49ae0f3fa935161e1419aab7b47d21a37ebeae1f17d4987b3160b

E.2.FROST(Ed448, SHAKE256)

// Configuration informationMAX_PARTICIPANTS: 3MIN_PARTICIPANTS: 2NUM_PARTICIPANTS: 2// Group input parametersparticipant_list: 1,3group_secret_key: 6298e1eef3c379392caaed061ed8a31033c9e9e3420726f23b404158a401cd9df24632adfe6b418dc942d8a091817dd8bd70e1c72ba52f3c00group_public_key: 3832f82fda00ff5365b0376df705675b63d2a93c24c6e81d40801ba265632be10f443f95968fadb70d10786827f30dc001c8d0f9b7c1d1b000message: 74657374share_polynomial_coefficients[1]: dbd7a514f7a731976620f0436bd135fe8dddc3fadd6e0d13dbd58a1981e587d377d48e0b7ce4e0092967c5e85884d0275a7a740b6abdcd0500// Signer input parametersP1 participant_share: 4a2b2f5858a932ad3d3b18bd16e76ced3070d72fd79ae4402df201f525e754716a1bc1b87a502297f2a99d89ea054e0018eb55d39562fd0100P2 participant_share: 2503d56c4f516444a45b080182b8a2ebbe4d9b2ab509f25308c88c0ea7ccdc44e2ef4fc4f63403a11b116372438a1e287265cadeff1fcb0700P3 participant_share: 00db7a8146f995db0a7cf844ed89d8e94c2b5f259378ff66e39d172828b264185ac4decf7219e4aa4478285b9c0eef4fccdf3eea69dd980d00// Signer round one outputsP1 hiding_nonce_randomness: 9cda90c98863ef3141b75f09375757286b4bc323dd61aeb45c07de45e4937bbdP1 binding_nonce_randomness: 781bf4881ffe1aa06f9341a747179f07a49745f8cd37d4696f226aa065683c0aP1 hiding_nonce: f922beb51a5ac88d1e862278d89e12c05263b945147db04b9566acb2b5b0f7422ccea4f9286f4f80e6b646e72143eeaecc0e5988f8b2b93100P1 binding_nonce: 1890f16a120cdeac092df29955a29c7cf29c13f6f7be60e63d63f3824f2d37e9c3a002dfefc232972dc08658a8c37c3ec06a0c5dc146150500P1 hiding_nonce_commitment: 3518c2246c874569e54ab254cb1da666ca30f7879605cc43b4d2c47a521f8b5716080ab723d3a0cd04b7e41f3cc1d3031c94ccf3829b23fe80P1 binding_nonce_commitment: 11b3d5220c57d02057497de3c4eebab384900206592d877059b0a5f1d5250d002682f0e22dff096c46bb81b46d60fcfe7752ed47cea76c3900P1 binding_factor_input: 3832f82fda00ff5365b0376df705675b63d2a93c24c6e81d40801ba265632be10f443f95968fadb70d10786827f30dc001c8d0f9b7c1d1b000e9a0f30b97fe77ef751b08d4e252a3719ae9135e7f7926f7e3b7dd6656b27089ca354997fe5a633aa0946c89f022462e7e9d50fd6ef313f72d956ea4571089427daa1862f623a41625177d91e4a8f350ce9c8bd3bc7c766515dc1dd3a0eab93777526b616cccb148fe1e5992dc1ae705c8ba2f97ca8983328d41d375ed1e5fde5c9d672121c9e8f177f4a1a9b2575961531b33f054451363c8f27618382cd66ce14ad93b68dac6a09f5edcbccc813906b3fc50b8fef1cc09757b06646f38ceed1674cd6ced28a59c93851b325c6a9ef6a4b3b88860b7138ee246034561c7460db0b3fae5010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000P1 binding_factor: 71966390dfdbed73cf9b79486f3b70e23b243e6c40638fb55998642a60109daecbfcb879eed9fe7dbbed8d9e47317715a5740f772173342e00P3 hiding_nonce_randomness: b3adf97ceea770e703ab295babf311d77e956a20d3452b4b3344aa89a828e6dfP3 binding_nonce_randomness: 81dbe7742b0920930299197322b255734e52bbb91f50cfe8ce689f56fadbce31P3 hiding_nonce: ccb5c1e82f23e0a4b966b824dbc7b0ef1cc5f56eeac2a4126e2b2143c5f3a4d890c52d27803abcf94927faf3fc405c0b2123a57a93cefa3b00P3 binding_nonce: e089df9bf311cf711e2a24ea27af53e07b846d09692fe11035a1112f04d8b7462a62f34d8c01493a22b57a1cbf1f0a46c77d64d46449a90100P3 hiding_nonce_commitment: 1254546d7d104c04e4fbcf29e05747e2edd392f6787d05a6216f3713ef859efe573d180d291e48411e5e3006e9f90ee986ccc26b7a42490b80P3 binding_nonce_commitment: 3ef0cec20be15e56b3ddcb6f7b956fca0c8f71990f45316b537b4f64c5e8763e6629d7262ff7cd0235d0781f23be97bf8fa8817643ea19cd00P3 binding_factor_input: 3832f82fda00ff5365b0376df705675b63d2a93c24c6e81d40801ba265632be10f443f95968fadb70d10786827f30dc001c8d0f9b7c1d1b000e9a0f30b97fe77ef751b08d4e252a3719ae9135e7f7926f7e3b7dd6656b27089ca354997fe5a633aa0946c89f022462e7e9d50fd6ef313f72d956ea4571089427daa1862f623a41625177d91e4a8f350ce9c8bd3bc7c766515dc1dd3a0eab93777526b616cccb148fe1e5992dc1ae705c8ba2f97ca8983328d41d375ed1e5fde5c9d672121c9e8f177f4a1a9b2575961531b33f054451363c8f27618382cd66ce14ad93b68dac6a09f5edcbccc813906b3fc50b8fef1cc09757b06646f38ceed1674cd6ced28a59c93851b325c6a9ef6a4b3b88860b7138ee246034561c7460db0b3fae5030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000P3 binding_factor: 236a6f7239ac2019334bad21323ec93bef2fead37bd55114356419f3fc1fb59f797f44079f28b1a64f51dd0a113f90f2c3a1c27d2faa4f1300// Signer round two outputsP1 sig_share: e1eb9bfbef792776b7103891032788406c070c5c315e3bf5d64acd46ea8855e85b53146150a09149665cbfec71626810b575e6f4dbe9ba3700P3 sig_share: 815434eb0b9f9242d54b8baf2141fe28976cabe5f441ccfcd5ee7cdb4b52185b02b99e6de28e2ab086c7764068c5a01b5300986b9f084f3e00sig: cd642cba59c449dad8e896a78a60e8edfcbd9040df524370891ff8077d47ce721d683874483795f0d85efcbd642c4510614328605a19c6ed806ffb773b6956419537cdfdb2b2a51948733de192dcc4b82dc31580a536db6d435e0cb3ce322fbcf9ec23362dda27092c08767e607bf2093600

E.3.FROST(ristretto255, SHA-512)

// Configuration informationMAX_PARTICIPANTS: 3MIN_PARTICIPANTS: 2NUM_PARTICIPANTS: 2// Group input parametersparticipant_list: 1,3group_secret_key: 1b25a55e463cfd15cf14a5d3acc3d15053f08da49c8afcf3ab265f2ebc4f970bgroup_public_key: e2a62f39eede11269e3bd5a7d97554f5ca384f9f6d3dd9c3c0d05083c7254f57message: 74657374share_polynomial_coefficients[1]: 410f8b744b19325891d73736923525a4f596c805d060dfb9c98009d34e3fec02// Signer input parametersP1 participant_share: 5c3430d391552f6e60ecdc093ff9f6f4488756aa6cebdbad75a768010b8f830eP2 participant_share: b06fc5eac20b4f6e1b271d9df2343d843e1e1fb03c4cbb673f2872d459ce6f01P3 participant_share: f17e505f0e2581c6acfe54d3846a622834b5e7b50cad9a2109a97ba7a80d5c04// Signer round one outputsP1 hiding_nonce_randomness: f595a133b4d95c6e1f79887220c8b275ce6277e7f68a6640e1e7140f9be2fb5cP1 binding_nonce_randomness: 34dd1001360e3513cb37bebfabe7be4a32c5bb91ba19fbd4360d039111f0fbdcP1 hiding_nonce: 214f2cabb86ed71427ea7ad4283b0fae26b6746c801ce824b83ceb2b99278c03P1 binding_nonce: c9b8f5e16770d15603f744f8694c44e335e8faef00dad182b8d7a34a62552f0cP1 hiding_nonce_commitment: 965def4d0958398391fc06d8c2d72932608b1e6255226de4fb8d972dac15fd57P1 binding_nonce_commitment: ec5170920660820007ae9e1d363936659ef622f99879898db86e5bf1d5bf2a14P1 binding_factor_input: e2a62f39eede11269e3bd5a7d97554f5ca384f9f6d3dd9c3c0d05083c7254f572889dde2854e26377a16caf77dfee5f6be8fe5b4c80318da84698a4161021b033911db5ef8205362701bc9ecd983027814abee94f46d094943a2f4b79a6e4d4603e52c435d8344554942a0a472d8ad84320585b8da3ae5b9ce31cd1903f795c1af66de22af1a45f652cd05ee446b1b4091aaccc91e2471cd18a85a659cecd11f0100000000000000000000000000000000000000000000000000000000000000P1 binding_factor: 8967fd70fa06a58e5912603317fa94c77626395a695a0e4e4efc4476662eba0cP3 hiding_nonce_randomness: daa0cf42a32617786d390e0c7edfbf2efbd428037069357b5173ae61d6dd5d5eP3 binding_nonce_randomness: b4387e72b2e4108ce4168931cc2c7fcce5f345a5297368952c18b5fc8473f050P3 hiding_nonce: 3f7927872b0f9051dd98dd73eb2b91494173bbe0feb65a3e7e58d3e2318fa40fP3 binding_nonce: ffd79445fb8030f0a3ddd3861aa4b42b618759282bfe24f1f9304c7009728305P3 hiding_nonce_commitment: 480e06e3de182bf83489c45d7441879932fd7b434a26af41455756264fbd5d6eP3 binding_nonce_commitment: 3064746dfd3c1862ef58fc68c706da287dd925066865ceacc816b3a28c7b363bP3 binding_factor_input: e2a62f39eede11269e3bd5a7d97554f5ca384f9f6d3dd9c3c0d05083c7254f572889dde2854e26377a16caf77dfee5f6be8fe5b4c80318da84698a4161021b033911db5ef8205362701bc9ecd983027814abee94f46d094943a2f4b79a6e4d4603e52c435d8344554942a0a472d8ad84320585b8da3ae5b9ce31cd1903f795c1af66de22af1a45f652cd05ee446b1b4091aaccc91e2471cd18a85a659cecd11f0300000000000000000000000000000000000000000000000000000000000000P3 binding_factor: f2c1bb7c33a10511158c2f1766a4a5fadf9f86f2a92692ed333128277cc31006// Signer round two outputsP1 sig_share: 9285f875923ce7e0c491a592e9ea1865ec1b823ead4854b48c8a46287749ee09P3 sig_share: 7cb211fe0e3d59d25db6e36b3fb32344794139602a7b24f1ae0dc4e26ad7b908sig: fc45655fbc66bbffad654ea4ce5fdae253a49a64ace25d9adb62010dd9fb25552164141787162e5b4cab915b4aa45d94655dbb9ed7c378a53b980a0be220a802

E.4.FROST(P-256, SHA-256)

// Configuration informationMAX_PARTICIPANTS: 3MIN_PARTICIPANTS: 2NUM_PARTICIPANTS: 2// Group input parametersparticipant_list: 1,3group_secret_key: 8ba9bba2e0fd8c4767154d35a0b7562244a4aaf6f36c8fb8735fa48b301bd8degroup_public_key: 023a309ad94e9fe8a7ba45dfc58f38bf091959d3c99cfbd02b4dc00585ec45ab70message: 74657374share_polynomial_coefficients[1]: 80f25e6c0709353e46bfbe882a11bdbb1f8097e46340eb8673b7e14556e6c3a4// Signer input parametersP1 participant_share: 0c9c1a0fe806c184add50bbdcac913dda73e482daf95dcb9f35dbb0d8a9f7731P2 participant_share: 8d8e787bef0ff6c2f494ca45f4dad198c6bee01212d6c84067159c52e1863ad5P3 participant_share: 0e80d6e8f6192c003b5488ce1eec8f5429587d48cf001541e713b2d53c09d928// Signer round one outputsP1 hiding_nonce_randomness: ec4c891c85fee802a9d757a67d1252e7f4e5efb8a538991ac18fbd0e06fb6fd3P1 binding_nonce_randomness: 9334e29d09061223f69a09421715a347e4e6deba77444c8f42b0c833f80f4ef9P1 hiding_nonce: 9f0542a5ba879a58f255c09f06da7102ef6a2dec6279700c656d58394d8facd4P1 binding_nonce: 6513dfe7429aa2fc972c69bb495b27118c45bbc6e654bb9dc9be55385b55c0d7P1 hiding_nonce_commitment: 0213b3e6298bf8ad46fd5e9389519a8665d63d98f4ec6a1fcca434e809d2d8070eP1 binding_nonce_commitment: 02188ff1390bf69374d7b272e454b1878ef10a6b6ea3ff36f114b300b4dbd5233bP1 binding_factor_input: 023a309ad94e9fe8a7ba45dfc58f38bf091959d3c99cfbd02b4dc00585ec45ab70825371853e974bc30ac5b947b216d70461919666584c70c51f9f56f117736c5d178dd0b521ad9c1abe98048419cbdec81504c85e12eb40e3bcb6ec73d3fc4afd0000000000000000000000000000000000000000000000000000000000000001P1 binding_factor: 7925f0d4693f204e6e59233e92227c7124664a99739d2c06b81cf64ddf90559eP3 hiding_nonce_randomness: c0451c5a0a5480d6c1f860e5db7d655233dca2669fd90ff048454b8ce983367bP3 binding_nonce_randomness: 2ba5f7793ae700e40e78937a82f407dd35e847e33d1e607b5c7eb6ed2a8ed799P3 hiding_nonce: f73444a8972bcda9e506bbca3d2b1c083c10facdf4bb5d47fef7c2dc1d9f2a0dP3 binding_nonce: 44c6a29075d6e7e4f8b97796205f9e22062e7835141470afe9417fd317c1c303P3 hiding_nonce_commitment: 033ac9a5fe4a8b57316ba1c34e8a6de453033b750e8984924a984eb67a11e73a3fP3 binding_nonce_commitment: 03a7a2480ee16199262e648aea3acab628a53e9b8c1945078f2ddfbdc98b7df369P3 binding_factor_input: 023a309ad94e9fe8a7ba45dfc58f38bf091959d3c99cfbd02b4dc00585ec45ab70825371853e974bc30ac5b947b216d70461919666584c70c51f9f56f117736c5d178dd0b521ad9c1abe98048419cbdec81504c85e12eb40e3bcb6ec73d3fc4afd0000000000000000000000000000000000000000000000000000000000000003P3 binding_factor: e10d24a8a403723bcb6f9bb4c537f316593683b472f7a89f166630dde11822c4// Signer round two outputsP1 sig_share: 400308eaed7a2ddee02a265abe6a1cfe04d946ee8720768899619cfabe7a3aebP3 sig_share: 561da3c179edbb0502d941bb3e3ace3c37d122aaa46fb54499f15f3a3331de44sig: 026d8d434874f87bdb7bc0dfd239b2c00639044f9dcb195e9a04426f70bfa4b70d9620acac6767e8e3e3036815fca4eb3a3caa69992b902bcd3352fc34f1ac192f

E.5.FROST(secp256k1, SHA-256)

// Configuration informationMAX_PARTICIPANTS: 3MIN_PARTICIPANTS: 2NUM_PARTICIPANTS: 2// Group input parametersparticipant_list: 1,3group_secret_key: 0d004150d27c3bf2a42f312683d35fac7394b1e9e318249c1bfe7f0795a83114group_public_key: 02f37c34b66ced1fb51c34a90bdae006901f10625cc06c4f64663b0eae87d87b4fmessage: 74657374share_polynomial_coefficients[1]: fbf85eadae3058ea14f19148bb72b45e4399c0b16028acaf0395c9b03c823579// Signer input parametersP1 participant_share: 08f89ffe80ac94dcb920c26f3f46140bfc7f95b493f8310f5fc1ea2b01f4254cP2 participant_share: 04f0feac2edcedc6ce1253b7fab8c86b856a797f44d83d82a385554e6e401984P3 participant_share: 00e95d59dd0d46b0e303e500b62b7ccb0e555d49f5b849f5e748c071da8c0dbc// Signer round one outputsP1 hiding_nonce_randomness: 7ea5ed09af19f6ff21040c07ec2d2adbd35b759da5a401d4c99dd26b82391cb2P1 binding_nonce_randomness: 47acab018f116020c10cb9b9abdc7ac10aae1b48ca6e36dc15acb6ec9be5cdc5P1 hiding_nonce: 841d3a6450d7580b4da83c8e618414d0f024391f2aeb511d7579224420aa81f0P1 binding_nonce: 8d2624f532af631377f33cf44b5ac5f849067cae2eacb88680a31e77c79b5a80P1 hiding_nonce_commitment: 03c699af97d26bb4d3f05232ec5e1938c12f1e6ae97643c8f8f11c9820303f1904P1 binding_nonce_commitment: 02fa2aaccd51b948c9dc1a325d77226e98a5a3fe65fe9ba213761a60123040a45eP1 binding_factor_input: 02f37c34b66ced1fb51c34a90bdae006901f10625cc06c4f64663b0eae87d87b4fff9b5210ffbb3c07a73a7c8935be4a8c62cf015f6cf7ade6efac09a6513540fc3f5a816aaebc2114a811a415d7a55db7c5cbc1cf27183e79dd9def941b5d48010000000000000000000000000000000000000000000000000000000000000001P1 binding_factor: 3e08fe561e075c653cbfd46908a10e7637c70c74f0a77d5fd45d1a750c739ec6P3 hiding_nonce_randomness: e6cc56ccbd0502b3f6f831d91e2ebd01c4de0479e0191b66895a4ffd9b68d544P3 binding_nonce_randomness: 7203d55eb82a5ca0d7d83674541ab55f6e76f1b85391d2c13706a89a064fd5b9P3 hiding_nonce: 2b19b13f193f4ce83a399362a90cdc1e0ddcd83e57089a7af0bdca71d47869b2P3 binding_nonce: 7a443bde83dc63ef52dda354005225ba0e553243402a4705ce28ffaafe0f5b98P3 hiding_nonce_commitment: 03077507ba327fc074d2793955ef3410ee3f03b82b4cdc2370f71d865beb926ef6P3 binding_nonce_commitment: 02ad53031ddfbbacfc5fbda3d3b0c2445c8e3e99cbc4ca2db2aa283fa68525b135P3 binding_factor_input: 02f37c34b66ced1fb51c34a90bdae006901f10625cc06c4f64663b0eae87d87b4fff9b5210ffbb3c07a73a7c8935be4a8c62cf015f6cf7ade6efac09a6513540fc3f5a816aaebc2114a811a415d7a55db7c5cbc1cf27183e79dd9def941b5d48010000000000000000000000000000000000000000000000000000000000000003P3 binding_factor: 93f79041bb3fd266105be251adaeb5fd7f8b104fb554a4ba9a0becea48ddbfd7// Signer round two outputsP1 sig_share: c4fce1775a1e141fb579944166eab0d65eefe7b98d480a569bbbfcb14f91c197P3 sig_share: 0160fd0d388932f4826d2ebcd6b9eaba734f7c71cf25b4279a4ca2581e47b18dsig: 0205b6d04d3774c8929413e3c76024d54149c372d57aae62574ed74319b5ea14d0c65dde8492a7471437e6c2fe3da49b90d23f642b5c6dbe7e36089f096dd97324