FROST: Flexible Round-Optimized Schnorr Threshold Signatures

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.

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.

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.

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. 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. Set $\phi _{t0}$ to be the challenge value $\omega$

• 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$.

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 (m, B). 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 (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$.

Fig. 4.

FROST-interactive two-round preprocessing protocol

Fig. 5.

FROST-interactive two-round signing protocol

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 (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:

$$ \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.