Non-interactive Half-Aggregation of EdDSA and Variants of Schnorr Signatures

Abstract

Schnorr’s signature scheme provides an elegant method to derive signatures with security rooted in the hardness of the discrete logarithm problem, which is a well-studied assumption and conducive to efficient cryptography. However, unlike pairing-based schemes which allow arbitrarily many signatures to be aggregated to a single constant sized signature, achieving significant non-interactive compression for Schnorr signatures and their variants has remained elusive. This work shows how to compress a set of independent EdDSA/Schnorr signatures to roughly half their naive size. Our technique does not employ generic succinct proofs; it is agnostic to both the hash function as well as the specific representation of the group used to instantiate the signature scheme. We demonstrate via an implementation that our aggregation scheme is indeed practical. Additionally, we give strong evidence that achieving better compression would imply proving statements specific to the hash function in Schnorr’s scheme, which would entail significant effort for standardized schemes such as SHA2 in EdDSA. Among the others, our solution has direct applications to compressing Ed25519-based blockchain blocks because transactions are independent and normally users do not interact with each other.

Keywords

Y. Kondi—did part of this work during an internship at Novi Financial/Facebook Research.

Appendices

Appendix A Related work

1.1 Appendix A.1 Security Proofs

Schnorr signatures were proposed by Claus Schnorr [57], and in the original paper a compact version was proposed, which outputted signatures of size $3\lambda$, where $\lambda$ is the provided security level (i.e. 128). In 1996, Pointcheval and Stern [53] applied their newly introduced Forking Lemma to provide the first formal security for a $2\lambda$-bit ideal hash assuming the underlying discrete logarithm is hard. In [59] the first proof of Schnorr’s ID against active attacks is provided in the GGM (Generic Group Model), but without focus on Fiat-Shamir constructions.

A significant contribution from Neven et al.  [48] was to apply the GGM and other results of [7] to prove security using a $\lambda$-bit hash function. Briefly, in their proof, hash functions are not handled as random oracles, but they should offer specific properties, such as variants of preimage and second preimage resistance; but not collision resistance. However, as we mention in Section A.3, most of the real world applications do not assume honest signers, and thus non-repudiation is an important property, which unfortunately requires a collision resistant $H_0$.

Finally, the works from Backendal et al. [2] clarified the relation between the UF-security of different Schnorr variants, while in [31] a tight reduction of the UF-security of Schnorr signatures to discrete log in the Algebraic Group Model [30] (AGM)+ROM was presented.

1.2 Appendix A.2 Multi-signatures

One of the main advantages of Schnorr signatures compared to ECDSA is its linearity which allows to add two (or more) Schnorr signatures together and get a valid compact aggregated output indistinguishable from a single signature. The concept of multi-signature is to allow co-signing on the same message. Even if the messages are different, there are techniques using indexed Merkle tree accumulators to agree on a common tree root and then everyone signs that root. However, just adding Schnorr signatures is not secure as the requirement to protect against rogue key and other similar attacks is essential, especially in blockchain systems.

There is indeed a number of practical proposals that require two or three rounds of interaction until co-signers agree on a common R and public key A value [3, 7, 11, 23, 41, 43, 45, 49, 50, 56, 60]. One of the most recent is the compact two-round Musig2 [49] which also supports pre-processing (before co-signers learn the message to be signed) of all but the first round, effectively enabling a non-interactive signing process. Musig2 security is proven in the AGM+ROM model and it relies on the hardness of the OMDL problem.

Another promising two-round protocol is FROST [41] which has a similar logic with Musig2, but it utilizes verifiable random functions (VRFs) and mostly considers a threshold signature setting.

Note that even with pre-processing, Musig2 requires an initial setup with broadcasting and maintaining state. Compared to half-aggregation which can work with zero interaction between signers, Musig2 and FROST have a huge potential for controlled environments (i.e., validator sets in blockchains), but might not be ideal in settings where the co-signers do not know each other in advance or when public keys and group formation are rotated/updated very often.

1.3 Appendix A.3 Schnorr signature variants

There exist multiple variants of the original Schnorr scheme and the majority of them are incompatible between each other. Some of the most notable differences include:

• $H_0$ is not binding to the public key and thus it’s computed as $H_0(R||m)$ instead of $H_0(R||A||m)$ [32, 57]. Note that these signatures are malleable as shown in the EdDSA paper (page 7, Malleability paragraph) [10].

• $H_0$ changing the order of inputs in $H_0$, such as $H_0(m||R)$. Note that protocols in which m is the first input to the hash function require collision resistant hash functions, as a malicious message submitter (who doesn’t know R), can try to find two messages $m_0$ and $m_1$ where $H_0(m_0) = H_0(m_1)$. This is the main reason for which the Pure EdDSA RFC 8032 [39] suggests $H_0(R||A||m)$ versus any other combination.

• $H_0$ takes as inputs only the x-coordinate of R, such as the EC-SDSA-opt in [32] and BIP-Schnorr [52].

• send the scalar $H_0$ instead of the point R. This variation (often referred to as compact) was proposed in the original Schnorr paper [57] and avoids the minor complexity of encoding the R point in the signature, while it allows for potentially shorter signatures by 25%. The idea is that only half of the $H_0$ bytes suffice to provide SUF-CMA security at the target security level of 128 bits. While this allows 48-byte signatures, there are two major caveats:

  • according to Bellare et al. [6] (page 39), the (R, S) version (mentioned as BNN in that paper) achieves semi-strong unforgeability, while the original 48-byte Schnorr only normal unforgeability. In short, because finding collisions in a short hash function is easy, a malicious signer can break message binding (non-repudiation) by finding two messages $m_0$ and $m_1$ where $truncated(H(R || A || m_0)) == truncated(H(R || A || m_1))$

  • as mentioned, collisions in 128-bit truncated $H_0$ require a 64-bit effort. But because the SUF-CMA model assumes honest signers, in multi-sig scenarios where potentially distrusting signers co-sign, some malicious coalition can try to obtain a valid signature on a message that an honest co-signer did not intend to sign.

Due to the above, and because compact signatures do not seem to support non-interactive aggregation or batch verification, it is clear that this work is compatible with most of the (R, S) Schnorr signature variants, EdDSA being one of them. Also note that half-aggregation achieves an asymptotic 50% size reduction and compares favorably against multiple compact Schnorr signatures.

1.4 Appendix A.4 Non-Schnorr schemes

Some of the best applications of non-interactive signature aggregation include shortening certificate chains and blockchain blocks. Putting Schnorr variants aside, there is a plethora of popular signature schemes used in real world applications including ECDSA, RSA, BLS and some newer post-quantum schemes i.e., based on hash functions or lattices. Regarding ECDSA, although there exist interactive threshold schemes, to the best of our knowledge there is no work around non-interactive aggregation, mainly due to the modular inversion involved [44]. Similarly, in RSA two users cannot share the same modulus N, which makes interactivity essential; however there exist sequential aggregate RSA signatures which however imply interaction [13]. Along the same lines, we are not aware of efficient multi-sig constructions for Lamport-based post-quantum schemes.

On the other hand, BLS is considered the most aggregation and blockchain friendly signature scheme, which by design allows for deriving a single signature from multiple outputs without any prior interaction and without proving knowledge or possession of secret keys [11]. The main practicality drawback of BLS schemes is that they are based on pairing-friendly curves and hashing to point functions for which there are on-going standardization efforts and limited HSM support. Also, the verification function of a rogue-key secure BLS scheme is still more expensive than Schnorr (aggregated or not) mainly due to the slower pairing computations.

1.5 Appendix A.5 Schnorr batching and aggregation

Similar approaches to generating linear combinations of signatures have been used for batch verification in the past as shown in Sect. 4. The original idea of operating on a group of signatures by means of a random linear combination of their members is due to Bellare et al. [4]. Other approaches consider an aggregated signature from public keys owned by the same user, which removes the requirement for rogue key resistance. For instance, in [33] an interactive batching technique is provided resulting to faster verification using higher degree polynomials.

Half-aggregation has already been proposed in the past, but either in its simple form without random linear combinations [24] (which is prone to rogue key attacks) or using non-standard Schnorr variants that are not compatible with EdDSA. $\varGamma$-signatures [62] are the closest prior work to our approach, also achieving half aggregation, but with a significantly modified and slightly slower Schnorr scheme. Additionally, their security is based on the custom non-malleable discrete logarithm (NMDL) assumption, although the authors claim that it could easily be proven secure against the stronger explicit knowledge-of-exponent assumption EKEA. On the other hand, we believe that our security guarantees are much more powerful as they are actually a proof of knowledge of signatures, which means that they can be used as a drop-in replacement in any protocol (where having the exact original signature strings is not important), without changing any underlying assumptions; and therefore be compliant with the standards.

Appendix B EdDSA signatures

EdDSA signature [10] is originally defined over Curve25519 in its twisted Edwards form and is often called Ed25519. The scheme provides $\sim$ 128 bits of security. The general name, EdDSA, refers to instantiation of the scheme over any compatible elliptic curve. Another notable instantiation is Ed448 [34, 39] offering $\sim$ 224 bits of security. A concrete instantiation of the scheme would depend on the elliptic curve and the security level. The Algorithm 8 is given in the most general form.

Appendix C Single signature security

An attacker $\mathcal {A}$ plays the following game:

  security game:

• 1. $(\textsf {pk}^*, \textsf {sk}^*) \leftarrow \mathsf {KeyGen}()$

• 2. $(m, \sigma ) \leftarrow \mathcal {A}^{O_{\textsf {Sign}(\textsf {sk}^*, \cdot )}}(\textsf {pk}^*)$

• 3. accept if $m_i \notin \mathcal {L}_{\textsf {Sign}}\; \wedge \;\mathsf {Verify}(m, \textsf {pk}^*, \sigma )$

  , the signing oracle, constructs the set $\mathcal {L}_{\textsf {Sign}}$:

• 1. On input m, compute $\sigma \leftarrow \mathsf {Sign}(\textsf {sk}^*, m)$

• 2. $\mathcal {L}_{\textsf {Sign}} \leftarrow \mathcal {L}_{\textsf {Sign}} \cup m$

• 3. return $\sigma$

Definition 3

An attacker $\mathcal {A}$, $(t, \epsilon )$-breaks a EUF-CMA security of the signature scheme if $\mathcal {A}$ runs in time at most t and wins the EUF-CMA game with probability $\epsilon$. A signature scheme is $(t, \epsilon )$-EUF-CMA-secure if no forger $(t, \epsilon )$-breaks it.

Likewise, if the scheme is $(t, \epsilon )$-EUF-CMA-secure, we say that it achieves $\log _2(t/\epsilon )$-bits security level.

Note also that there is an additional requirement on single signature security which becomes increasingly important especially in blockchain applications is Strong Binding [19], it prevents a malicious signer from constructing a signature that is valid against different public keys and/or different messages. We define the associated game:

  security game:

• 1. $(\textsf {pk}, m, \textsf {pk}', m', \sigma ) \leftarrow \mathcal {A}()$

• 2. accept if $(\textsf {pk}, m) \ne (\textsf {pk}', m')\; \wedge \; \mathsf {Verify}(m, \textsf {pk}, \sigma )\; \wedge \; \mathsf {Verify}(m', \textsf {pk}', \sigma )$

Definition 4

An attacker $\mathcal {A}$, $(t, \epsilon )$-breaks SBS security of the signature scheme if $\mathcal {A}$ runs in time at most t and wins the SBS game with probability $\epsilon$. A signature scheme is $(t, \epsilon )$-SBS-secure if no forger $(t, \epsilon )$-breaks it.

Appendix D Proof of Theorem 6

Proof

By statistical argument we show that the adversary may only produce an SBS forgery with negligible probability. For a successful forgery $((A_1, m_1), \ldots , (A_n, m_n), \sigma _{\textsf {aggr}}) \ne ((A'_1, m'_1), \ldots (A'_2, m'_2), \sigma _{\textsf {aggr}})$, all 2n underlying signatures can be extracted: $\sigma _1, \ldots , \sigma _n, \sigma '_1, \ldots , \sigma '_n$. All of those signatures have the same R components (since those are part of $\sigma _{\textsf {aggr}}$), but possibly different S components. When a query is made to the random oracle $H_1(R_1, A_1, m_1, \ldots , R_n, A_n, m_n, i)$, denote the output by $h^j_i$, where j is the incrementing counter for the unique tuples $(R_1, A_1, m_1, \ldots , R_n, A_n, m_n)$ queried to the random oracle. Denote by $s^j_i$ the discrete log of $R_1 + H_0(R_i, A_i, m_i) A_i$ (here we work under the assumption that the discrete log can always be uniquely determined). Without loss of generality we assume that the adversary verifies the forgery, therefore for some two indices $j'$ and $j''$ (that correspond to the SBS forgery output by the adversary) it must hold that the linear combination of the $\{s^{j'}_i\}_{i = 1}^n$’s with coefficients $\{h^{j'}_i\}_{i=1}^n$ is equal to the linear combination of $\{s^{j''}_i\}_{i = 1}^n$’s with coefficients $\{h^{j''}_i\}_{i=1}^n$. Having that in the RO-model, we can assume that the values $\{h^{j'}_i\}_{i=1}^n$ and $\{h^{j''}_i\}_{i=1}^n$ are programmed to uniformly random independent values after the s’s values are determined. Each h randomizes the non-zero value of s to an exponent indistinguishable from random, therefore creating a random element as a result of a linear combination. Therefore the probability of a successful forgery for the adversary must be bounded by the collision probability $Q^2 / (2 \cdot |\mathbb {G}|)$, where $Q \le t$ is the number of $H_1$-queries and $|\mathbb {G}|$ is the size of the group (for prime order groups, or an order of a base point).    $\square$

Appendix E Proof of Theorem 8

Proof

From the forgery produced by the adversary $\mathsf {Adv}_1$: $((m_1, \textsf {pk}_1), \ldots , (m_n, \textsf {pk}_n), (m'_1, \textsf {pk}'_1), \ldots , (m'g_n, \textsf {pk}'_n), \sigma _{\textsf {aggr}})$,

we extract two sets of signatures by running the extractor of Theorem 4: $(\sigma _1, \ldots , \sigma _n)$ and $(\sigma '_1, \ldots , \sigma '_n)$. Those signatures have the same R-components ($R_1, \ldots , R_n$), but possibly different S-components $(S_1, S'_1, \ldots , S_n, S'_n)$ when aggregated those components produce the same signature $\sigma$, therefore for some random $e \ne e'$, it holds that $\sum _{i = 1}^n S_i \cdot e^{i-1} = \sum _{i = 1}^n S'_i \cdot e'^{i-1}$ which may happen with probability at most $2^{\lambda }$ when $(S_1, \ldots , S_n) \ne (S'_1, \ldots , S'_n)$. Assuming that $(S_1, \ldots , S_n) = (S'_1, \ldots , S'_n)$, but $\left[ (m_1, \textsf {pk}_1), \ldots , (m_n, \textsf {pk}_n)\right] \ne \left[ (m'_1, \textsf {pk}'_1), \ldots , (m'_n, \textsf {pk}'_n)\right]$, as required for the forgery of $\mathsf {Adv}_1$ to be successful, it follows that at some position $i \in [n]$ where the equality breaks, a successful single SBS-forgery can be constructed: $(m_i, \textsf {pk}_i, m'_i, \textsf {pk}'_i, \sigma = (R_i, S_i))$.    $\square$

Appendix F Parameter selection for almost-half-aggregation

In this section we explain a methodology of picking parameters for aggregation scheme described in Algorithm 7.

However, as we explain next, it is more efficient to do the aggregation in batches, i.e. aggregate some fixed constant number of signatures, choosing this number to achieve a desired trade-off between compression rate, aggregation time and verification time. The computational complexity of the aggregator is $O(r \cdot n \cdot 2^\ell )$ and of the verifier is $O(n \cdot r)$. In fact, in this scheme the verifier is about $r/2 > 1$ times less efficient than verifying signatures iteratively one-by-one, therefore this compression scheme will always sacrifice verifier’s computational efficiency for compressed storage or network bandwidth for transmission of signatures. The aggregator’s complexity is by far greater than the verifier’s, we approximate it next through compression rate c and batch size n. The compression rate can be approximated as

$$\begin{aligned} c = (256 \cdot n + r \cdot 256 + r \cdot \ell ) / (512 \cdot n) \approx (n + r) / (2n). \end{aligned}$$

We can estimate the aggregator’s time through $r = n (2c - 1)$ as $O(n^3 \cdot (2c - 1) \cdot 2^{\lambda /n/(2c-1)})$. For a fixed compression rate c it achieves minimum at a batch-size n shown on Fig. 1 for $\lambda = 128$. The verifier’s time can be estimated through compression rate as $O(n^2 (2c - 1))$, it is therefore most optimal to select an upper bound on the batch size according to Fig. 1 and lower the batch-size to trade-off between aggregator’s and verifier’s runtime. We report optimal aggregation times for the given compression rate in Fig. 2 for Ed25519 signature scheme. Amortized verification per signature is constant for constant r, amortized optimal aggregation per signature is linear in the batch size n.

Fig. 1.

Optimal batch size to achieve the minimum aggregation time.

Fig. 2.

Aggregation and verification time amortized per signature. Parameters n, r are set to achieve the smallest aggregation time: n is chosen from Fig. 1, $r = 30$.

Appendix G Formal analysis for the impossibility of non-interactive compression by more than a half

This section expands on the impossibility of non-interactive compression by more than half and extends Sect. 5. We first fix the exact distribution of signatures that must be aggregated, and then reason about the output of any given aggregation scheme on this input.

$\mathsf {GenSigs} (n,1^\lambda )$:

• 1. For each $i\in [n]$, sample $(\textsf {pk}_i,\textsf {sk}_i)\leftarrow \mathsf {KeyGen}(1^\lambda )$ and $r_i\leftarrow F_s$, and compute $R_i=r_i\cdot B$ and $\sigma _i = \textsf {sk}_i\cdot \mathsf {RO} (\textsf {pk}_i, R_i ,0) + r_i$

• 2. Output $(\textsf {pk}_i,R_i,\sigma _i)_{i\in [n]}$

The $\mathsf {GenSigs}$ algorithm simply creates n uniformly sampled signatures on the message ‘0’.

Theorem 9

Let $(\mathsf {AggregateSig}, \mathsf {AggregateVerify})$ characterize an aggregate signature scheme for $\mathsf {KeyGen},\mathsf {Sign},\mathsf {Verify}$ as per Schnorr with group $(\mathbb {G},B,q)$ such that $|q|=2\lambda$. Let $\mathcal {Q} _V$ be the list of queries made to $\mathsf {RO}$ by

$$\mathsf {AggregateVerify} ^{\mathsf {RO}}(\mathsf {AggregateSig}^{\mathsf {RO}}(\{\textsf {pk}_i,R_i,\sigma _i\}_{i\in [n]}))$$

where $(\textsf {pk}_i,R_i,\sigma _i)_{i\in [n]}\leftarrow \mathsf {GenSigs} (n,1^\lambda )$. Then for any n, $\mathsf {max}((\Pr [(\textsf {pk}_i,R_i,0) \not \in \mathcal {Q} _V])_{i\in [n]})$ is negligible in $\lambda$.

Proof

Let $\varepsilon = \mathsf {\max }((\Pr [(\textsf {pk}_i,R_i,0) \not \in \mathcal {Q} _V])_{i\in [n]})$, and let $j\in [n]$ be the corresponding index. We now define an alternative signature generation algorithm as follows,

$\mathsf {GenSigs} ^*(n,j,\textsf {pk}_j,1^\lambda )$:

• 1. For each $i\in [n]\setminus j$, sample $(\textsf {pk}_i,\textsf {sk}_i)\leftarrow \mathsf {KeyGen}(1^\lambda )$ and $r_i\leftarrow F_s$, and compute $R_i=r_i\cdot B$ and $\sigma _i = \textsf {sk}_i\cdot \mathsf {RO} (\textsf {pk}_i, R_i ,0) + r_i$

• 2. Sample $\sigma _j\leftarrow F_s$ and $e_j\leftarrow F_s$

• 3. Set $R_j = \sigma _i\cdot B - e_j\cdot \textsf {pk}_j$

• 4. Output $(\textsf {pk}_i,R_i,\sigma _i)_{i\in [n]}$

Observe the following two facts about $\mathsf {GenSigs} ^*$: (1) it does not use $\textsf {sk}_j$, and (2) the distributions of $\mathsf {GenSigs}$ and $\mathsf {GenSigs} ^*$ appear identical to any algorithm that does not query $(\textsf {pk}_i,R_i,0)$ to $\mathsf {RO}$. The first fact directly makes $\mathsf {GenSigs} ^*$ conducive to an adversary in the aggregated signature game: given challenge public key $\textsf {pk}$, simply invoke $\mathsf {GenSigs} ^*$ with $\textsf {pk}_j=\textsf {pk}$ to produce $(\textsf {pk}_i,R_i,\sigma _i)_{i\in [n]}$ and then feed these to $\mathsf {AggregateSig}$⁵. The advantage this simple adversary is given by the probability that the verifier does not notice that that $\mathsf {GenSigs} ^*$ did not supply a valid signature under $\textsf {pk}^*$ to $\mathsf {AggregateSig}$, and we can quantify this using the second fact as follows:

$$\begin{aligned}&\Pr [\mathsf {AggregateVerify} ^{\mathsf {RO}}(\mathsf {AggregateSig}^{\mathsf {RO}}(\mathsf {GenSigs} ^*(n,j,\textsf {pk}_j,1^\lambda )))=1] \\&= \Pr [\mathsf {AggregateVerify} ^{\mathsf {RO}}(\mathsf {AggregateSig}^{\mathsf {RO}}(\mathsf {GenSigs} (n,1^\lambda )))=1] - \Pr [(\textsf {pk}_i,R_i,0) \in \mathcal {Q} _V] \\&= 1 - \Pr [(\textsf {pk}_i,R_i,0) \in \mathcal {Q} _V] \\&= 1 - (1-\varepsilon ) = \varepsilon \end{aligned}$$

Assuming unforgeability of the aggregated signature scheme, $\varepsilon$ must be negligible.    $\square$