doc: Add RFC documents

1 files changed, 2436 insertions, 0 deletions

diff --git a/doc/rfc/rfc9591.txt b/doc/rfc/rfc9591.txt
new file mode 100644
index 0000000..0cb2058
--- /dev/null
+++ b/doc/rfc/rfc9591.txt
@@ -0,0 +1,2436 @@
+
+
+
+
+Internet Research Task Force (IRTF)                          D. Connolly
+Request for Comments: 9591                              Zcash Foundation
+Category: Informational                                         C. Komlo
+ISSN: 2070-1721                 University of Waterloo, Zcash Foundation
+                                                             I. Goldberg
+                                                  University of Waterloo
+                                                              C. A. Wood
+                                                              Cloudflare
+                                                               June 2024
+
+
+  The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for
+                      Two-Round Schnorr Signatures
+
+Abstract
+
+   This document specifies the Flexible Round-Optimized Schnorr
+   Threshold (FROST) signing protocol.  FROST signatures can be issued
+   after a threshold number of entities cooperate to compute a
+   signature, allowing for improved distribution of trust and redundancy
+   with respect to a secret key.  FROST depends only on a prime-order
+   group and cryptographic hash function.  This document specifies a
+   number of ciphersuites to instantiate FROST using different prime-
+   order groups and hash functions.  This document is a product of the
+   Crypto Forum Research Group (CFRG) in the IRTF.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Research Task Force
+   (IRTF).  The IRTF publishes the results of Internet-related research
+   and development activities.  These results might not be suitable for
+   deployment.  This RFC represents the consensus of the Crypto Forum
+   Research Group of the Internet Research Task Force (IRTF).  Documents
+   approved for publication by the IRSG are not candidates for any level
+   of Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9591.
+
+Copyright Notice
+
+   Copyright (c) 2024 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions and Definitions
+   3.  Cryptographic Dependencies
+     3.1.  Prime-Order Group
+     3.2.  Cryptographic Hash Function
+   4.  Helper Functions
+     4.1.  Nonce Generation
+     4.2.  Polynomials
+     4.3.  List Operations
+     4.4.  Binding Factors Computation
+     4.5.  Group Commitment Computation
+     4.6.  Signature Challenge Computation
+   5.  Two-Round FROST Signing Protocol
+     5.1.  Round One - Commitment
+     5.2.  Round Two - Signature Share Generation
+     5.3.  Signature Share Aggregation
+     5.4.  Identifiable Abort
+   6.  Ciphersuites
+     6.1.  FROST(Ed25519, SHA-512)
+     6.2.  FROST(ristretto255, SHA-512)
+     6.3.  FROST(Ed448, SHAKE256)
+     6.4.  FROST(P-256, SHA-256)
+     6.5.  FROST(secp256k1, SHA-256)
+     6.6.  Ciphersuite Requirements
+   7.  Security Considerations
+     7.1.  Side-Channel Mitigations
+     7.2.  Optimizations
+     7.3.  Nonce Reuse Attacks
+     7.4.  Protocol Failures
+     7.5.  Removing the Coordinator Role
+     7.6.  Input Message Hashing
+     7.7.  Input Message Validation
+   8.  IANA Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Appendix A.  Schnorr Signature Encoding
+   Appendix B.  Schnorr Signature Generation and Verification for
+           Prime-Order Groups
+   Appendix C.  Trusted Dealer Key Generation
+     C.1.  Shamir Secret Sharing
+       C.1.1.  Additional Polynomial Operations
+     C.2.  Verifiable Secret Sharing
+   Appendix D.  Random Scalar Generation
+     D.1.  Rejection Sampling
+     D.2.  Wide Reduction
+   Appendix E.  Test Vectors
+     E.1.  FROST(Ed25519, SHA-512)
+     E.2.  FROST(Ed448, SHAKE256)
+     E.3.  FROST(ristretto255, SHA-512)
+     E.4.  FROST(P-256, SHA-256)
+     E.5.  FROST(secp256k1, SHA-256)
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   Unlike signatures in a single-party setting, threshold signatures
+   require cooperation among a threshold number of signing participants,
+   each holding a share of a common private key.  The security of
+   threshold schemes in general assumes that an adversary can corrupt
+   strictly fewer than a threshold number of signer participants.
+
+   This document specifies the Flexible Round-Optimized Schnorr
+   Threshold (FROST) signing protocol based on the original work in
+   [FROST20].  FROST reduces network overhead during threshold signing
+   operations while employing a novel technique to protect against
+   forgery attacks applicable to prior Schnorr-based threshold signature
+   constructions.  FROST requires two rounds to compute a signature.
+   Single-round signing variants based on [FROST20] are out of scope.
+
+   FROST depends only on a prime-order group and cryptographic hash
+   function.  This document specifies a number of ciphersuites to
+   instantiate FROST using different prime-order groups and hash
+   functions.  Two ciphersuites can be used to produce signatures that
+   are compatible with Edwards-Curve Digital Signature Algorithm (EdDSA)
+   variants Ed25519 and Ed448 as specified in [RFC8032], i.e., the
+   signatures can be verified with a verifier that is compliant with
+   [RFC8032].  However, unlike EdDSA, the signatures produced by FROST
+   are not deterministic, since deriving nonces deterministically allows
+   for a complete key-recovery attack in multi-party, discrete
+   logarithm-based signatures.
+
+   Key generation for FROST signing is out of scope for this document.
+   However, for completeness, key generation with a trusted dealer is
+   specified in Appendix C.
+
+   This document represents the consensus of the Crypto Forum Research
+   Group (CFRG).  It is not an IETF product and is not a standard.
+
+2.  Conventions and Definitions
+
+   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 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   The following notation is used throughout the document.
+
+   byte:  A sequence of eight bits.
+
+   random_bytes(n):  Outputs n bytes, sampled uniformly at random using
+      a cryptographically secure pseudorandom number generator (CSPRNG).
+
+   count(i, L):  Outputs the number of times the element i is
+      represented in the list L.
+
+   len(l):  Outputs the length of list l, e.g., len([1,2,3]) = 3.
+
+   reverse(l):  Outputs the list l in reverse order, e.g.,
+      reverse([1,2,3]) = [3,2,1].
+
+   range(a, b):  Outputs a list of integers from a to b-1 in ascending
+      order, e.g., range(1, 4) = [1,2,3].
+
+   pow(a, b):  Outputs the result, a Scalar, of a to the power of b,
+      e.g., pow(2, 3) = 8 modulo the relevant group order p.
+
+   ||:  Denotes concatenation of byte strings, i.e., x || y denotes the
+      byte string x, immediately followed by the byte string y, with no
+      extra separator, yielding xy.
+
+   nil:  Denotes an empty byte string.
+
+   Unless otherwise stated, we assume that secrets are sampled uniformly
+   at random using a CSPRNG; see [RFC4086] for additional guidance on
+   the generation of random numbers.
+
+3.  Cryptographic Dependencies
+
+   FROST signing depends on the following cryptographic constructs:
+
+   *  Prime-order group (Section 3.1)
+
+   *  Cryptographic hash function (Section 3.2)
+
+   The following sections describe these constructs in more detail.
+
+3.1.  Prime-Order Group
+
+   FROST depends on an abelian group of prime order p.  We represent
+   this group as the object G that additionally defines helper functions
+   described below.  The group operation for G is addition + with
+   identity element I.  For any elements A and B of the group G, A + B =
+   B + A is also a member of G.  Also, for any A in G, there exists an
+   element -A such that A + (-A) = (-A) + A = I.  For convenience, we
+   use - to denote subtraction, e.g., A - B = A + (-B).  Integers, taken
+   modulo the group order p, are called "Scalars"; arithmetic operations
+   on Scalars are implicitly performed modulo p.  Since p is prime,
+   Scalars form a finite field.  Scalar multiplication is equivalent to
+   the repeated application of the group operation on an element A with
+   itself r-1 times, denoted as ScalarMult(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 or Scalar addition, depending on the type of the
+   operands.)  For any element A, ScalarMult(A, p) = I.  We denote B as
+   a fixed generator of the group.  Scalar base multiplication is
+   equivalent to the repeated application of the group operation on B
+   with itself r-1 times, denoted as ScalarBaseMult(r).  The set of
+   Scalars corresponds to GF(p), which we refer to as the Scalar field.
+   It is assumed that group element addition, negation, and equality
+   comparison can be efficiently computed for arbitrary group elements.
+
+   This document uses types Element and Scalar to denote elements of the
+   group G and its set of Scalars, respectively.  We denote Scalar(x) as
+   the conversion of integer input x to the corresponding Scalar value
+   with the same numeric value.  For example, Scalar(1) yields a Scalar
+   representing the value 1.  Moreover, we use the type NonZeroScalar to
+   denote a Scalar value that is not equal to zero, i.e., Scalar(0).  We
+   denote equality comparison of these types as == and assignment of
+   values by =. When comparing Scalar values, e.g., for the purposes of
+   sorting lists of Scalar values, the least nonnegative representation
+   mod p is used.
+
+   We now detail a number of member functions that can be invoked on G.
+
+   Order():  Outputs the order of G (i.e., p).
+
+   Identity():  Outputs the identity Element of the group (i.e., I).
+
+   RandomScalar():  Outputs a random Scalar element in GF(p), i.e., a
+      random Scalar in [0, p - 1].
+
+   ScalarMult(A, k):  Outputs the Scalar multiplication between Element
+      A and Scalar k.
+
+   ScalarBaseMult(k):  Outputs the Scalar multiplication between Scalar
+      k and the group generator B.
+
+   SerializeElement(A):  Maps an Element A to a canonical byte array buf
+      of fixed length Ne.  This function raises an error if A is the
+      identity element of the group.
+
+   DeserializeElement(buf):  Attempts to map a byte array buf to an
+      Element A and fails if the input is not the valid canonical byte
+      representation of an element of the group.  This function raises
+      an error if deserialization fails or if A is the identity element
+      of the group; see Section 6 for group-specific input validation
+      steps.
+
+   SerializeScalar(s):  Maps a Scalar s to a canonical byte array buf of
+      fixed length Ns.
+
+   DeserializeScalar(buf):  Attempts to map a byte array buf to a Scalar
+      s.  This function raises an error if deserialization fails; see
+      Section 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 that SHOULD be used in
+   practice, see Section 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.  See Section 6 for more details about each.
+
+4.  Helper Functions
+
+   Beyond the core dependencies, the protocol in this document depends
+   on the following helper operations:
+
+   *  Nonce generation (Section 4.1);
+
+   *  Polynomials (Section 4.2);
+
+   *  List operations (Section 4.3);
+
+   *  Binding factors computation (Section 4.4);
+
+   *  Group commitment computation (Section 4.5); and
+
+   *  Signature challenge computation (Section 4.6).
+
+   The following sections describe these operations in more detail.
+
+4.1.  Nonce Generation
+
+   To hedge against a bad random number generator (RNG) that outputs
+   predictable values, nonces are generated with the nonce_generate
+   function by combining fresh randomness with the secret key as input
+   to a domain-separated hash function built from the ciphersuite hash
+   function H.  This domain-separated hash function is denoted as H3.
+   This function always samples 32 bytes of fresh randomness to ensure
+   that the probability of nonce reuse is at most 2^-128 as long as no
+   more than 2^64 signatures are computed by a given signing
+   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 the highest-degree coefficient is in the
+   last position.  For example, the polynomial x^2 + 2x + 3 has degree 2
+   and is represented as a list of three coefficients [3, 2, 1].  A
+   point on the polynomial f is a tuple (x, y), where y = f(x).
+
+   The function derive_interpolating_value derives a value that is used
+   for polynomial interpolation.  It is provided a list of x-coordinates
+   as input, each of which cannot 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
+   produced during the FROST protocol.  The following function encodes a
+   list of participant commitments 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
+   commitment 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.
+   - 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 defined naively and
+   scales linearly relative to the number of signers.  For improved
+   performance, the group commitment can be computed using multi-
+   exponentiation techniques 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.  Two-Round FROST Signing Protocol
+
+   This section describes the two-round FROST signing protocol for
+   producing Schnorr signatures.  The protocol is configured to run with
+   a selection of NUM_PARTICIPANTS signer participants and a
+   Coordinator.  NUM_PARTICIPANTS is a positive and non-zero integer
+   that MUST be at least MIN_PARTICIPANTS, but MUST NOT be larger than
+   MAX_PARTICIPANTS, where MIN_PARTICIPANTS <= MAX_PARTICIPANTS and
+   MIN_PARTICIPANTS is a positive and non-zero integer.  Additionally,
+   MAX_PARTICIPANTS MUST be a positive integer less than the group
+   order.  A signer participant, or simply "participant", is an entity
+   that is trusted to hold and use a signing key share.  The Coordinator
+   is an entity with the following responsibilities:
+
+   1.  Determining the participants that will participate (at least
+       MIN_PARTICIPANTS in number);
+
+   2.  Coordinating rounds (receiving and forwarding inputs among
+       participants);
+
+   3.  Aggregating signature shares output by each participant; and
+
+   4.  Publishing the resulting signature.
+
+   FROST assumes that the Coordinator and the set of signer participants
+   are chosen externally to the protocol.  Note that it is possible to
+   deploy the protocol without designating a single Coordinator; see
+   Section 7.5 for more information.
+
+   FROST produces signatures that can be verified as if they were
+   produced from a single signer using a signing key s with
+   corresponding public key PK, where s is a Scalar value and PK =
+   G.ScalarBaseMult(s).  As a threshold signing protocol, the group
+   signing key s is Shamir secret-shared amongst each of the
+   MAX_PARTICIPANTS participants and is used to produce signatures; see
+   Appendix C.1 for more information about Shamir secret sharing.  In
+   particular, FROST assumes each participant is configured with the
+   following information:
+
+   *  An identifier, which is a NonZeroScalar value denoted as i in the
+      range [1, MAX_PARTICIPANTS] and MUST be distinct from the
+      identifier of every other participant.
+
+   *  A signing key sk_i, which is a Scalar value representing the i-th
+      Shamir secret share of the group signing key s.  In particular,
+      sk_i is the value f(i) on a secret polynomial f of degree
+      (MIN_PARTICIPANTS - 1), where s is f(0).  The public key
+      corresponding to this signing key share is PK_i =
+      G.ScalarBaseMult(sk_i).
+
+   Additionally, the Coordinator and each participant are configured
+   with common group information, denoted as "group info," which
+   consists of the following:
+
+   *  Group public key, which is an Element in G denoted as PK.
+
+   *  Public keys PK_i for each participant, which are Element values in
+      G denoted as PK_i for each i in [1, MAX_PARTICIPANTS].
+
+   This document does not specify how this information, including the
+   signing key shares, are configured and distributed to participants.
+   In general, two configuration mechanisms are possible: one that
+   requires a single trusted dealer and one that requires performing a
+   distributed key generation protocol.  We highlight the key generation
+   mechanism by a trusted dealer in Appendix C for reference.
+
+   FROST requires two rounds to complete.  In the first round,
+   participants generate and publish one-time-use commitments to be used
+   in the second round.  In the second round, each participant produces
+   a share of the signature over the Coordinator-chosen message and the
+   other participant commitments.  After the second round is completed,
+   the Coordinator aggregates the signature shares to produce a final
+   signature.  The Coordinator SHOULD abort the protocol if the
+   signature is invalid; see Section 5.4 for more information about
+   dealing with invalid signatures and misbehaving participants.  This
+   complete interaction (without being aborted) is shown in Figure 1.
+
+           (group info)            (group info,     (group info,
+               |               signing key share)   signing key share)
+               |                         |                |
+               v                         v                v
+           Coordinator               Signer-1   ...   Signer-n
+       ------------------------------------------------------------
+      signing request
+   ------------>
+               |
+         == Round 1 (Commitment) ==
+               | participant commitment |                 |
+               |<-----------------------+                 |
+               |          ...                             |
+               | participant commitment            (commit state) ==\
+               |<-----------------------------------------+         |
+                                                                    |
+         == Round 2 (Signature Share Generation) ==                 |
+      message
+   ------------>
+               |                                                    |
+               |   participant input    |                 |         |
+               +------------------------>                 |         |
+               |     signature share    |                 |         |
+               |<-----------------------+                 |         |
+               |          ...                             |         |
+               |    participant input                     |         |
+               +------------------------------------------>         /
+               |     signature share                      |<=======/
+               <------------------------------------------+
+               |
+         == Aggregation ==
+               |
+     signature |
+   <-----------+
+
+                     Figure 1: FROST Protocol Overview
+
+   Details for round one are described in Section 5.1 and details for
+   round two are described in Section 5.2.  Note that each participant
+   persists some state between the two rounds; this state is deleted as
+   described in Section 5.2.  The final Aggregation step is described in
+   Section 5.3.
+
+   FROST assumes that all inputs to each round, especially those that
+   are received over the network, are validated before use.  In
+   particular, this means that any value of type Element or Scalar
+   received over the network MUST be deserialized using
+   DeserializeElement and DeserializeScalar, respectively, as these
+   functions perform the necessary input validation steps.
+   Additionally, all messages sent over the wire MUST be encoded using
+   their respective functions, e.g., Scalars and Elements are encoded
+   using SerializeScalar and SerializeElement.
+
+   FROST assumes reliable message delivery between the Coordinator and
+   participants in order for the protocol to complete.  An attacker
+   masquerading as another participant will result only in an invalid
+   signature; see Section 7.  However, in order to identify misbehaving
+   participants, we assume that the network channel is additionally
+   authenticated; confidentiality is not required.
+
+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 the commit
+   function below.  Note that this function invokes nonce_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 outputs nonce and comm from participant P_i are both stored
+   locally and kept for use in the second round.  The nonce value is
+   secret and MUST NOT be shared, whereas the public output comm is sent
+   to the Coordinator.  The nonce values produced by this function MUST
+   NOT be used in more than one invocation of sign, and the nonces MUST
+   be generated from 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).  Signers additionally require
+   locally held data, specifically their private key and the nonces
+   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 participant MUST validate the inputs
+   before processing the Coordinator's request.  In particular, the
+   signer MUST validate commitment_list, deserializing each group
+   Element in the list using DeserializeElement from Section 3.1.  If
+   deserialization fails, the signer MUST abort the protocol.  Moreover,
+   each participant MUST ensure that its identifier and commitments
+   (from the first round) appear in commitment_list.  Applications that
+   restrict participants from processing arbitrary input messages are
+   also required to perform relevant application-layer input validation
+   checks; see Section 7.7 for more details.
+
+   Upon receipt and successful input validation, each signer then runs
+   the following procedure 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
+   sends these shares back to the Coordinator.  Each participant MUST
+   delete the nonce and corresponding commitment after completing sign
+   and MUST NOT use the nonce as input more than once to sign.
+
+   Note that the lambda_i value derived during this procedure does not
+   change across FROST signing operations for the same signing group.
+   As such, participants can 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 Coordinator MUST validate
+   each signature share using DeserializeScalar.  If validation fails,
+   the Coordinator MUST abort the protocol, as the resulting signature
+   will be invalid.  If all signature shares are valid, the Coordinator
+   aggregates them to produce the final signature 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 encoding of this signature is specified in Section 6.
+
+   The Coordinator SHOULD verify this signature using the group public
+   key before publishing or releasing the signature.  Signature
+   verification is as specified for the corresponding ciphersuite; see
+   Section 6 for details.  The aggregate signature will verify
+   successfully if all signature shares are valid.  Moreover, subsets of
+   valid signature shares will not yield a valid aggregate signature
+   themselves.
+
+   If the aggregate signature verification fails, the Coordinator MAY
+   verify each signature share individually to identify and act on
+   misbehaving participants.  The mechanism for acting on a misbehaving
+   participant is out of scope for this specification; see Section 5.4
+   for more information about dealing with invalid signatures and
+   misbehaving participants.
+
+   The function for verifying a signature share, denoted as
+   verify_signature_share, is described below.  Recall that the
+   Coordinator is configured with "group info" that contains the group
+   public key PK and public keys PK_i for each participant.  The
+   group_public_key and PK_i function arguments MUST 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
+   and verifying the signature under the group public key.  However,
+   since the aggregate signature is valid if all signature shares are
+   valid, this order of operations 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 the protocol honestly in order to generate a valid
+   signature.  When the signing protocol does not produce a valid
+   signature, the Coordinator SHOULD abort; see Section 7 for 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) on the signing protocol by contributing
+   malformed signature shares or refusing to participate.  Identifying
+   misbehaving participants that produce invalid shares can be done by
+   checking signature shares from each participant using
+   verify_signature_share as described in Section 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 shares as described in Section 5.3.
+   FROST does not provide accommodations for identifying participants
+   that refuse to participate, though applications are assumed to detect
+   when participants fail to engage in the signing protocol.
+
+   In both cases, preventing this type of attack requires the
+   Coordinator to identify misbehaving participants such that
+   applications can take corrective action.  The mechanism for 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 allowed participants in future runs of
+   FROST.
+
+6.  Ciphersuites
+
+   A FROST ciphersuite must specify the underlying prime-order group
+   details and cryptographic hash function.  Each ciphersuite is denoted
+   as (Group, Hash), e.g., (ristretto255, SHA-512).  This section
+   contains some ciphersuites.  Each ciphersuite also includes a context
+   string, denoted as contextString, which is an ASCII string literal
+   (with no terminating NUL character).
+
+   The RECOMMENDED ciphersuite is (ristretto255, SHA-512) as described
+   in Section 6.2.  The (Ed25519, SHA-512) and (Ed448, SHAKE256)
+   ciphersuites are included for compatibility with Ed25519 and Ed448 as
+   defined in [RFC8032].
+
+   The DeserializeElement and DeserializeScalar functions instantiated
+   for a particular prime-order group corresponding to a ciphersuite
+   MUST adhere to the description in Section 3.1.  Validation steps for
+   these functions are described for each of the ciphersuites below.
+   Future ciphersuites MUST describe how input validation is done for
+   DeserializeElement and DeserializeScalar.
+
+   Each ciphersuite includes explicit instructions for verifying
+   signatures produced by FROST.  Note that these instructions are
+   equivalent to those produced by a single participant.
+
+   Each ciphersuite adheres to the requirements in Section 6.6.  Future
+   ciphersuites MUST also adhere to these requirements.
+
+6.1.  FROST(Ed25519, SHA-512)
+
+   This ciphersuite uses edwards25519 for the Group and SHA-512 for the
+   hash function H meant to produce Ed25519-compliant signatures as
+   specified in Section 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^252 + 27742317777372353535851937790883648493
+         (see [RFC7748]).
+
+      Identity():  As defined in [RFC7748].
+
+      RandomScalar():  Implemented by returning a uniformly random
+         Scalar in the range [0, G.Order() - 1].  Refer to Appendix 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 group identity element.
+
+      DeserializeElement(buf):  Implemented as specified in [RFC8032],
+         Section 5.1.3.  Additionally, this function validates that the
+         resulting element is not the group identity element and is in
+         the prime-order subgroup.  If any of these checks fail,
+         deserialization returns an error.  The latter check can be
+         implemented by multiplying the resulting point by the order of
+         the group and checking that the result is the identity element.
+         Note that optimizations for this check exist; see [Pornin22].
+
+      SerializeScalar(s):  Implemented by outputting the little-endian
+         32-byte encoding of the Scalar value with the top three bits
+         set to zero.
+
+      DeserializeScalar(buf):  Implemented by attempting to deserialize
+         a Scalar from a little-endian 32-byte string.  This function
+         can fail if the input does not represent a Scalar in the range
+         [0, G.Order() - 1].  Note that this means the top three bits of
+         the input MUST 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 digest as a little-endian integer, and
+         reducing the resulting integer modulo 2^252 +
+         27742317777372353535851937790883648493.
+
+      H2(m):  Implemented by computing H(m), interpreting the 64-byte
+         digest as a little-endian integer, and reducing the resulting
+         integer modulo 2^252 + 27742317777372353535851937790883648493.
+
+      H3(m):  Implemented by computing H(contextString || "nonce" || m),
+         interpreting the 64-byte digest as a little-endian integer, and
+         reducing the resulting integer modulo 2^252 +
+         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 in Section 5.1.7 of [RFC8032]
+   with the constraint that implementations MUST 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 in Appendix A.
+
+6.2.  FROST(ristretto255, SHA-512)
+
+   This ciphersuite uses ristretto255 for the Group and SHA-512 for the
+   hash function H.  The value of the contextString parameter is "FROST-
+   RISTRETTO255-SHA512-v1".
+
+   Group:  ristretto255 [RISTRETTO], where Ne = 32 and Ns = 32.
+
+      Order():  Return 2^252 + 27742317777372353535851937790883648493
+         (see [RISTRETTO]).
+
+      Identity():  As defined in [RISTRETTO].
+
+      RandomScalar():  Implemented by returning a uniformly random
+         Scalar in the range [0, G.Order() - 1].  Refer to Appendix D
+         for implementation guidance.
+
+      SerializeElement(A):  Implemented using the "Encode" function from
+         [RISTRETTO].  Additionally, this function validates that the
+         input element is not the group identity element.
+
+      DeserializeElement(buf):  Implemented using the "Decode" function
+         from [RISTRETTO].  Additionally, this function validates that
+         the resulting element is not the group identity 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 of the Scalar value with the top three bits
+         set to zero.
+
+      DeserializeScalar(buf):  Implemented by attempting to deserialize
+         a Scalar from a little-endian 32-byte string.  This function
+         can fail if the input does not represent a Scalar in the range
+         [0, G.Order() - 1].  Note that this means the top three bits of
+         the input MUST be zero.
+
+   Hash (H):  SHA-512, which has 64 bytes of output.
+
+      H1(m):  Implemented by computing H(contextString || "rho" || m)
+         and mapping the output to a Scalar as described in [RISTRETTO],
+         Section 4.4.
+
+      H2(m):  Implemented by computing H(contextString || "chal" || m)
+         and mapping the output to a Scalar as described in [RISTRETTO],
+         Section 4.4.
+
+      H3(m):  Implemented by computing H(contextString || "nonce" || m)
+         and mapping the output 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 in Appendix B.
+
+   Canonical signature encoding is as specified in Appendix A.
+
+6.3.  FROST(Ed448, SHAKE256)
+
+   This ciphersuite uses edwards448 for the Group and SHAKE256 for the
+   hash function H meant to produce Ed448-compliant signatures as
+   specified in Section 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
+   context string as is allowed for Ed448 in [RFC8032], and always sets
+   the [RFC8032] context string to the empty string.  The value of the
+   (internal to FROST) contextString parameter is "FROST-
+   ED448-SHAKE256-v1".
+
+   Group:  edwards448 [RFC8032], where Ne = 57 and Ns = 57.
+
+      Order():  Return 2^446 - 13818066809895115352007386748515426880336
+         692474882178609894547503885.
+
+      Identity():  As defined in [RFC7748].
+
+      RandomScalar():  Implemented by returning a uniformly random
+         Scalar in the range [0, G.Order() - 1].  Refer to Appendix 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 group identity element.
+
+      DeserializeElement(buf):  Implemented as specified in [RFC8032],
+         Section 5.2.3.  Additionally, this function validates that the
+         resulting element is not the group identity element and is in
+         the prime-order subgroup.  If any of these checks fail,
+         deserialization returns an error.  The latter check can be
+         implemented by multiplying the resulting point by the order of
+         the group and checking that the result is the identity element.
+         Note that optimizations for this check exist; see [Pornin22].
+
+      SerializeScalar(s):  Implemented by outputting the little-endian
+         57-byte encoding of the Scalar value.
+
+      DeserializeScalar(buf):  Implemented by attempting to deserialize
+         a Scalar from a little-endian 57-byte string.  This function
+         can fail if the input does not represent 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 the 114-byte digest as a little-endian integer,
+         and reducing the resulting integer modulo 2^446 - 1381806680989
+         5115352007386748515426880336692474882178609894547503885.
+
+      H2(m):  Implemented by computing H("SigEd448" || 0 || 0 || m),
+         interpreting the 114-byte digest as a little-endian integer,
+         and reducing the resulting integer modulo 2^446 - 1381806680989
+         5115352007386748515426880336692474882178609894547503885.
+
+      H3(m):  Implemented by computing H(contextString || "nonce" || m),
+         interpreting the 114-byte digest as a little-endian integer,
+         and reducing the resulting integer modulo 2^446 - 1381806680989
+         5115352007386748515426880336692474882178609894547503885.
+
+      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 in Section 5.2.7 of [RFC8032]
+   with the constraint that implementations MUST 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 in Appendix A.
+
+6.4.  FROST(P-256, SHA-256)
+
+   This ciphersuite uses P-256 for the Group and SHA-256 for the hash
+   function H.  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 0xffffffff00000000ffffffffffffffffbce6faada7179e8
+         4f3b9cac2fc632551.
+
+      Identity():  As defined in [x9.62].
+
+      RandomScalar():  Implemented by returning a uniformly random
+         Scalar in the range [0, G.Order() - 1].  Refer to Appendix D
+         for implementation guidance.
+
+      SerializeElement(A):  Implemented using the compressed Elliptic-
+         Curve-Point-to-Octet-String method according to [SEC1],
+         yielding a 33-byte output.  Additionally, this function
+         validates that the input element is not the group identity
+         element.
+
+      DeserializeElement(buf):  Implemented by attempting to deserialize
+         a 33-byte input string to a 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 are in the correct range,
+         that the point is on the curve, and that the point is not the
+         point at infinity.  (As noted in the specification, validation
+         of the point order 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 conversion according to [SEC1].
+
+      DeserializeScalar(buf):  Implemented by attempting to deserialize
+         a Scalar from a 32-byte string using Octet-String-to-Field-
+         Element from [SEC1].  This function can fail if the input 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) using expand_message_xmd with SHA-256 with
+         parameters DST = contextString || "rho", F set to the Scalar
+         field, p set to G.Order(), m = 1, and L = 48.
+
+      H2(m):  Implemented as hash_to_field(m, 1) (see [HASH-TO-CURVE],
+         Section 5.2) using expand_message_xmd with SHA-256 with
+         parameters DST = contextString || "chal", F set to the Scalar
+         field, p set to G.Order(), m = 1, and L = 48.
+
+      H3(m):  Implemented as hash_to_field(m, 1) (see [HASH-TO-CURVE],
+         Section 5.2) using expand_message_xmd with SHA-256 with
+         parameters DST = contextString || "nonce", F set to the Scalar
+         field, p set to G.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 in Appendix B.
+
+   Canonical signature encoding is as specified in Appendix A.
+
+6.5.  FROST(secp256k1, SHA-256)
+
+   This ciphersuite uses secp256k1 for the Group and SHA-256 for the
+   hash function H.  The value of the contextString parameter is "FROST-
+   secp256k1-SHA256-v1".
+
+   Group:  secp256k1 [SEC2], where Ne = 33 and Ns = 32.
+
+      Order():  Return 0xfffffffffffffffffffffffffffffffebaaedce6af48a03
+         bbfd25e8cd0364141.
+
+      Identity():  As defined in [SEC2].
+
+      RandomScalar():  Implemented by returning a uniformly random
+         Scalar in the range [0, G.Order() - 1].  Refer to Appendix D
+         for implementation guidance.
+
+      SerializeElement(A):  Implemented using the compressed Elliptic-
+         Curve-Point-to-Octet-String method according to [SEC1],
+         yielding a 33-byte output.  Additionally, this function
+         validates that the input element is not the group identity
+         element.
+
+      DeserializeElement(buf):  Implemented by attempting to deserialize
+         a 33-byte input string to a 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 are in the correct range,
+         the point is on the curve, and the point is not the point at
+         infinity.  (As noted in the specification, validation of the
+         point order 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 conversion according to [SEC1].
+
+      DeserializeScalar(buf):  Implemented by attempting to deserialize
+         a Scalar from a 32-byte string using Octet-String-to-Field-
+         Element from [SEC1].  This function can fail if the input 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) using expand_message_xmd with SHA-256 with
+         parameters DST = contextString || "rho", F set to the Scalar
+         field, p set to G.Order(), m = 1, and L = 48.
+
+      H2(m):  Implemented as hash_to_field(m, 1) (see [HASH-TO-CURVE],
+         Section 5.2) using expand_message_xmd with SHA-256 with
+         parameters DST = contextString || "chal", F set to the Scalar
+         field, p set to G.Order(), m = 1, and L = 48.
+
+      H3(m):  Implemented as hash_to_field(m, 1) (see [HASH-TO-CURVE],
+         Section 5.2) using expand_message_xmd with SHA-256 with
+         parameters DST = contextString || "nonce", F set to the Scalar
+         field, p set to G.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 in Appendix B.
+
+   Canonical signature encoding is as specified in Appendix A.
+
+6.6.  Ciphersuite Requirements
+
+   Future documents that introduce new ciphersuites MUST adhere to the
+   following requirements.
+
+   1.  H1, H2, and H3 all have output distributions that are close to
+       (indistinguishable from) the uniform distribution.
+
+   2.  All hash functions MUST 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 group MUST be of prime order and all deserialization
+       functions MUST 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.  Security Considerations
+
+   A security analysis of FROST is documented in [FROST20] and
+   [StrongerSec22].  At a high level, FROST provides security against
+   Existential Unforgeability Under Chosen Message Attacks (EUF-CMA) as
+   defined in [StrongerSec22].  To satisfy this requirement, the
+   ciphersuite needs to adhere to the requirements in Section 6.6 and
+   the following assumptions must hold.
+
+   *  The signer key shares are generated and distributed securely,
+      e.g., via a trusted dealer that performs key generation (see
+      Appendix C.2) or through a distributed key generation protocol.
+
+   *  The Coordinator and at most (MIN_PARTICIPANTS-1) participants may
+      be corrupted.
+
+   Note that the Coordinator is not trusted with any private
+   information, and communication at the time of signing can be
+   performed over a public channel as long as it is authenticated and
+   reliable.
+
+   FROST provides security against DoS attacks under the following
+   assumptions:
+
+   *  The Coordinator does not perform a DoS attack.
+
+   *  The Coordinator identifies misbehaving participants such that they
+      can be removed from future invocations of FROST.  The Coordinator
+      may also abort upon detecting a misbehaving participant to ensure
+      that invalid signatures are not produced.
+
+   FROST does not aim to achieve the following goals:
+
+   *  Post-quantum security.  FROST, like plain Schnorr signatures,
+      requires the hardness of the Discrete Logarithm Problem.
+
+   *  Robustness.  Preventing DoS attacks against misbehaving
+      participants requires the Coordinator to identify and act on
+      misbehaving participants; see Section 5.4 for more information.
+      While FROST does not provide robustness, [ROAST] is a wrapper
+      protocol around FROST that does.
+
+   *  Downgrade prevention.  All participants in the protocol are
+      assumed to agree on which algorithms to use.
+
+   *  Metadata protection.  If protection for metadata is desired, a
+      higher-level communication channel can be used to facilitate key
+      generation and signing.
+
+   The rest of this section documents issues particular to
+   implementations or deployments.
+
+7.1.  Side-Channel Mitigations
+
+   Several routines process secret values (nonces, signing keys /
+   shares), and depending on the implementation and deployment
+   environment, mitigating side-channels may be pertinent.  Mitigating
+   these side-channels requires implementing G.ScalarMult(),
+   G.ScalarBaseMult(), G.SerializeScalar(), and G.DeserializeScalar() in
+   constant (value-independent) time.  The various ciphersuites lend
+   themselves differently to specific implementation techniques and ease
+   of achieving side-channel resistance, though ultimately avoiding
+   value-dependent computation or branching is the goal.
+
+7.2.  Optimizations
+
+   [StrongerSec22] presented an optimization to FROST that reduces the
+   total number of Scalar multiplications from 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 of the protocol is the
+   same set of signing participants that produced the signature output
+   by round two.  As such, the optimization is NOT 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 during the first round of signing.  The randomness produced in
+   this procedure MUST be sampled uniformly at random.  The resulting
+   nonces produced via nonce_generate are indistinguishable from values
+   sampled uniformly at random.  This requirement is necessary to avoid
+   replay attacks initiated by other participants that allow for a
+   complete key-recovery attack.  The Coordinator MAY further hedge
+   against nonce reuse attacks by tracking participant nonce commitments
+   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 requiring the 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 simply requires each participant
+   to communicate with all other participants.  We loosely describe 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 performing commit() as is done in the
+   setting where a Coordinator is used.  However, instead of sending the
+   commitment to 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 perform sign().  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 perform verify_signature_share and then
+   aggregate directly.
+
+   The requirements for the underlying network channel remain the same
+   in the setting where all participants play the role of the
+   Coordinator, in that all exchanged messages are public and the
+   channel must be reliable.  However, in the setting where a player
+   attempts to split the view of all other players by sending disjoint
+   values to a subset of players, the signing operation will output an
+   invalid signature.  To avoid this DoS, implementations may wish to
+   define a mechanism where messages are authenticated so that cheating
+   players can be identified 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-hashing MUST 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 is RECOMMENDED that they use the hash function (H)
+   associated with the chosen ciphersuite in a manner similar to how H4
+   is defined.  In particular, a different prefix SHOULD be used to
+   differentiate this pre-hash from H4.  For example, if a fictional
+   protocol Quux decided to pre-hash its input messages, one possible
+   way to do so is via H(contextString || "Quux-pre-hash" || m).
+
+7.7.  Input Message Validation
+
+   Message validation varies by application.  For example, some
+   applications may require that participants only process messages of a
+   certain structure.  In digital currency applications, wherein
+   multiple participants may collectively sign a transaction, it is
+   reasonable to require each participant to check that the input
+   message is a syntactically valid transaction.
+
+   As another example, some applications may require that participants
+   only process messages with permitted content according to some
+   policy.  In digital currency applications, this might mean that a
+   transaction being signed is allowed and intended by the relevant
+   stakeholders.  Another instance of this type of message validation is
+   in the context of [TLS], wherein implementations may use threshold
+   signing protocols to produce signatures of transcript hashes.  In
+   this setting, signing participants might require the raw TLS
+   handshake messages to validate before computing the transcript hash
+   that is signed.
+
+   In general, input message validation is an application-specific
+   consideration that varies based on the use case and threat model.
+   However, it is RECOMMENDED that applications take additional
+   precautions and validate inputs so that participants do not operate
+   as signing oracles for arbitrary messages.
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+9.  References
+
+9.1.  Normative References
+
+   [HASH-TO-CURVE]
+              Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,
+              and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380,
+              DOI 10.17487/RFC9380, August 2023,
+              <https://www.rfc-editor.org/info/rfc9380>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
+              Signature Algorithm (EdDSA)", RFC 8032,
+              DOI 10.17487/RFC8032, January 2017,
+              <https://www.rfc-editor.org/info/rfc8032>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RISTRETTO]
+              de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I.,
+              Tankersley, G., and F. Valsorda, "The ristretto255 and
+              decaf448 Groups", RFC 9496, DOI 10.17487/RFC9496, December
+              2023, <https://www.rfc-editor.org/info/rfc9496>.
+
+   [SEC1]     Standards for Efficient Cryptography, "SEC 1: Elliptic
+              Curve Cryptography", Version 2.0, May 2009,
+              <https://secg.org/sec1-v2.pdf>.
+
+   [SEC2]     Standards for Efficient Cryptography, "SEC 2: Recommended
+              Elliptic Curve Domain Parameters", Version 2.0, January
+              2010, <https://secg.org/sec2-v2.pdf>.
+
+   [x9.62]    American National Standards Institute, "Public Key
+              Cryptography for the Financial Services Industry: the
+              Elliptic Curve Digital Signature Algorithm (ECDSA)",
+              ANSI X9.62-2005, November 2005.
+
+9.2.  Informative References
+
+   [FeldmanSecretSharing]
+              Feldman, P., "A practical scheme for non-interactive
+              verifiable secret sharing", IEEE, 28th Annual Symposium on
+              Foundations of Computer Science (sfcs 1987),
+              DOI 10.1109/sfcs.1987.4, October 1987,
+              <https://doi.org/10.1109/sfcs.1987.4>.
+
+   [FROST20]  Komlo, C. and I. Goldberg, "FROST: Flexible Round-
+              Optimized Schnorr Threshold Signatures", December 2020,
+              <https://eprint.iacr.org/2020/852.pdf>.
+
+   [MultExp]  Connolly, D. and C. Gouvea, "Speeding up FROST with multi-
+              scalar multiplication", June 2023, <https://zfnd.org/
+              speeding-up-frost-with-multi-scalar-multiplication/>.
+
+   [Pornin22] Pornin, T., "Point-Halving and Subgroup Membership in
+              Twisted Edwards Curves", September 2022,
+              <https://eprint.iacr.org/2022/1164.pdf>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
+              for Security", RFC 7748, DOI 10.17487/RFC7748, January
+              2016, <https://www.rfc-editor.org/info/rfc7748>.
+
+   [ROAST]    Ruffing, T., Ronge, V., Jin, E., Schneider-Bensch, J., and
+              D. Schröder, "ROAST: Robust Asynchronous Schnorr Threshold
+              Signatures", Paper 2022/550, DOI 10.1145/3548606, November
+              2022, <https://eprint.iacr.org/2022/550>.
+
+   [ShamirSecretSharing]
+              Shamir, A., "How to share a secret", Association for
+              Computing Machinery (ACM), Communications of the ACM, Vol.
+              22, Issue 11, pp. 612-613, DOI 10.1145/359168.359176,
+              November 1979, <https://doi.org/10.1145/359168.359176>.
+
+   [StrongerSec22]
+              Bellare, M., Crites, E., Komlo, C., Maller, M., Tessaro,
+              S., and C. Zhu, "Better than Advertised Security for Non-
+              interactive Threshold Signatures",
+              DOI 10.1007/978-3-031-15985-5_18, August 2022,
+              <https://crypto.iacr.org/2022/
+              papers/538806_1_En_18_Chapter_OnlinePDF.pdf>.
+
+   [TLS]      Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+Appendix A.  Schnorr Signature Encoding
+
+   This section describes one possible canonical encoding of FROST
+   signatures.  Using notation from Section 3 of [TLS], the encoding of
+   a FROST signature (R, z) is as follows:
+
+     struct {
+       opaque R_encoded[Ne];
+       opaque z_encoded[Ns];
+     } Signature;
+
+   Where Signature.R_encoded is G.SerializeElement(R),
+   Signature.z_encoded is G.SerializeScalar(z), and G is determined by
+   ciphersuite.
+
+Appendix B.  Schnorr Signature Generation and Verification for Prime-
+             Order Groups
+
+   This section contains descriptions of functions for generating and
+   verifying Schnorr signatures.  It is included to complement the
+   routines present in [RFC8032] for prime-order groups, including
+   ristretto255, P-256, and secp256k1.  The functions for generating and
+   verifying signatures are prime_order_sign and prime_order_verify,
+   respectively.
+
+   The function prime_order_sign produces a Schnorr signature over a
+   message given a full secret signing key as input (as opposed to a key
+   share).
+
+   Inputs:
+   - msg, message to sign, a byte string.
+   - sk, secret key, a Scalar.
+
+   Outputs:
+   - (R, z), a Schnorr signature consisting of an Element R and
+     Scalar z.
+
+   def prime_order_sign(msg, sk):
+     r = G.RandomScalar()
+     R = G.ScalarBaseMult(r)
+     PK = G.ScalarBaseMult(sk)
+     comm_enc = G.SerializeElement(R)
+     pk_enc = G.SerializeElement(PK)
+     challenge_input = comm_enc || pk_enc || msg
+     c = H2(challenge_input)
+     z = r + (c * sk) // Scalar addition and multiplication
+     return (R, z)
+
+   The function prime_order_verify verifies Schnorr signatures with
+   validated inputs.  Specifically, it assumes that the signature R
+   component and public key belong to the prime-order group.
+
+   Inputs:
+   - msg, signed message, a byte string.
+   - sig, a tuple (R, z) output from signature generation.
+   - PK, public key, an Element.
+
+   Outputs:
+   - True if signature is valid, and False otherwise.
+
+   def prime_order_verify(msg, sig = (R, z), PK):
+     comm_enc = G.SerializeElement(R)
+     pk_enc = G.SerializeElement(PK)
+     challenge_input = comm_enc || pk_enc || msg
+     c = H2(challenge_input)
+
+     l = G.ScalarBaseMult(z)
+     r = R + G.ScalarMult(PK, c)
+     return l == r
+
+Appendix C.  Trusted Dealer Key Generation
+
+   One possible key generation mechanism is to depend on a trusted
+   dealer, wherein the dealer generates a group secret s uniformly at
+   random and uses Shamir and Verifiable Secret Sharing
+   [ShamirSecretSharing] as described in Appendices C.1 and C.2 to
+   create secret shares of s, denoted as s_i for i = 1, ...,
+   MAX_PARTICIPANTS, to be sent to all MAX_PARTICIPANTS participants.
+   This operation is specified in the trusted_dealer_keygen algorithm.
+   The mathematical relation between the secret key s and the
+   MAX_PARTICIPANTS secret shares is formalized in the
+   secret_share_combine(shares) algorithm, defined in Appendix C.1.
+
+   The dealer that performs trusted_dealer_keygen is trusted to 1)
+   generate good randomness, 2) delete secret values after distributing
+   shares to each participant, and 3) keep secret values confidential.
+
+   Inputs:
+   - secret_key, a group secret, a Scalar, that MUST be derived from at
+     least Ns bytes of entropy.
+   - MAX_PARTICIPANTS, the number of shares to generate, an integer.
+   - MIN_PARTICIPANTS, the threshold of the secret sharing scheme,
+     an integer.
+
+   Outputs:
+   - participant_private_keys, MAX_PARTICIPANTS shares of the secret
+     key s, each a tuple consisting of the participant identifier
+     (a NonZeroScalar) and the key share (a Scalar).
+   - group_public_key, public key corresponding to the group signing
+     key, an Element.
+   - vss_commitment, a vector commitment of Elements in G, to each of
+     the coefficients in the polynomial defined by secret_key_shares and
+     whose first element is G.ScalarBaseMult(s).
+
+   def trusted_dealer_keygen(
+           secret_key, MAX_PARTICIPANTS, MIN_PARTICIPANTS):
+     # Generate random coefficients for the polynomial
+     coefficients = []
+     for i in range(0, MIN_PARTICIPANTS - 1):
+       coefficients.append(G.RandomScalar())
+     participant_private_keys, coefficients = secret_share_shard(
+         secret_key, coefficients, MAX_PARTICIPANTS)
+     vss_commitment = vss_commit(coefficients):
+     return participant_private_keys, vss_commitment[0], vss_commitment
+
+   It is assumed that the dealer then sends one secret key share to each
+   of the NUM_PARTICIPANTS participants, along with vss_commitment.
+   After receiving their secret key share and vss_commitment,
+   participants MUST abort if they do not have the same view of
+   vss_commitment.  The dealer can use a secure broadcast channel to
+   ensure each participant has a consistent view of this commitment.
+   Furthermore, each participant MUST perform
+   vss_verify(secret_key_share_i, vss_commitment) and abort if the check
+   fails.  The trusted dealer MUST delete the secret_key and
+   secret_key_shares upon completion.
+
+   Use of this method for key generation requires a mutually
+   authenticated secure channel between the dealer and participants to
+   send secret key shares, wherein the channel provides confidentiality
+   and integrity.  Mutually authenticated TLS is one possible deployment
+   option.
+
+C.1.  Shamir Secret Sharing
+
+   In Shamir secret sharing, a dealer distributes a secret Scalar s to n
+   participants in such a way that any cooperating subset of at least
+   MIN_PARTICIPANTS participants can recover the secret.  There are two
+   basic steps in this scheme: 1) splitting a secret into multiple
+   shares and 2) combining shares to reveal the resulting secret.
+
+   This secret sharing scheme works over any field F.  In this
+   specification, F is the Scalar field of the prime-order group G.
+
+   The procedure for splitting a secret into shares is as follows.  The
+   algorithm polynomial_evaluate is defined in Appendix 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
+
+   Let points be the output of this function.  The i-th element in
+   points is the share for the i-th participant, which is the randomly
+   generated polynomial evaluated at coordinate i.  We denote a secret
+   share as the tuple (i, points[i]) and the list of these shares as
+   shares. i MUST never equal 0; recall that f(0) = s, where f is the
+   polynomial defined in a Shamir secret sharing operation.
+
+   The procedure for combining a shares list of length MIN_PARTICIPANTS
+   to recover the secret s is as follows; the algorithm
+   polynomial_interpolate_constant is defined in Appendix 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
+
+C.1.1.  Additional Polynomial Operations
+
+   This section describes two functions.  One function, denoted as
+   polynomial_evaluate, is for evaluating a polynomial f(x) at a
+   particular point x using Horner's method, i.e., computing y = f(x).
+   The other function, polynomial_interpolate_constant, is for
+   recovering the constant term of an interpolating polynomial defined
+   by a set of points.
+
+   The function polynomial_evaluate is defined as follows.
+
+   Inputs:
+   - x, input at which to evaluate the polynomial, a Scalar
+   - coeffs, the polynomial coefficients, a list of Scalars
+
+   Outputs: Scalar result of the polynomial evaluated at input x
+
+   def polynomial_evaluate(x, coeffs):
+     value = Scalar(0)
+     for coeff in reverse(coeffs):
+       value *= x
+       value += coeff
+     return value
+
+   The function polynomial_interpolate_constant is defined as follows.
+
+   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's share with a public
+   commitment to the polynomial f for which the secret s is the constant
+   term.  This check ensures that all participants have a point (their
+   share) on the same polynomial, ensuring that they can reconstruct the
+   correct secret later.
+
+   The procedure for committing to a polynomial f of degree at most
+   MIN_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.  If vss_verify fails, the participant MUST 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
+
+Appendix D.  Random Scalar Generation
+
+   Two popular algorithms for generating a random integer uniformly
+   distributed in the range [0, G.Order() -1] are described in the
+   sections that follow.
+
+D.1.  Rejection Sampling
+
+   Generate a random byte array with Ns bytes and attempt to map to a
+   Scalar by calling DeserializeScalar in constant time.  If it
+   succeeds, return the result.  If it fails, try again with another
+   random byte array, until the procedure succeeds.  Failure to
+   implement DeserializeScalar in constant time can leak information
+   about the underlying corresponding Scalar.
+
+   As an optimization, if the group order is very close to a power of 2,
+   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), then RandomScalar can simply
+   return a uniformly random integer of at most b bits.
+
+D.2.  Wide Reduction
+
+   Generate a random byte array with l = ceil(((3 *
+   ceil(log2(G.Order()))) / 2) / 8) bytes and interpret it as an
+   integer; reduce the integer modulo G.Order() and return the result.
+   See Section 5 of [HASH-TO-CURVE] for the underlying derivation of l.
+
+Appendix E.  Test Vectors
+
+   This section contains test vectors for all ciphersuites listed in
+   Section 6.  All Element and Scalar values are represented in
+   serialized form and encoded in hexadecimal strings.  Signatures are
+   represented as the concatenation of their constituent parts.  The
+   input message to be signed is also encoded as a hexadecimal string.
+
+   Each test vector consists of the following information.
+
+   *  Configuration.  This lists the fixed parameters for the particular
+      instantiation of FROST, including MAX_PARTICIPANTS,
+      MIN_PARTICIPANTS, and NUM_PARTICIPANTS.
+
+   *  Group input parameters.  This lists the group secret key and
+      shared public key, generated by a trusted dealer as described in
+      Appendix C, as well as the input message to be signed.  The
+      randomly generated coefficients produced by the trusted dealer to
+      share the group signing secret are also listed.  Each coefficient
+      is identified by its index, e.g., share_polynomial_coefficients[1]
+      is the coefficient of the first term in the polynomial.  Note that
+      the 0-th coefficient is omitted, as this is equal to the group
+      secret key.  All values are encoded as hexadecimal strings.
+
+   *  Signer input parameters.  This lists the signing key share for
+      each of the NUM_PARTICIPANTS participants.
+
+   *  Round one parameters and outputs.  This lists the NUM_PARTICIPANTS
+      participants engaged in the protocol, identified by their
+      NonZeroScalar identifier, and the following for each participant:
+      the hiding and binding commitment values produced in Section 5.1;
+      the randomness values used to derive the commitment nonces in
+      nonce_generate; the resulting group binding factor input computed
+      in part from the group commitment list encoded as described in
+      Section 4.3; and the group binding factor as computed in
+      Section 5.2.
+
+   *  Round two parameters and outputs.  This lists the NUM_PARTICIPANTS
+      participants engaged in the protocol, identified by their
+      NonZeroScalar identifier, along with their corresponding output
+      signature share as produced in Section 5.2.
+
+   *  Final output.  This lists the aggregate signature as produced in
+      Section 5.3.
+
+E.1.  FROST(Ed25519, SHA-512)
+
+   // Configuration information
+   MAX_PARTICIPANTS: 3
+   MIN_PARTICIPANTS: 2
+   NUM_PARTICIPANTS: 2
+
+   // Group input parameters
+   participant_list: 1,3
+   group_secret_key: 7b1c33d3f5291d85de664833beb1ad469f7fb6025a0ec78b3a7
+   90c6e13a98304
+   group_public_key: 15d21ccd7ee42959562fc8aa63224c8851fb3ec85a3faf66040
+   d380fb9738673
+   message: 74657374
+   share_polynomial_coefficients[1]: 178199860edd8c62f5212ee91eff1295d0d
+   670ab4ed4506866bae57e7030b204
+
+   // Signer input parameters
+   P1 participant_share: 929dcc590407aae7d388761cddb0c0db6f5627aea8e217f
+   4a033f2ec83d93509
+   P2 participant_share: a91e66e012e4364ac9aaa405fcafd370402d9859f7b6685
+   c07eed76bf409e80d
+   P3 participant_share: d3cb090a075eb154e82fdb4b3cb507f110040905468bb9c
+   46da8bdea643a9a02
+
+   // Signer round one outputs
+   P1 hiding_nonce_randomness: 0fd2e39e111cdc266f6c0f4d0fd45c947761f1f5d
+   3cb583dfcb9bbaf8d4c9fec
+   P1 binding_nonce_randomness: 69cd85f631d5f7f2721ed5e40519b1366f340a87
+   c2f6856363dbdcda348a7501
+   P1 hiding_nonce: 812d6104142944d5a55924de6d49940956206909f2acaeedecda
+   2b726e630407
+   P1 binding_nonce: b1110165fc2334149750b28dd813a39244f315cff14d4e89e61
+   42f262ed83301
+   P1 hiding_nonce_commitment: b5aa8ab305882a6fc69cbee9327e5a45e54c08af6
+   1ae77cb8207be3d2ce13de3
+   P1 binding_nonce_commitment: 67e98ab55aa310c3120418e5050c9cf76cf387cb
+   20ac9e4b6fdb6f82a469f932
+   P1 binding_factor_input: 15d21ccd7ee42959562fc8aa63224c8851fb3ec85a3f
+   af66040d380fb9738673504df914fa965023fb75c25ded4bb260f417de6d32e5c442c
+   6ba313791cc9a4948d6273e8d3511f93348ea7a708a9b862bc73ba2a79cfdfe07729a
+   193751cbc973af46d8ac3440e518d4ce440a0e7d4ad5f62ca8940f32de6d8dc00fc12
+   c660b817d587d82f856d277ce6473cae6d2f5763f7da2e8b4d799a3f3e725d4522ec7
+   0100000000000000000000000000000000000000000000000000000000000000
+   P1 binding_factor: f2cb9d7dd9beff688da6fcc83fa89046b3479417f47f55600b
+   106760eb3b5603
+   P3 hiding_nonce_randomness: 86d64a260059e495d0fb4fcc17ea3da7452391baa
+   494d4b00321098ed2a0062f
+   P3 binding_nonce_randomness: 13e6b25afb2eba51716a9a7d44130c0dbae0004a
+   9ef8d7b5550c8a0e07c61775
+   P3 hiding_nonce: c256de65476204095ebdc01bd11dc10e57b36bc96284595b8215
+   222374f99c0e
+   P3 binding_nonce: 243d71944d929063bc51205714ae3c2218bd3451d0214dfb5ae
+   ec2a90c35180d
+   P3 hiding_nonce_commitment: cfbdb165bd8aad6eb79deb8d287bcc0ab6658ae57
+   fdcc98ed12c0669e90aec91
+   P3 binding_nonce_commitment: 7487bc41a6e712eea2f2af24681b58b1cf1da278
+   ea11fe4e8b78398965f13552
+   P3 binding_factor_input: 15d21ccd7ee42959562fc8aa63224c8851fb3ec85a3f
+   af66040d380fb9738673504df914fa965023fb75c25ded4bb260f417de6d32e5c442c
+   6ba313791cc9a4948d6273e8d3511f93348ea7a708a9b862bc73ba2a79cfdfe07729a
+   193751cbc973af46d8ac3440e518d4ce440a0e7d4ad5f62ca8940f32de6d8dc00fc12
+   c660b817d587d82f856d277ce6473cae6d2f5763f7da2e8b4d799a3f3e725d4522ec7
+   0300000000000000000000000000000000000000000000000000000000000000
+   P3 binding_factor: b087686bf35a13f3dc78e780a34b0fe8a77fef1b9938c563f5
+   573d71d8d7890f
+
+   // Signer round two outputs
+   P1 sig_share: 001719ab5a53ee1a12095cd088fd149702c0720ce5fd2f29dbecf24
+   b7281b603
+   P3 sig_share: bd86125de990acc5e1f13781d8e32c03a9bbd4c53539bbc106058bf
+   d14326007
+
+   sig: 36282629c383bb820a88b71cae937d41f2f2adfcc3d02e55507e2fb9e2dd3cbe
+   bd9d2b0844e49ae0f3fa935161e1419aab7b47d21a37ebeae1f17d4987b3160b
+
+E.2.  FROST(Ed448, SHAKE256)
+
+   // Configuration information
+   MAX_PARTICIPANTS: 3
+   MIN_PARTICIPANTS: 2
+   NUM_PARTICIPANTS: 2
+
+   // Group input parameters
+   participant_list: 1,3
+   group_secret_key: 6298e1eef3c379392caaed061ed8a31033c9e9e3420726f23b4
+   04158a401cd9df24632adfe6b418dc942d8a091817dd8bd70e1c72ba52f3c00
+   group_public_key: 3832f82fda00ff5365b0376df705675b63d2a93c24c6e81d408
+   01ba265632be10f443f95968fadb70d10786827f30dc001c8d0f9b7c1d1b000
+   message: 74657374
+   share_polynomial_coefficients[1]: dbd7a514f7a731976620f0436bd135fe8dd
+   dc3fadd6e0d13dbd58a1981e587d377d48e0b7ce4e0092967c5e85884d0275a7a740b
+   6abdcd0500
+
+   // Signer input parameters
+   P1 participant_share: 4a2b2f5858a932ad3d3b18bd16e76ced3070d72fd79ae44
+   02df201f525e754716a1bc1b87a502297f2a99d89ea054e0018eb55d39562fd0100
+   P2 participant_share: 2503d56c4f516444a45b080182b8a2ebbe4d9b2ab509f25
+   308c88c0ea7ccdc44e2ef4fc4f63403a11b116372438a1e287265cadeff1fcb0700
+   P3 participant_share: 00db7a8146f995db0a7cf844ed89d8e94c2b5f259378ff6
+   6e39d172828b264185ac4decf7219e4aa4478285b9c0eef4fccdf3eea69dd980d00
+
+   // Signer round one outputs
+   P1 hiding_nonce_randomness: 9cda90c98863ef3141b75f09375757286b4bc323d
+   d61aeb45c07de45e4937bbd
+   P1 binding_nonce_randomness: 781bf4881ffe1aa06f9341a747179f07a49745f8
+   cd37d4696f226aa065683c0a
+   P1 hiding_nonce: f922beb51a5ac88d1e862278d89e12c05263b945147db04b9566
+   acb2b5b0f7422ccea4f9286f4f80e6b646e72143eeaecc0e5988f8b2b93100
+   P1 binding_nonce: 1890f16a120cdeac092df29955a29c7cf29c13f6f7be60e63d6
+   3f3824f2d37e9c3a002dfefc232972dc08658a8c37c3ec06a0c5dc146150500
+   P1 hiding_nonce_commitment: 3518c2246c874569e54ab254cb1da666ca30f7879
+   605cc43b4d2c47a521f8b5716080ab723d3a0cd04b7e41f3cc1d3031c94ccf3829b23
+   fe80
+   P1 binding_nonce_commitment: 11b3d5220c57d02057497de3c4eebab384900206
+   592d877059b0a5f1d5250d002682f0e22dff096c46bb81b46d60fcfe7752ed47cea76
+   c3900
+   P1 binding_factor_input: 3832f82fda00ff5365b0376df705675b63d2a93c24c6
+   e81d40801ba265632be10f443f95968fadb70d10786827f30dc001c8d0f9b7c1d1b00
+   0e9a0f30b97fe77ef751b08d4e252a3719ae9135e7f7926f7e3b7dd6656b27089ca35
+   4997fe5a633aa0946c89f022462e7e9d50fd6ef313f72d956ea4571089427daa1862f
+   623a41625177d91e4a8f350ce9c8bd3bc7c766515dc1dd3a0eab93777526b616cccb1
+   48fe1e5992dc1ae705c8ba2f97ca8983328d41d375ed1e5fde5c9d672121c9e8f177f
+   4a1a9b2575961531b33f054451363c8f27618382cd66ce14ad93b68dac6a09f5edcbc
+   cc813906b3fc50b8fef1cc09757b06646f38ceed1674cd6ced28a59c93851b325c6a9
+   ef6a4b3b88860b7138ee246034561c7460db0b3fae501000000000000000000000000
+   000000000000000000000000000000000000000000000000000000000000000000000
+   0000000000000000000
+   P1 binding_factor: 71966390dfdbed73cf9b79486f3b70e23b243e6c40638fb559
+   98642a60109daecbfcb879eed9fe7dbbed8d9e47317715a5740f772173342e00
+   P3 hiding_nonce_randomness: b3adf97ceea770e703ab295babf311d77e956a20d
+   3452b4b3344aa89a828e6df
+   P3 binding_nonce_randomness: 81dbe7742b0920930299197322b255734e52bbb9
+   1f50cfe8ce689f56fadbce31
+   P3 hiding_nonce: ccb5c1e82f23e0a4b966b824dbc7b0ef1cc5f56eeac2a4126e2b
+   2143c5f3a4d890c52d27803abcf94927faf3fc405c0b2123a57a93cefa3b00
+   P3 binding_nonce: e089df9bf311cf711e2a24ea27af53e07b846d09692fe11035a
+   1112f04d8b7462a62f34d8c01493a22b57a1cbf1f0a46c77d64d46449a90100
+   P3 hiding_nonce_commitment: 1254546d7d104c04e4fbcf29e05747e2edd392f67
+   87d05a6216f3713ef859efe573d180d291e48411e5e3006e9f90ee986ccc26b7a4249
+   0b80
+   P3 binding_nonce_commitment: 3ef0cec20be15e56b3ddcb6f7b956fca0c8f7199
+   0f45316b537b4f64c5e8763e6629d7262ff7cd0235d0781f23be97bf8fa8817643ea1
+   9cd00
+   P3 binding_factor_input: 3832f82fda00ff5365b0376df705675b63d2a93c24c6
+   e81d40801ba265632be10f443f95968fadb70d10786827f30dc001c8d0f9b7c1d1b00
+   0e9a0f30b97fe77ef751b08d4e252a3719ae9135e7f7926f7e3b7dd6656b27089ca35
+   4997fe5a633aa0946c89f022462e7e9d50fd6ef313f72d956ea4571089427daa1862f
+   623a41625177d91e4a8f350ce9c8bd3bc7c766515dc1dd3a0eab93777526b616cccb1
+   48fe1e5992dc1ae705c8ba2f97ca8983328d41d375ed1e5fde5c9d672121c9e8f177f
+   4a1a9b2575961531b33f054451363c8f27618382cd66ce14ad93b68dac6a09f5edcbc
+   cc813906b3fc50b8fef1cc09757b06646f38ceed1674cd6ced28a59c93851b325c6a9
+   ef6a4b3b88860b7138ee246034561c7460db0b3fae503000000000000000000000000
+   000000000000000000000000000000000000000000000000000000000000000000000
+   0000000000000000000
+   P3 binding_factor: 236a6f7239ac2019334bad21323ec93bef2fead37bd5511435
+   6419f3fc1fb59f797f44079f28b1a64f51dd0a113f90f2c3a1c27d2faa4f1300
+
+   // Signer round two outputs
+   P1 sig_share: e1eb9bfbef792776b7103891032788406c070c5c315e3bf5d64acd4
+   6ea8855e85b53146150a09149665cbfec71626810b575e6f4dbe9ba3700
+   P3 sig_share: 815434eb0b9f9242d54b8baf2141fe28976cabe5f441ccfcd5ee7cd
+   b4b52185b02b99e6de28e2ab086c7764068c5a01b5300986b9f084f3e00
+
+   sig: cd642cba59c449dad8e896a78a60e8edfcbd9040df524370891ff8077d47ce72
+   1d683874483795f0d85efcbd642c4510614328605a19c6ed806ffb773b6956419537c
+   dfdb2b2a51948733de192dcc4b82dc31580a536db6d435e0cb3ce322fbcf9ec23362d
+   da27092c08767e607bf2093600
+
+E.3.  FROST(ristretto255, SHA-512)
+
+   // Configuration information
+   MAX_PARTICIPANTS: 3
+   MIN_PARTICIPANTS: 2
+   NUM_PARTICIPANTS: 2
+
+   // Group input parameters
+   participant_list: 1,3
+   group_secret_key: 1b25a55e463cfd15cf14a5d3acc3d15053f08da49c8afcf3ab2
+   65f2ebc4f970b
+   group_public_key: e2a62f39eede11269e3bd5a7d97554f5ca384f9f6d3dd9c3c0d
+   05083c7254f57
+   message: 74657374
+   share_polynomial_coefficients[1]: 410f8b744b19325891d73736923525a4f59
+   6c805d060dfb9c98009d34e3fec02
+
+   // Signer input parameters
+   P1 participant_share: 5c3430d391552f6e60ecdc093ff9f6f4488756aa6cebdba
+   d75a768010b8f830e
+   P2 participant_share: b06fc5eac20b4f6e1b271d9df2343d843e1e1fb03c4cbb6
+   73f2872d459ce6f01
+   P3 participant_share: f17e505f0e2581c6acfe54d3846a622834b5e7b50cad9a2
+   109a97ba7a80d5c04
+
+   // Signer round one outputs
+   P1 hiding_nonce_randomness: f595a133b4d95c6e1f79887220c8b275ce6277e7f
+   68a6640e1e7140f9be2fb5c
+   P1 binding_nonce_randomness: 34dd1001360e3513cb37bebfabe7be4a32c5bb91
+   ba19fbd4360d039111f0fbdc
+   P1 hiding_nonce: 214f2cabb86ed71427ea7ad4283b0fae26b6746c801ce824b83c
+   eb2b99278c03
+   P1 binding_nonce: c9b8f5e16770d15603f744f8694c44e335e8faef00dad182b8d
+   7a34a62552f0c
+   P1 hiding_nonce_commitment: 965def4d0958398391fc06d8c2d72932608b1e625
+   5226de4fb8d972dac15fd57
+   P1 binding_nonce_commitment: ec5170920660820007ae9e1d363936659ef622f9
+   9879898db86e5bf1d5bf2a14
+   P1 binding_factor_input: e2a62f39eede11269e3bd5a7d97554f5ca384f9f6d3d
+   d9c3c0d05083c7254f572889dde2854e26377a16caf77dfee5f6be8fe5b4c80318da8
+   4698a4161021b033911db5ef8205362701bc9ecd983027814abee94f46d094943a2f4
+   b79a6e4d4603e52c435d8344554942a0a472d8ad84320585b8da3ae5b9ce31cd1903f
+   795c1af66de22af1a45f652cd05ee446b1b4091aaccc91e2471cd18a85a659cecd11f
+   0100000000000000000000000000000000000000000000000000000000000000
+   P1 binding_factor: 8967fd70fa06a58e5912603317fa94c77626395a695a0e4e4e
+   fc4476662eba0c
+   P3 hiding_nonce_randomness: daa0cf42a32617786d390e0c7edfbf2efbd428037
+   069357b5173ae61d6dd5d5e
+   P3 binding_nonce_randomness: b4387e72b2e4108ce4168931cc2c7fcce5f345a5
+   297368952c18b5fc8473f050
+   P3 hiding_nonce: 3f7927872b0f9051dd98dd73eb2b91494173bbe0feb65a3e7e58
+   d3e2318fa40f
+   P3 binding_nonce: ffd79445fb8030f0a3ddd3861aa4b42b618759282bfe24f1f93
+   04c7009728305
+   P3 hiding_nonce_commitment: 480e06e3de182bf83489c45d7441879932fd7b434
+   a26af41455756264fbd5d6e
+   P3 binding_nonce_commitment: 3064746dfd3c1862ef58fc68c706da287dd92506
+   6865ceacc816b3a28c7b363b
+   P3 binding_factor_input: e2a62f39eede11269e3bd5a7d97554f5ca384f9f6d3d
+   d9c3c0d05083c7254f572889dde2854e26377a16caf77dfee5f6be8fe5b4c80318da8
+   4698a4161021b033911db5ef8205362701bc9ecd983027814abee94f46d094943a2f4
+   b79a6e4d4603e52c435d8344554942a0a472d8ad84320585b8da3ae5b9ce31cd1903f
+   795c1af66de22af1a45f652cd05ee446b1b4091aaccc91e2471cd18a85a659cecd11f
+   0300000000000000000000000000000000000000000000000000000000000000
+   P3 binding_factor: f2c1bb7c33a10511158c2f1766a4a5fadf9f86f2a92692ed33
+   3128277cc31006
+
+   // Signer round two outputs
+   P1 sig_share: 9285f875923ce7e0c491a592e9ea1865ec1b823ead4854b48c8a462
+   87749ee09
+   P3 sig_share: 7cb211fe0e3d59d25db6e36b3fb32344794139602a7b24f1ae0dc4e
+   26ad7b908
+
+   sig: fc45655fbc66bbffad654ea4ce5fdae253a49a64ace25d9adb62010dd9fb2555
+   2164141787162e5b4cab915b4aa45d94655dbb9ed7c378a53b980a0be220a802
+
+E.4.  FROST(P-256, SHA-256)
+
+   // Configuration information
+   MAX_PARTICIPANTS: 3
+   MIN_PARTICIPANTS: 2
+   NUM_PARTICIPANTS: 2
+
+   // Group input parameters
+   participant_list: 1,3
+   group_secret_key: 8ba9bba2e0fd8c4767154d35a0b7562244a4aaf6f36c8fb8735
+   fa48b301bd8de
+   group_public_key: 023a309ad94e9fe8a7ba45dfc58f38bf091959d3c99cfbd02b4
+   dc00585ec45ab70
+   message: 74657374
+   share_polynomial_coefficients[1]: 80f25e6c0709353e46bfbe882a11bdbb1f8
+   097e46340eb8673b7e14556e6c3a4
+
+   // Signer input parameters
+   P1 participant_share: 0c9c1a0fe806c184add50bbdcac913dda73e482daf95dcb
+   9f35dbb0d8a9f7731
+   P2 participant_share: 8d8e787bef0ff6c2f494ca45f4dad198c6bee01212d6c84
+   067159c52e1863ad5
+   P3 participant_share: 0e80d6e8f6192c003b5488ce1eec8f5429587d48cf00154
+   1e713b2d53c09d928
+
+   // Signer round one outputs
+   P1 hiding_nonce_randomness: ec4c891c85fee802a9d757a67d1252e7f4e5efb8a
+   538991ac18fbd0e06fb6fd3
+   P1 binding_nonce_randomness: 9334e29d09061223f69a09421715a347e4e6deba
+   77444c8f42b0c833f80f4ef9
+   P1 hiding_nonce: 9f0542a5ba879a58f255c09f06da7102ef6a2dec6279700c656d
+   58394d8facd4
+   P1 binding_nonce: 6513dfe7429aa2fc972c69bb495b27118c45bbc6e654bb9dc9b
+   e55385b55c0d7
+   P1 hiding_nonce_commitment: 0213b3e6298bf8ad46fd5e9389519a8665d63d98f
+   4ec6a1fcca434e809d2d8070e
+   P1 binding_nonce_commitment: 02188ff1390bf69374d7b272e454b1878ef10a6b
+   6ea3ff36f114b300b4dbd5233b
+   P1 binding_factor_input: 023a309ad94e9fe8a7ba45dfc58f38bf091959d3c99c
+   fbd02b4dc00585ec45ab70825371853e974bc30ac5b947b216d70461919666584c70c
+   51f9f56f117736c5d178dd0b521ad9c1abe98048419cbdec81504c85e12eb40e3bcb6
+   ec73d3fc4afd000000000000000000000000000000000000000000000000000000000
+   0000001
+   P1 binding_factor: 7925f0d4693f204e6e59233e92227c7124664a99739d2c06b8
+   1cf64ddf90559e
+   P3 hiding_nonce_randomness: c0451c5a0a5480d6c1f860e5db7d655233dca2669
+   fd90ff048454b8ce983367b
+   P3 binding_nonce_randomness: 2ba5f7793ae700e40e78937a82f407dd35e847e3
+   3d1e607b5c7eb6ed2a8ed799
+   P3 hiding_nonce: f73444a8972bcda9e506bbca3d2b1c083c10facdf4bb5d47fef7
+   c2dc1d9f2a0d
+   P3 binding_nonce: 44c6a29075d6e7e4f8b97796205f9e22062e7835141470afe94
+   17fd317c1c303
+   P3 hiding_nonce_commitment: 033ac9a5fe4a8b57316ba1c34e8a6de453033b750
+   e8984924a984eb67a11e73a3f
+   P3 binding_nonce_commitment: 03a7a2480ee16199262e648aea3acab628a53e9b
+   8c1945078f2ddfbdc98b7df369
+   P3 binding_factor_input: 023a309ad94e9fe8a7ba45dfc58f38bf091959d3c99c
+   fbd02b4dc00585ec45ab70825371853e974bc30ac5b947b216d70461919666584c70c
+   51f9f56f117736c5d178dd0b521ad9c1abe98048419cbdec81504c85e12eb40e3bcb6
+   ec73d3fc4afd000000000000000000000000000000000000000000000000000000000
+   0000003
+   P3 binding_factor: e10d24a8a403723bcb6f9bb4c537f316593683b472f7a89f16
+   6630dde11822c4
+
+   // Signer round two outputs
+   P1 sig_share: 400308eaed7a2ddee02a265abe6a1cfe04d946ee8720768899619cf
+   abe7a3aeb
+   P3 sig_share: 561da3c179edbb0502d941bb3e3ace3c37d122aaa46fb54499f15f3
+   a3331de44
+
+   sig: 026d8d434874f87bdb7bc0dfd239b2c00639044f9dcb195e9a04426f70bfa4b7
+   0d9620acac6767e8e3e3036815fca4eb3a3caa69992b902bcd3352fc34f1ac192f
+
+E.5.  FROST(secp256k1, SHA-256)
+
+   // Configuration information
+   MAX_PARTICIPANTS: 3
+   MIN_PARTICIPANTS: 2
+   NUM_PARTICIPANTS: 2
+
+   // Group input parameters
+   participant_list: 1,3
+   group_secret_key: 0d004150d27c3bf2a42f312683d35fac7394b1e9e318249c1bf
+   e7f0795a83114
+   group_public_key: 02f37c34b66ced1fb51c34a90bdae006901f10625cc06c4f646
+   63b0eae87d87b4f
+   message: 74657374
+   share_polynomial_coefficients[1]: fbf85eadae3058ea14f19148bb72b45e439
+   9c0b16028acaf0395c9b03c823579
+
+   // Signer input parameters
+   P1 participant_share: 08f89ffe80ac94dcb920c26f3f46140bfc7f95b493f8310
+   f5fc1ea2b01f4254c
+   P2 participant_share: 04f0feac2edcedc6ce1253b7fab8c86b856a797f44d83d8
+   2a385554e6e401984
+   P3 participant_share: 00e95d59dd0d46b0e303e500b62b7ccb0e555d49f5b849f
+   5e748c071da8c0dbc
+
+   // Signer round one outputs
+   P1 hiding_nonce_randomness: 7ea5ed09af19f6ff21040c07ec2d2adbd35b759da
+   5a401d4c99dd26b82391cb2
+   P1 binding_nonce_randomness: 47acab018f116020c10cb9b9abdc7ac10aae1b48
+   ca6e36dc15acb6ec9be5cdc5
+   P1 hiding_nonce: 841d3a6450d7580b4da83c8e618414d0f024391f2aeb511d7579
+   224420aa81f0
+   P1 binding_nonce: 8d2624f532af631377f33cf44b5ac5f849067cae2eacb88680a
+   31e77c79b5a80
+   P1 hiding_nonce_commitment: 03c699af97d26bb4d3f05232ec5e1938c12f1e6ae
+   97643c8f8f11c9820303f1904
+   P1 binding_nonce_commitment: 02fa2aaccd51b948c9dc1a325d77226e98a5a3fe
+   65fe9ba213761a60123040a45e
+   P1 binding_factor_input: 02f37c34b66ced1fb51c34a90bdae006901f10625cc0
+   6c4f64663b0eae87d87b4fff9b5210ffbb3c07a73a7c8935be4a8c62cf015f6cf7ade
+   6efac09a6513540fc3f5a816aaebc2114a811a415d7a55db7c5cbc1cf27183e79dd9d
+   ef941b5d4801000000000000000000000000000000000000000000000000000000000
+   0000001
+   P1 binding_factor: 3e08fe561e075c653cbfd46908a10e7637c70c74f0a77d5fd4
+   5d1a750c739ec6
+   P3 hiding_nonce_randomness: e6cc56ccbd0502b3f6f831d91e2ebd01c4de0479e
+   0191b66895a4ffd9b68d544
+   P3 binding_nonce_randomness: 7203d55eb82a5ca0d7d83674541ab55f6e76f1b8
+   5391d2c13706a89a064fd5b9
+   P3 hiding_nonce: 2b19b13f193f4ce83a399362a90cdc1e0ddcd83e57089a7af0bd
+   ca71d47869b2
+   P3 binding_nonce: 7a443bde83dc63ef52dda354005225ba0e553243402a4705ce2
+   8ffaafe0f5b98
+   P3 hiding_nonce_commitment: 03077507ba327fc074d2793955ef3410ee3f03b82
+   b4cdc2370f71d865beb926ef6
+   P3 binding_nonce_commitment: 02ad53031ddfbbacfc5fbda3d3b0c2445c8e3e99
+   cbc4ca2db2aa283fa68525b135
+   P3 binding_factor_input: 02f37c34b66ced1fb51c34a90bdae006901f10625cc0
+   6c4f64663b0eae87d87b4fff9b5210ffbb3c07a73a7c8935be4a8c62cf015f6cf7ade
+   6efac09a6513540fc3f5a816aaebc2114a811a415d7a55db7c5cbc1cf27183e79dd9d
+   ef941b5d4801000000000000000000000000000000000000000000000000000000000
+   0000003
+   P3 binding_factor: 93f79041bb3fd266105be251adaeb5fd7f8b104fb554a4ba9a
+   0becea48ddbfd7
+
+   // Signer round two outputs
+   P1 sig_share: c4fce1775a1e141fb579944166eab0d65eefe7b98d480a569bbbfcb
+   14f91c197
+   P3 sig_share: 0160fd0d388932f4826d2ebcd6b9eaba734f7c71cf25b4279a4ca25
+   81e47b18d
+
+   sig: 0205b6d04d3774c8929413e3c76024d54149c372d57aae62574ed74319b5ea14
+   d0c65dde8492a7471437e6c2fe3da49b90d23f642b5c6dbe7e36089f096dd97324
+
+Acknowledgments
+
+   This document was improved based on input and contributions by the
+   Zcash Foundation engineering team.  In addition, the authors of this
+   document would like to thank Isis Lovecruft, Alden Torres, T. Wilson-
+   Brown, and Conrado Gouvea for their input and contributions.
+
+Authors' Addresses
+
+   Deirdre Connolly
+   Zcash Foundation
+   Email: durumcrustulum@gmail.com
+
+
+   Chelsea Komlo
+   University of Waterloo, Zcash Foundation
+   Email: ckomlo@uwaterloo.ca
+
+
+   Ian Goldberg
+   University of Waterloo
+   Email: iang@uwaterloo.ca
+
+
+   Christopher A. Wood
+   Cloudflare
+   Email: caw@heapingbits.net