Abstract
Unlike signatures in a singleparty 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 networklimited devices or when coordination occurs over unreliable networks. In this work, we present FROST, a Flexible RoundOptimized 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 tworound protocol, or optimized to a singleround signing protocol with a preprocessing 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 chosenmessage 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
Notes
 1.
Signatures generated using the FROST protocol can also be referred to as “FROSTy signatures”.
 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.
Note that if n is small, the \(\lambda _i\) for every possible S can be precomputed as a performance optimization.
 4.
For example, authentication tokens or TLS certificates could serve to authenticate participants to one another.
 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 singleparty Schnorr signature scheme in Sect. 2.3.
 6.
A onetime 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.
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
Abidin, A., Aly, A., Mustafa, M.A.: Collaborative authentication using threshold cryptography. In: Emerging Technologies for Authorization and Authentication, pp. 122–137 (2020)
Bellare, M., Boldyreva, A., Staddon, J.: Randomness reuse in multirecipient encryption schemeas. In: Desmedt, Y.G. (ed.) PKC 2003. LNCS, vol. 2567, pp. 85–99. Springer, Heidelberg (2003). https://doi.org/10.1007/3540362886_7
Bellare, M., Neven, G.: Multisignatures in the plain publickey 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
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/0387347992_3
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
Boneh, D., Drijvers, M., Neven, G.: Compact multisignatures 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/9783030033293_15
Boneh, D., Lynn, B., Shacham, H.: Short signatures from the Weil pairing. J. Cryptol. 17(4), 297–319 (2004). https://doi.org/10.1007/s0014500403149
Cramer, R., Damgård, I., Ishai, Y.: Share conversion, pseudorandom secretsharing 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/9783540305767_19
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
Drijvers, M., et al.: On the security of tworound multisignatures. In: 2019 IEEE Symposium on Security and Privacy (SP), pp. 1084–1101 (2019)
Feldman, P.: A practical scheme for noninteractive 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
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
Gennaro, R., Goldfeder, S.: One round threshold ECDSA with identifiable abort. Technical report 2020/540, IACR ePrint (2020). https://eprint.iacr.org/2020/540
Gennaro, R., Jarecki, S., Krawczyk, H., Rabin, T.: Secure applications of Pedersen’s distributed key generation protocol. In: Topics in Cryptology – CTRSA 2003, pp. 373–390 (2003)
Gennaro, R., Jarecki, S., Krawczyk, H., Rabin, T.: Secure distributed key generation for discretelog based cryptosystems. J. Cryptol. 20(1), 51–83 (2006). https://doi.org/10.1007/s0014500603473
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
Josefsson, S., Liusvaara, I.: EdwardsCurve Digital Signature Algorithm (EdDSA), January 2017. https://tools.ietf.org/html/rfc8032
KZen Networks: Multi Party Schnorr Signatures (2019). https://github.com/KZennetworks/multipartyschnorr. Accessed Jan 2020
Lovecruft, I., de Valence, H.: The Ristretto Group (2020). https://doc.dalek.rs/curve25519_dalek/
Lueks, W.: Security and Privacy via Cryptography – Having your cake and eating it too (2017). https://wouterlueks.nl/assets/docs/thesis_lueks_def.pdf
Maxwell, G., Poelstra, A., Seurin, Y., Wuille, P.: Simple Schnorr multisignatures with applications to Bitcoin. Des. Codes Cryptogr. 87(9), 2139–2164 (2019). https://doi.org/10.1007/s1062301900608x
Mittal, P., Olumofin, F., Troncoso, C., Borisov, N., Goldberg, I.: PIRTor: scalable anonymous communication using private information retrieval. In: 20th USENIX Security Symposium, SEC 2011 (2011). http://dl.acm.org/citation.cfm?id=2028067.2028098
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/3540464166_47
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
Schnorr, C.: Security of blind discrete log signatures against interactive attacks. In: ICICS (2001)
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/0387348050_22
Shamir, A.: How to share a secret. Commun. ACM 22, 612–613 (1979)
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
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/3540457089_19
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 roguekey attacks in plain PedDKG 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 noninteractively generate secrets for Shamir secretsharing schemes by Lueks [20, §2.5.2].
We thank the Royal Bank of Canada and NSERC grant CRDPJ534381 for funding this work. This research was undertaken, in part, thanks to funding from the Canada Research Chairs program.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
A Proof of Security
A Proof of Security
In Sect. 6.2, we presented a highlevel overview of the proof of security for FROSTInteractive. We now present the proof in detail.
1.1 A.1 Preliminaries
Our proof strategy is to demonstrate that the security of FROSTInteractive 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 \(t1\) 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.
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_{J1}\), 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:
where IG is an input generator for a challenge input x. Then
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.
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 \(t1\) 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(t1)}\) for participant \(P_i\). To calculate and to distribute shares \(f_t(1), \dots , f_t(t1)\) to the \(t1\) participants corrupted by \(\mathcal {F}\), \(\mathcal {A}\) does the following:

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

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

3.
Calculate \(\phi _{t1}, \dots , \phi _{t(t1)}\) by performing Lagrange interpolation in the exponent, or \(\phi _{tk} = \omega ^{\lambda _{k0} } \cdot g^{ \sum _{i=1}^{t1} \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 , (t1, \bar{x}_{t(t1)})\) to the participants \(P_1, \dots , P_{t1}\) corrupted by \(\mathcal {F}\). Further, \(\mathcal {A}\) simulates the proof of knowledge for \(a_{t0}\) by deriving \(\sigma \) as:
\(\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}^{t1} \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 FROSTInteractive 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 longlived 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_{(t1)0})\) using the extractor for the zeroknowledge 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 \).
We can compute dlog(Y), because
and since \(h_J \ne h_J'\), then
The discrete logarithm corresponding to \(\omega \) can then be extracted as follows:
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 FROSTInteractive
Due to the difficulty of simulating zeroknowledge proofs in parallel, for the purposes of proving the security of FROST, we will first prove security against an interactive tworound variant of the FROST signing operation, which we call FROSTInteractive. In Sect. 6.2, we discuss how the security for FROSTInteractive extends to plain FROST.
FROSTInteractive. FROSTInteractive uses the same KeyGen protocol to generate longlived keys as regular FROST, as further described in Sect. 5.1. We present an overview of the Preprocess step for FROSTInteractive in Fig. 4, and the signing step in Fig. 5.
The distinction between the signing operations for plain FROST and FROSTInteractive is how the binding value \(\rho _i\) is generated. Because of the difficulty of simulating noninteractive zeroknowledge proofs of knowledge (NIZKPKs) in a concurrent setting, we instantiate FROSTInteractive using a onetime VRF, from which each participant generates their value \(\rho _i\) given the inputs (m, B). We prove this variant to be secure against the standard notion of EUFCMA security.
Preprocess. The Preprocess phase for FROSTInteractive differs from FROST in two ways. First, participants additionally generate onetime 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 zeroknowledge proof of knowledge for the \((a_{ij}, b_{ij})\) onetime VRF keys. These keys are later used to generate \(\rho _i\) during the signing phase.
We require Preprocess for FROSTInteractive to be performed serially so that the simulator can efficiently extract the discrete logarithm of the adversary’s noninteractive zero knowledge proof of knowledge of its VRF keys via rewinding. In the setting of plain FROST, the Preprocess step can be performed noninteractively, and thus the requirement of performing this step serially is no longer relevant.
Sign. To perform signing, \(\mathcal {SA}\) first sends (m, B) 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\).
Proof of Security for FROSTInteractive. We now present a proof of EUFCMA security for FROSTInteractive, demonstrating that an adversary that can compute forgeries acting against FROSTInteractive 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 FROSTInteractive 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
and
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 FROSTInteractive. 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 blackbox forger.
We now describe how \(\mathcal {A}\) simulates FROSTInteractive to \(\mathcal {F}\) in Algorithm 4. Recall that \(\mathcal {F}\) controls \(t1\) 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), FROSTInteractive uses an interactive onetime 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 FROSTInteractive signing protocol in the role of \(\mathcal {SA}\), sending (m, B) 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:
The running time for C to compute the discrete logarithm by procuring two forgeries from FROSTInteractive 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 + (4t2)n_s + (n+t1)t + 6)\) exponentiations:

In simulating KeyGen, \((t1)\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 \(t1\) \(J_\ell \) lists in Round 2 of simulating Preprocess,

\(t1\) 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 FROSTInteractive to FROST
In this section, we describe the changes we make to FROSTInteractive 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 OneTime Verifiable Random Functions to Generate \(\rho _i\). The primary difference between FROSTInteractive and FROST is that in the former, interactive onetime 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 onetime 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 onetime VRFs removed, all participants can compute every other participants’ \(\rho _i\) values noninteractively, and so the first round of the Sign protocol for FROSTInteractive (where participants exchange their \(\rho _i\) values) is no longer necessary for FROST.
Removal of the Proofs of Knowledge of the OneTime VRF Keys and One Round of the Preprocess Phase. As the onetime 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
Copyright information
© 2021 Springer Nature Switzerland AG
About this paper
Cite this paper
Komlo, C., Goldberg, I. (2021). FROST: Flexible RoundOptimized 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/9783030816520_2
Download citation
DOI: https://doi.org/10.1007/9783030816520_2
Published:
Publisher Name: Springer, Cham
Print ISBN: 9783030816513
Online ISBN: 9783030816520
eBook Packages: Computer ScienceComputer Science (R0)