Skip to main content

FROST: Flexible Round-Optimized Schnorr Threshold Signatures

Part of the Lecture Notes in Computer Science book series (LNSC,volume 12804)

Abstract

Unlike signatures in a single-party setting, threshold signatures require cooperation among a threshold number of signers each holding a share of a common private key. Consequently, generating signatures in a threshold setting imposes overhead due to network rounds among signers, proving costly when secret shares are stored on network-limited devices or when coordination occurs over unreliable networks. In this work, we present FROST, a Flexible Round-Optimized Schnorr Threshold signature scheme that reduces network overhead during signing operations while employing a novel technique to protect against forgery attacks applicable to similar schemes in the literature. FROST improves upon the state of the art in Schnorr threshold signature protocols, as it can safely perform signing operations in a single round without limiting concurrency of signing operations, yet allows for true threshold signing, as only a threshold t out of n possible participants are required for signing operations, such that \(t\le n\). FROST can be used as either a two-round protocol, or optimized to a single-round signing protocol with a pre-processing stage. FROST achieves its efficiency improvements in part by allowing the protocol to abort in the presence of a misbehaving participant (who is then identified and excluded from future operations)—a reasonable model for practical deployment scenarios. We present proofs of security demonstrating that FROST is secure against chosen-message attacks assuming the discrete logarithm problem is hard and the adversary controls fewer participants than the threshold.

Keywords

  • Secret sharing
  • Threshold signatures
  • Schnorr signatures

This is a preview of subscription content, access via your institution.

Buying options

Chapter
USD   29.95
Price excludes VAT (USA)
  • DOI: 10.1007/978-3-030-81652-0_2
  • Chapter length: 32 pages
  • Instant PDF download
  • Readable on all devices
  • Own it forever
  • Exclusive offer for individuals only
  • Tax calculation will be finalised during checkout
eBook
USD   84.99
Price excludes VAT (USA)
  • ISBN: 978-3-030-81652-0
  • Instant PDF download
  • Readable on all devices
  • Own it forever
  • Exclusive offer for individuals only
  • Tax calculation will be finalised during checkout
Softcover Book
USD   109.99
Price excludes VAT (USA)
Fig. 1.
Fig. 2.
Fig. 3.

Notes

  1. 1.

    Signatures generated using the FROST protocol can also be referred to as “FROSTy signatures”.

  2. 2.

    Note that we slightly modify this attack to include the public key Y as an input into H to match the notation used in this paper.

  3. 3.

    Note that if n is small, the \(\lambda _i\) for every possible S can be precomputed as a performance optimization.

  4. 4.

    For example, authentication tokens or TLS certificates could serve to authenticate participants to one another.

  5. 5.

    Each participant contributes to the group commitment R, which corresponds to the commitment \(g^k\) to the nonce k in step 1 of the single-party Schnorr signature scheme in Sect. 2.3.

  6. 6.

    A one-time VRF \(F_k\) for key k relaxes the standard properties of a VRF by requiring that \(F_k(x)\) be unpredictable to someone who does not know k only when at most one value of \(F_k(y)\) has been published by the keyholder (and \(y \not = x\)). We use the construction \(k=(a,b) \in \mathbb {Z}_q^2\) and \(F_k(x) = a + b\cdot x\). The public key is \((A=g^a,B=g^b)\).

  7. 7.

    This is the main heuristic step; sufficiency (“if”) is immediate, but we do not prove necessity (“only if”). That said, the only information the forger has about honest participant \(P_t\)’s private key \(s_t\) is \(Y_t = g^{s_t}\) and \(\pi \) pairs \((g^{k_j}, z_j = k_j + s_t \cdot \lambda _t \cdot H_2(R_j, Y, m_j))_{j=1}^\pi \). If the forger can produce a forgery, they must necessarily be able to compute a pair \((g^{k^*}, z^* = k^* + s_t \cdot \lambda _t \cdot H_2(R^*, Y, m^*))\). Assuming taking discrete logs is infeasible, writing \(z^*\) as a linear combination of the \(z_j\) (as polynomials in the unknown \(s_t\)) appears to be the forger’s only reasonable strategy.

References

  1. Abidin, A., Aly, A., Mustafa, M.A.: Collaborative authentication using threshold cryptography. In: Emerging Technologies for Authorization and Authentication, pp. 122–137 (2020)

    Google Scholar 

  2. Bellare, M., Boldyreva, A., Staddon, J.: Randomness re-use in multi-recipient encryption schemeas. In: Desmedt, Y.G. (ed.) PKC 2003. LNCS, vol. 2567, pp. 85–99. Springer, Heidelberg (2003). https://doi.org/10.1007/3-540-36288-6_7

    CrossRef  Google Scholar 

  3. Bellare, M., Neven, G.: Multi-signatures in the plain public-key model and a general forking lemma. In: Proceedings of the 13th ACM Conference on Computer and Communications Security, CCS 2006, pp. 390–399 (2006). https://doi.org/10.1145/1180405.1180453

  4. Benaloh, J., Leichter, J.: Generalized secret sharing and monotone functions. In: Goldwasser, S. (ed.) Generalized Secret Sharing and Monotone Functions. LNCS, vol. 403, pp. 27–35. Springer, New York (1990). https://doi.org/10.1007/0-387-34799-2_3

    CrossRef  Google Scholar 

  5. Benhamouda, F., Lepoint, T., Orrù, M., Raykova, M.: On the (in)security of ROS. Technical report 2020/945, IACR ePrint (2020). https://eprint.iacr.org/2020/945

  6. Boneh, D., Drijvers, M., Neven, G.: Compact multi-signatures for smaller blockchains. In: Peyrin, T., Galbraith, S. (eds.) ASIACRYPT 2018. LNCS, vol. 11273, pp. 435–464. Springer, Cham (2018). https://doi.org/10.1007/978-3-030-03329-3_15

    CrossRef  Google Scholar 

  7. Boneh, D., Lynn, B., Shacham, H.: Short signatures from the Weil pairing. J. Cryptol. 17(4), 297–319 (2004). https://doi.org/10.1007/s00145-004-0314-9

    MathSciNet  CrossRef  MATH  Google Scholar 

  8. Cramer, R., Damgård, I., Ishai, Y.: Share conversion, pseudorandom secret-sharing and applications to secure computation. In: Kilian, J. (ed.) TCC 2005. LNCS, vol. 3378, pp. 342–362. Springer, Heidelberg (2005). https://doi.org/10.1007/978-3-540-30576-7_19

    CrossRef  Google Scholar 

  9. Damgård, I., Jakobsen, T.P., Nielsen, J.B., Pagter, J.I., Østergård, M.B.: Fast threshold ECDSA with honest majority. Technical report 2020/501, IACR ePrint (2020). https://eprint.iacr.org/2020/501

  10. Drijvers, M., et al.: On the security of two-round multi-signatures. In: 2019 IEEE Symposium on Security and Privacy (SP), pp. 1084–1101 (2019)

    Google Scholar 

  11. Feldman, P.: A practical scheme for non-interactive verifiable secret sharing. In: Proceedings of the 28th Annual Symposium on Foundations of Computer Science, SFCS 1987, pp. 427–438 (1987). https://doi.org/10.1109/SFCS.1987.4

  12. Gennaro, R., Goldfeder, S.: Fast multiparty threshold ECDSA with fast trustless setup. In: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, pp. 1179–1194 (2018). https://doi.org/10.1145/3243734.3243859

  13. Gennaro, R., Goldfeder, S.: One round threshold ECDSA with identifiable abort. Technical report 2020/540, IACR ePrint (2020). https://eprint.iacr.org/2020/540

  14. Gennaro, R., Jarecki, S., Krawczyk, H., Rabin, T.: Secure applications of Pedersen’s distributed key generation protocol. In: Topics in Cryptology – CT-RSA 2003, pp. 373–390 (2003)

    Google Scholar 

  15. Gennaro, R., Jarecki, S., Krawczyk, H., Rabin, T.: Secure distributed key generation for discrete-log based cryptosystems. J. Cryptol. 20(1), 51–83 (2006). https://doi.org/10.1007/s00145-006-0347-3

  16. Goldfeder, S., et al.: Securing Bitcoin wallets via a new DSA/ECDSA threshold signature scheme (2015). http://stevengoldfeder.com/papers/threshold_sigs.pdf. Accessed Dec 2019

  17. Josefsson, S., Liusvaara, I.: Edwards-Curve Digital Signature Algorithm (EdDSA), January 2017. https://tools.ietf.org/html/rfc8032

  18. KZen Networks: Multi Party Schnorr Signatures (2019). https://github.com/KZen-networks/multi-party-schnorr. Accessed Jan 2020

  19. Lovecruft, I., de Valence, H.: The Ristretto Group (2020). https://doc.dalek.rs/curve25519_dalek/

  20. Lueks, W.: Security and Privacy via Cryptography – Having your cake and eating it too (2017). https://wouterlueks.nl/assets/docs/thesis_lueks_def.pdf

  21. Maxwell, G., Poelstra, A., Seurin, Y., Wuille, P.: Simple Schnorr multi-signatures with applications to Bitcoin. Des. Codes Cryptogr. 87(9), 2139–2164 (2019). https://doi.org/10.1007/s10623-019-00608-x

  22. Mittal, P., Olumofin, F., Troncoso, C., Borisov, N., Goldberg, I.: PIR-Tor: scalable anonymous communication using private information retrieval. In: 20th USENIX Security Symposium, SEC 2011 (2011). http://dl.acm.org/citation.cfm?id=2028067.2028098

  23. Pedersen, T.P.: A threshold cryptosystem without a trusted party. In: Davies, D.W. (ed.) EUROCRYPT 1991. LNCS, vol. 547, pp. 522–526. Springer, Heidelberg (1991). https://doi.org/10.1007/3-540-46416-6_47

    CrossRef  Google Scholar 

  24. Pointcheval, D., Stern, J.: Security arguments for digital signatures and blind signatures. J. Cryptol. 13(3), 361–396 (2000). https://doi.org/10.1007/s001450010003

  25. Schnorr, C.: Security of blind discrete log signatures against interactive attacks. In: ICICS (2001)

    Google Scholar 

  26. Schnorr, C.P.: Efficient identification and signatures for smart cards. In: Brassard, G. (ed.) CRYPTO 1989. LNCS, vol. 435, pp. 239–252. Springer, New York (1990). https://doi.org/10.1007/0-387-34805-0_22

    CrossRef  Google Scholar 

  27. Shamir, A.: How to share a secret. Commun. ACM 22, 612–613 (1979)

    Google Scholar 

  28. Stinson, D.R., Strobl, R.: Provably secure distributed Schnorr signatures and a \((t, n)\) threshold scheme for implicit certificates. In: Proceedings of the 6th Australasian Conference on Information Security and Privacy, ACISP 2001, pp. 417–434 (2001). http://dl.acm.org/citation.cfm?id=646038.678297

  29. Wagner, D.: A generalized birthday problem. In: Yung, M. (ed.) CRYPTO 2002. LNCS, vol. 2442, pp. 288–304. Springer, Heidelberg (2002). https://doi.org/10.1007/3-540-45708-9_19

    CrossRef  Google Scholar 

Download references

Acknowledgments

We thank Douglas Stebila for his discussion on our proof of security and security bounds. We thank Richard Barnes for his discussion on practical constraints and identifying significant optimizations to a prior version of FROST, which our final version of FROST builds upon. We thank Isis Lovecruft for their discussion and parallel implementation of FROST.

We thank colleagues at the Zcash Foundation for discussions on applications of threshold signatures, and Omer Shlomovits and Elichai Turkel for pointing out the case of rogue-key attacks in plain Ped-DKG and the suggestion to use a proof of knowledge for \(a_{i0}\) as a prevention mechanism. We acknowledge the helpful description of additive secret sharing and share conversion as a technique to non-interactively generate secrets for Shamir secret-sharing schemes by Lueks [20, §2.5.2].

We thank the Royal Bank of Canada and NSERC grant CRDPJ-534381 for funding this work. This research was undertaken, in part, thanks to funding from the Canada Research Chairs program.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Ian Goldberg .

Editor information

Editors and Affiliations

A  Proof of Security

A  Proof of Security

In Sect. 6.2, we presented a high-level overview of the proof of security for FROST-Interactive. We now present the proof in detail.

1.1 A.1  Preliminaries

Our proof strategy is to demonstrate that the security of FROST-Interactive reduces to the difficulty of computing the discrete logarithm of an arbitrary challenge value \(\omega \). At a high level, \(\omega \) will be embedded into a public key Y representing a set of participants, such that Y is the output of these participants cooperating to perform the FROST KeyGen protocol. Then, to compute the discrete logarithm of \(\omega \), a forger \(\mathcal {F}\) will produce two forgeries \((\sigma , \sigma '), \sigma \ne \sigma '\) for the same commitment value R and message m. Using \((\sigma , \sigma ')\), the discrete logarithm of \(\omega \) can subsequently be extracted.

We now describe how we perform this proof strategy in detail, starting by introducing four different algorithms that we use in our proof, and expanding further below.

  • \(\mathcal {F}\) represents a forger that with probability \(\epsilon \) and in time t can compute a forgery \(\sigma \) for a public key Y, where Y was generated as part of the FROST KeyGen protocol.

  • \(\mathcal {A}\) represents a simulator that invokes \(\mathcal {F}\) and simulates the necessary inputs/outputs for \(\mathcal {F}\) to perform its forgery attack. Specifically, \(\mathcal {A}\) simulates honest participants in FROST KeyGen and signing operations, as well as random oracle queries.

  • \(GF_\mathcal {A}\) represents the Generalized Forking Algorithm that establishes a random tape and outputs to random oracle queries, and invokes \(\mathcal {A}\) with these values in order to produce two forgeries \((\sigma , \sigma ')\).

  • C represents the coordination algorithm that accepts a challenge value \(\omega \) and invokes the other algorithms in order to obtain \((\sigma , \sigma ')\), which it then uses to compute the discrete logarithm of \(\omega \).

Adversary Powers. When performing its forgery attack, we grant \(\mathcal {F}\) the role of the signature aggregator \(\mathcal {SA}\). Without loss of generality, we assume \(\mathcal {F}\) controls \(t-1\) participants, and has full power over how these participants behave, what secret and public values they generate, etc. We also assume the participant \(P_t\) is in the signing set S.

We now further describe \(GF_\mathcal {A}\) and C; note these algorithms remain largely unchanged from their use by Bellare and Neven [3]. We describe the implementation of \(\mathcal {A}\) in the proof directly.

Generalized Forking Algorithm and Lemma. We build upon the Generalized Forking Algorithm and Lemma by Bellare and Neven [3], which simulates the rewinding of the adversary \(\mathcal {A}\), and which we describe next.

Generalized Forking Algorithm. Let \(n_r\) be the maximum number of random oracle outputs that \(\mathcal {A}\) may need to generate, and let h be the number of possible outputs from the random oracle H.

The adversary \(\mathcal {A}\) is an algorithm that accepts as inputs a public key Y, the randomly selected set \(h_1, \dots , h_{n_r}\) of random oracle outputs, and a random tape \(\beta \). \(\mathcal {A}\) outputs an integer J which represents the index corresponding to the random oracle query that can be used to derive c for the forgery \(\sigma =(R, z)\), along with \(\sigma \) itself. \(GF_\mathcal {A}\) (Algorithm 1) plays the role of setting up these inputs and outputs, and executing \(\mathcal {A}\) accordingly.

figure a

The execution \(GF_\mathcal {A}\) is as follows: first \(GF_\mathcal {A}\) instantiates a random tape \(\beta \), and generates random outputs \(h_1, \dots , h_{n_r}\) which will then be used by \(\mathcal {A}\) to simulate the outputs for each random oracle query. \(GF_\mathcal {A}\) then executes \(\mathcal {A}\) with these inputs as well as a public key Y. \(\mathcal {A}\) uses the forger \(\mathcal {F}\) as a subroutine to perform its forgery attack, simulating all input and output whenever \(\mathcal {F}\) requests a signing operation or random oracle query. Eventually, \(\mathcal {F}\) outputs a forgery \(\sigma \) with probability \(\epsilon \), which \(\mathcal {A}\) returns along with its corresponding index for the random oracle query that can be used to derive c for \(\sigma \). After \(\mathcal {A}\) outputs \((J, \sigma )\), \(GF_\mathcal {A}\) first checks to see if the output is a successful forgery, as indicated by when \(J \ge 1\). If so, it continues to the second execution of \(\mathcal {A}\).

For the second execution of \(\mathcal {A}\), \(GF_\mathcal {A}\) will feed in the same random tape \(\beta \), but will supply a different set of simulated responses for the random oracle H. In order to “fork” \(\mathcal {A}\), \(GF_\mathcal {A}\) will supply the same responses \(h_1, \dots , h_{J-1}\), but will provide different responses for \(h_J, \dots , h_{n_r}\). In doing so, \(GF_\mathcal {A}\) simulates forking the adversary at a specific point when performing its attack similar to the proof model by Pointcheval and Stern [24], but without needing to rewind \(\mathcal {A}\) to a specific point.

After its second execution, \(\mathcal {A}\) will return \((J', \sigma ')\) or \(\bot \). If but the output from the random oracle queries is different such that \(h_J \ne h_J'\), then \(GF_\mathcal {A}\) will output 1 to indicate success along with the two forgeries \(\sigma , \sigma '\) and the two random oracle queries corresponding to these forgeries \((h_J, h_J')\). These values can then be used by the coordination algorithm C to determine the discrete logarithm of the challenge value \(\omega \) (we provide more details on how to perform this operation below).

Generalized Forking Lemma. We will now see how the generalized forking lemma presented by Bellare and Neven [3] determines the probability that \(GF_\mathcal {A}\) will return a successful output. Let acc be the accepting probability of \(\mathcal {A}\), or the probability that \(J \ge 1\), and let h be the total number of possible outputs of H. Let \(e'\) be the advantage of solving the discrete logarithm problem over some group \(\mathbb {G}\). Recall that \(n_r\) is the maximum number of random oracle outputs \(\mathcal {A}\) may need to generate.

Lemma 1

Generalized Forking Lemma [3] Let frk be defined by the following probability:

$$ \text {frk} = Pr [b=1 : x \overset{\$}{\leftarrow }IG : (b, \sigma , \sigma ') \overset{\$}{\leftarrow }GF_\mathcal {A}(x)] $$

where IG is an input generator for a challenge input x. Then

$$ e' \ge \text {frk} \ge \text {acc} \cdot (\frac{\text {acc}}{n_r} - \frac{1}{h}) $$

Lemma 1 demonstrates the probability \(e'\) that running the generalized forking algorithm \(GF_\mathcal {A}\) will produce two valid forgeries \(\sigma =(R, z)\) and \(\sigma '=(R', z')\) along with their respective challenge responses from the random oracle \((h_J, h_J')\) over the same message m and public commitment R, and so enable the extraction of the desired discrete logarithm.

Embedding the Challenge Value During KeyGen. We use a coordination algorithm C described in Algorithm 2 to perform setup for \(GF_\mathcal {A}\) and to derive the discrete logarithm of the challenge value \(\omega \) afterward.

figure b

Simulating KeyGen. We now describe how C embeds the challenge value \(\omega \) into the group public key Y during a simulation of the KeyGen phase; Y is in turn fed as input into \(GF_\mathcal {A}\). For simplicity of notation, we let \(n=t\) (where n is the total number of participants and t is the threshold), and \(\mathcal {F}\) controls \(t-1\) participants, and \(\mathcal {A}\) simulates the \(t^{\text {th}}\) (honest) participant to \(\mathcal {F}\). The case for general n is similar.

For the first round of the key generation protocol, \(\mathcal {A}\) simulates \(P_t\) as follows. Let be the set of public commitments \(\phi _{i1}, \dots , \phi _{i(t-1)}\) for participant \(P_i\). To calculate and to distribute shares \(f_t(1), \dots , f_t(t-1)\) to the \(t-1\) participants corrupted by \(\mathcal {F}\), \(\mathcal {A}\) does the following:

  1. 1.

    Randomly generate \(\bar{x}_{t1}, \dots , \bar{x}_{t(t-1)}\) to serve as the secret shares corresponding to \(f_t(1), \dots , f_t(t-1)\)

  2. 2.

    Set \(\phi _{t0}\) to be the challenge value \(\omega \)

  3. 3.

    Calculate \(\phi _{t1}, \dots , \phi _{t(t-1)}\) by performing Lagrange interpolation in the exponent, or \(\phi _{tk} = \omega ^{\lambda _{k0} } \cdot g^{ \sum _{i=1}^{t-1} \lambda _{ki} \cdot \bar{x}_{ti}}\)

\(\mathcal {A}\) then broadcasts for \(P_t\). For the second round, \(\mathcal {A}\) sends \((1, \bar{x}_{t1}), \dots , (t-1, \bar{x}_{t(t-1)})\) to the participants \(P_1, \dots , P_{t-1}\) corrupted by \(\mathcal {F}\). Further, \(\mathcal {A}\) simulates the proof of knowledge for \(a_{t0}\) by deriving \(\sigma \) as:

$$\begin{aligned} c_t, z \overset{\$}{\leftarrow }\mathbb {Z}_q\text {; }R = g^z \cdot \omega ^{-c_t}\text {; and } \sigma = (R, z) \end{aligned}$$

\(\mathcal {A}\) derives the public key for \(P_t\) by following the same steps they would use to calculate the public key for their peers (as the discrete log of the challenge value \(\omega \) is unknown), by deriving \(Y_t = \prod _{j=1}^n \prod _{k=0}^{t-1} \phi _{jk}^{t^k \bmod q}\).

The participants controlled by \(\mathcal {F}\) can derive their private key shares \(s_i\) by directly following the KeyGen protocol, then deriving \(Y_i = g^{s_i}\). We will see in the proof for FROST-Interactive how \(\mathcal {A}\) can still simulate signing for the honest party \(P_t\) to \(\mathcal {F}\) even without knowing its corresponding private key share. Each party (honest or corrupted by \(\mathcal {F}\)) can follow the KeyGen protocol to derive the group’s long-lived public key, by calculating \(Y = \prod _{j=1}^n \phi _{j0}\).

In addition, C must obtain \(\mathcal {F}\)’s secret values \((a_{10}, \dots , a_{(t-1)0})\) using the extractor for the zero-knowledge proofs that \(\mathcal {F}\) generates. C will use these values next in order to convert the discrete logarithm for the group public key Y into the discrete logarithm for the challenge value \(\omega \).

Solving Discrete Logarithm of the Challenge. We now describe how two forged signatures \((\sigma , \sigma ')\) along with the challenge values from the random oracle query \((h_J, h_J')\) produced as output from \(GF_\mathcal {A}\) can be used by C to extract the discrete logarithm of the challenge value \(\omega \). We give an overview of the algorithm ExtractDLog in Algorithm 3, which C uses as a subroutine. Note that the advantage \(e'\) used later in our proofs denotes the advantage of \(C(\omega )\) of solving the discrete logarithm for the challenge value \(\omega \).

figure c

We can compute dlog(Y), because

$$ R = g^z \cdot Y^{-h_J} = g^{z'} \cdot Y^{-h_{J}'} $$

and since \(h_J \ne h_J'\), then

$$ dlog(Y) = \frac{(z'-z)}{(h_J'-h_J)} $$

The discrete logarithm corresponding to \(\omega \) can then be extracted as follows:

$$\begin{aligned} a_{t0} = dlog(Y) - \sum _{i=1}^{t-1} a_{i0} = dlog(\omega ) \end{aligned}$$
(2)

As discussed in Sect. A.1, all of \(\mathcal {F}\)’s \(a_{i0}, i \ne t\) values are known as these were extracted by \(\mathcal {A}\) while performing the key generation protocol. Hence, C can extract \(a_{t0}\) using Eq. 2, resulting in learning the discrete log of the challenge value \(\omega \).

1.2 A.2  Proof of Security for FROST-Interactive

Due to the difficulty of simulating zero-knowledge proofs in parallel, for the purposes of proving the security of FROST, we will first prove security against an interactive two-round variant of the FROST signing operation, which we call FROST-Interactive. In Sect. 6.2, we discuss how the security for FROST-Interactive extends to plain FROST.

FROST-Interactive. FROST-Interactive uses the same KeyGen protocol to generate long-lived keys as regular FROST, as further described in Sect. 5.1. We present an overview of the Preprocess step for FROST-Interactive in Fig. 4, and the signing step in Fig. 5.

The distinction between the signing operations for plain FROST and FROST-Interactive is how the binding value \(\rho _i\) is generated. Because of the difficulty of simulating non-interactive zero-knowledge proofs of knowledge (NIZKPKs) in a concurrent setting, we instantiate FROST-Interactive using a one-time VRF, from which each participant generates their value \(\rho _i\) given the inputs (mB). We prove this variant to be secure against the standard notion of EUF-CMA security.

Preprocess. The Preprocess phase for FROST-Interactive differs from FROST in two ways. First, participants additionally generate one-time VRF keys \((a_{ij}, b_{ij})\) and their commitments \((A_{ij} = g^{a_{ij}}, B_{ij} = g^{b_{ij}})\) along with the usual FROST nonce values \((d_{ij}, e_{ij})\) and their commitments \((D_{ij} = g^{d_{ij}}, E_{ij} = g^{e_{ij}})\) along with a zero-knowledge proof of knowledge for the \((a_{ij}, b_{ij})\) one-time VRF keys. These keys are later used to generate \(\rho _i\) during the signing phase.

We require Preprocess for FROST-Interactive to be performed serially so that the simulator can efficiently extract the discrete logarithm of the adversary’s non-interactive zero knowledge proof of knowledge of its VRF keys via rewinding. In the setting of plain FROST, the Preprocess step can be performed non-interactively, and thus the requirement of performing this step serially is no longer relevant.

Sign. To perform signing, \(\mathcal {SA}\) first sends (mB) to each participant, and each participant responds with \(\rho _i = a_{ij} + b_{ij} \cdot H_{\rho }(m, B)\), where B is derived similarly to in plain FROST via the ordered list of tuples \((i, D_{ij}, E_{ij}), i \in S\). In the second round, \(\mathcal {SA}\) then sends each \(\rho _i\) to each of the signing participants, who use these values to derive R and then to calculate their own response \(z_i\).

Fig. 4.
figure 4

FROST-interactive two-round preprocessing protocol

Fig. 5.
figure 5

FROST-interactive two-round signing protocol

figure d

Proof of Security for FROST-Interactive. We now present a proof of EUF-CMA security for FROST-Interactive, demonstrating that an adversary that can compute forgeries acting against FROST-Interactive can be used to compute the discrete logarithm of an arbitrary challenge value.

Let \(n_h\) be the number of queries made to the random oracle, \(n_p\) be the number of allowed preprocess queries, and \(n_s\) be the number of allowed signing queries.

Theorem 2

If the discrete logarithm problem in \(\mathbb {G}\) is \((\tau ', \epsilon ')\)-hard, then the FROST-Interactive signature scheme over \(\mathbb {G}\) with n signing participants, a threshold of t, and a preprocess batch size of \(\pi \) is \((\tau , n_h, n_p, n_s, \epsilon )\)-secure whenever

$$ \epsilon ' \le \frac{\epsilon ^2}{2 n_h + (\pi +1) n_p + 1} $$

and

$$ \tau ' = 4\tau + (30\pi n_p + (4t-2)n_s + (n+t-1)t + 6) \cdot t_{exp} + O(\pi n_p + n_s + n_h + 1) $$

such that \(t_{exp}\) is the time of an exponentiation in \(\mathbb {G}\), assuming the number of participants compromised by the adversary is less than the threshold t.

Proof

We prove the theorem by contradiction. Assume that \(\mathcal {F}\) can \((\tau , n_h, n_p, n_s, \epsilon )\)-break the unforgeability property of FROST-Interactive. We will demonstrate that an algorithm C that can \((\tau ', \epsilon ')\)-solve the discrete logarithm of an arbitrary challenge value \(\omega \in \mathbb {G}\). We first describe the simulator \(\mathcal {A}\), which uses \(\mathcal {F}\) as a black-box forger.

We now describe how \(\mathcal {A}\) simulates FROST-Interactive to \(\mathcal {F}\) in Algorithm 4. Recall that \(\mathcal {F}\) controls \(t-1\) participants, and \(\mathcal {A}\) simulates a single honest participant \(P_t\).

Let \(n_r = 2 n_h + (\pi + 1)n_p + 1\) denote the maximum number of random oracle outputs \(\mathcal {A}\) may require.

After performing the key generation phase as described in Sect. A.1, \(\mathcal {A}\) invokes \(\mathcal {F}\) to perform its forgery attack. \(\mathcal {A}\) simulates both the responses to the random oracle queries of \(\mathcal {F}\) as well as the role of \(P_t\) in the Preprocess and Sign algorithms.

Simulating Random Oracle Queries. For each random oracle query to \(H_{\rho }\), \(H_2\), \(H_3\), and \(H_4\), \(\mathcal {A}\) responds by first checking a corresponding associative table (initialized to empty on start) to see if the output has already been determined for that query. If no such output exists, \(\mathcal {A}\) sets the output to the next available value from \(\{ h_1, \dots , h_{n_r} \}\) supplied by \(GF_\mathcal {A}\) upon start, indicated by ctr. After setting the output, \(\mathcal {A}\) increments ctr and returns the freshly assigned output. In lieu of the \(H_1(i, m, B)\) hash function used in FROST (presented in Sect. 5.2), FROST-Interactive uses an interactive one-time VRF with input \(H_{\rho }(m, B)\) to provide this binding mechanism.

Simulating Preprocess. To perform the Preprocess stage, \(\mathcal {A}\) simulates the honest participant \(P_t\), following the protocol honestly with exception of the following steps. When generating \(D_{tj}\), \(\mathcal {A}\) first picks \(\bar{c}_j\) as the next available \(h_{ctr}\) value, and keeps track of which one it used by setting \(C[j] = ctr\) in a list C. \(\mathcal {A}\) randomly selects \(\bar{z}_{tj} \overset{\$}{\leftarrow }\mathbb {Z}_q\), and then derives \(D_{tj} = g^{\bar{z}_{tj}} \cdot {Y_t}^{-\bar{c}_j}\).

\(\mathcal {A}\) honestly computes and publishes its proof of knowledge of the \((a_{tj}, b_{tj})\) values in Round 2. However, during this round, \(\mathcal {A}\) itself forks \(\mathcal {F}\) in order to extract the discrete logarithms \((a_{\ell j}, b_{\ell j})\) of the commitment values \((A_{\ell j}, B_{\ell j})\) for all of the players \(P_\ell \) controlled by \(\mathcal {F}\). \(\mathcal {A}\) is able to learn these values by rewinding \(\mathcal {F}\) to the point before it makes the query \(\Phi = H_3(K_1, \dots , K_t)\), and programming the random oracle to return a different random output \(\Phi '\). Then, when \(\mathcal {F}\) republishes \(J_i : i \ne t\) for all dishonest parties that \(\mathcal {F}\) controls, \(\mathcal {A}\) can solve for the discrete log for each commitment.

Simulating Signing. \(\mathcal {F}\) initiates the FROST-Interactive signing protocol in the role of \(\mathcal {SA}\), sending (mB) in Round 1. Upon receiving these values, \(\mathcal {A}\) is able to compute not only its \(\rho _t\), but also all of the other \(\rho _\ell \) values for all of the other participants, because of its knowledge of the \((a_{\ell j}, b_{\ell j})\) that \(\mathcal {A}\) obtained during Round 2 of the preprocessing stage. Using these \(\rho _\ell \) values, it can compute the R that will be used in Round 2, and program \(H_2(R, Y, m) = \bar{c}_j\). It also saves C[j], the ctr value such that \(\bar{c}_k = h_{ctr}\), as \(J_2[R, Y, m]\) in a table \(J_2\).

Note that \(\mathcal {A}\) is never required to guess which output from the random oracle to program to correctly issue a signature, because \(\mathcal {A}\) can always compute R before \(\mathcal {F}\) can, and consequently can program the random oracle \(H_2(R, Y, m)\) with perfect success. Conversely, a signing request by \(\mathcal {A}\) in the simulation for plain Schnorr succeeds only with probability \(1/(n_h + n_s + 1)\) [3].

Finding the Discrete Logarithm of the Challenge Input. As described in Sect. A.1, using the two forgeries \((\sigma , \sigma ')\), the discrete logarithm of \(\omega \) can be derived.

Recall that the probability of \(\mathcal {F}\) succeeding for one run of \(\mathcal {A}\) is simply \(\epsilon \), as \(\mathcal {A}\) can return the correct challenge for each signing query. Then, using the forking lemma, the probability that the discrete logarithm of \(\omega \) can be extracted after \(\mathcal {A}\) is run twice is at least \(\frac{\epsilon ^2}{n_r}\) (ignoring the negligible \(\frac{\epsilon }{h}\) term, as h—the number of possible hash outputs—is typically at least \(2^{256}\)), and the total time required to extract the discrete logarithm of the challenge value is:

$$ \tau ' = 4\tau + (30\pi n_p + (4t-2)n_s + (n+t-1)t + 6) \cdot t_{exp} + O(\pi n_p + n_s + n_h + 1) $$

The running time for C to compute the discrete logarithm by procuring two forgeries from FROST-Interactive is four times that for \(\mathcal {F}\) (because of the forking of \(\mathcal {A}\), which itself forks \(\mathcal {F}\)), plus the time to compute \((30\pi n_p + (4t-2)n_s + (n+t-1)t + 6)\) exponentiations:

  • In simulating KeyGen, \((t-1)\cdot t\) to compute , 2 to compute R, and \(n\cdot t\) to compute \(Y_t\)

  • In each of two executions of \(\mathcal {A}\):

    • 7 in each of \(\pi \) iterations of Round 1 of simulating Preprocess,

    • 8\(\pi \) to validate each of two versions of \(t-1\) \(J_\ell \) lists in Round 2 of simulating Preprocess,

    • \(t-1\) to validate the \(\rho _\ell \) and t to compute R in each simulation of Sign,

    • 2 to compute R to verify the output of \(\mathcal {F}\).

and \(O(\pi n_p + n_s + n_h + 1)\) other minor operations, such as table lookups.

1.3 A.3  Extension of FROST-Interactive to FROST

In this section, we describe the changes we make to FROST-Interactive to remove one round of communication in each of the Preprocess and the Sign phases. We argue in Sect. 6 why our changes do not harm the security of the protocol.

Removal of One-Time Verifiable Random Functions to Generate \(\rho _i\). The primary difference between FROST-Interactive and FROST is that in the former, interactive one-time VRFs are used to generate the \(\rho _i\) binding values. In FROST, on the other hand, these values are generated with random oracles (modelling hash functions). Removing the one-time VRFs removes the VRF keys \((a_{ij},b_{ij})\) and their commitments \((A_{ij}, B_{ij})\) from the protocol.

Removal of One Round of the Sign Phase. With the one-time VRFs removed, all participants can compute every other participants’ \(\rho _i\) values non-interactively, and so the first round of the Sign protocol for FROST-Interactive (where participants exchange their \(\rho _i\) values) is no longer necessary for FROST.

Removal of the Proofs of Knowledge of the One-Time VRF Keys and One Round of the Preprocess Phase. As the one-time VRF keys are removed, so are their proofs of knowledge \(J_i\) in the Preprocess phase. Removing the \(J_i\) then makes the \(K_i\) unused, and removing the \(K_i\) removes the first round of the Preprocess phase.

Rights and permissions

Reprints and Permissions

Copyright information

© 2021 Springer Nature Switzerland AG

About this paper

Verify currency and authenticity via CrossMark

Cite this paper

Komlo, C., Goldberg, I. (2021). FROST: Flexible Round-Optimized Schnorr Threshold Signatures. In: Dunkelman, O., Jacobson, Jr., M.J., O'Flynn, C. (eds) Selected Areas in Cryptography. SAC 2020. Lecture Notes in Computer Science(), vol 12804. Springer, Cham. https://doi.org/10.1007/978-3-030-81652-0_2

Download citation

  • DOI: https://doi.org/10.1007/978-3-030-81652-0_2

  • Published:

  • Publisher Name: Springer, Cham

  • Print ISBN: 978-3-030-81651-3

  • Online ISBN: 978-3-030-81652-0

  • eBook Packages: Computer ScienceComputer Science (R0)