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 wellstudied assumption and conducive to efficient cryptography. However, unlike pairingbased schemes which allow arbitrarily many signatures to be aggregated to a single constant sized signature, achieving significant noninteractive 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 Ed25519based blockchain blocks because transactions are independent and normally users do not interact with each other.
Keywords
 Schnorr
 EdDSA
 Signatures
 Aggregation
Y. Kondi—did part of this work during an internship at Novi Financial/Facebook Research.
This is a preview of subscription content, access via your institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsNotes
 1.
Even for shortened Schnorr signatures \(\sigma = (H(R,\textsf {pk},m),S)\), where the output of the hash function is halved, signatures are at least \(3\lambda \) bits, i.e. 50% larger than the amount of information they carry.
 2.
An anonymous reviewer suggested a PRF could be used to derive the values of y from a single seed in order to save space for an implementation of the reduction.
 3.
Note that additionally \(2\log _2(n)+1\) bits of security will be lost due to n.
 4.
The ‘curve25519dalek’ and ‘ed25519dalek’ libraries were used for the benchmark of this entire section, which ran on a AMD Ryzen 9 3950X 16Core CPU. We used the scalar u64 backend of the dalek suite of libraries, to offer comparable results across a wide range of architectures, and the implementation does make use of Pippenger’s bucketization algorithm for multiexponentiation.
 5.
If necessary, intercept \((\textsf {pk}_j,R_j,0)\) queried by \(\mathsf {AggregateSig}\) to \(\mathsf {RO} \), and respond with \(e_j\) as set by \(\mathsf {GenSigs} ^*\).
References
Aranha, D.F., Orlandi, C., Takahashi, A., Zaverucha, G.: Security of hedged fiatshamir signatures under fault attacks. In: Eurocrypt (2020)
Backendal, M., Bellare, M., Sorrell, J., Sun, J.: The fiatshamir zoo: relating the security of different signature variants. In: Nordic Conference on Secure IT Systems, pp. 154–170. Springer (2018)
Bagherzandi, A., Cheon, J.H., Jarecki, S.: Multisignatures secure under the discrete logarithm assumption and a generalized forking lemma. In: ACM CCS (2008)
Bellare, M., Garay, J.A., Rabin, T.: Fast batch verification for modular exponentiation and digital signatures. In: Nyberg, K. (ed.) EUROCRYPT 1998. LNCS, vol. 1403, pp. 236–250. Springer, Heidelberg (1998). https://doi.org/10.1007/BFb0054130
Bellare, M., Goldreich, O.: On defining proofs of knowledge. In: Brickell, E.F. (ed.) Advances in Cryptology  CRYPTO’92. Lecture Notes in Computer Science, vol. 740, pp. 390–420. Springer, Heidelberg (1993)
Bellare, M., Namprempre, C., Neven, G.: Security proofs for identitybased identification and signature schemes. J. Cryptol. 22(1), 1–61 (2009)
Bellare, M., Neven, G.: Multisignatures in the plain publickey model and a general forking lemma. In: ACM CCS (2006)
BenSasson, E., Bentov, I., Horesh, Y., Riabzev, M.: Scalable, transparent, and postquantum secure computational integrity. Cryptology ePrint Archive, Report 2018/046 (2018). https://eprint.iacr.org/2018/046
BenSasson, E., Chiesa, A., Riabzev, M., Spooner, N., Virza, M., Ward, N.P.: Aurora: transparent succinct arguments for R1CS. In: Eurocrypt (2019)
Bernstein, D.J., Duif, N., Lange, T., Schwabe, P., Yang, B.Y.: Highspeed highsecurity signatures. In: CHES (2011)
Boneh, D., Drijvers, M., Neven, G.: Compact multisignatures for smaller blockchains. In: Asiacrypt (2018)
Boneh, D., Gentry, C., Lynn, B., Shacham, H.: Aggregate and verifiably encrypted signatures from bilinear maps. In: Eurocrypt (2003)
Boneh, D., Gentry, C., Shacham, H., et al.: A survey of two signature aggregation techniques, Ben Lynn (2003)
Boneh, D., Lynn, B., Shacham, H.: Short signatures from the Weil pairing. In: Asiacrypt (2001)
Breitner, J., Heninger, N.: Biased nonce sense: Lattice attacks against weak ECDSA signatures in cryptocurrencies. In: International Conference on Financial Cryptography and Data Security, pp. 3–20. Springer (2019)
Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., Maxwell, G.: Bulletproofs: short proofs for confidential transactions and more. In: IEEE S&P, pp. 315–334 (2018)
Canetti, R.: Universally composable security: a new paradigm for cryptographic protocols. In: FOCS (2001)
Chalkias, K., Garillot, F., Kondi, Y., Nikolaenko, V.: ed25519dalekfiat, branch:halfaggregation (2021). https://github.com/novifinancial/ed25519dalekfiat/tree/halfaggregation
Chalkias, K., Garillot, F., Nikolaenko, V.: Taming the many EDDSAS. Technical Report, Cryptology ePrint Archive, Report 2020/1244 (2020). https://eprint.iacr.org/2020/1244
Checkoway, S., et al.: A systematic analysis of the juniper dual EC incident. In: ACM CCS (2016)
Courtois, N.T., Emirdag, P., Valsorda, F.: Private key recovery combination attacks: on extreme fragility of popular bitcoin key management, wallet and cold storage solutions in presence of poor RNG events (2014)
Djvm  the deterministic JVM library (2020)
Drijvers, M., et al.: On the security of tworound multisignatures. In: 2019 IEEE Symposium on Security and Privacy (SP), pp. 1084–1101. IEEE (2019)
Dryja, T.: Perblock noninteractive Schnorr signature aggregation (2017)
Everspaugh, A., Zhai, Y., Jellinek, R., Ristenpart, T., Swift, M.: NotSoRandom numbers in virtualized linux and the whirlwind RNG. In: 2014 IEEE Symposium on Security and Privacy, pp. 559–574. IEEE (May 2014)
Fernandes, D.A.B., Soares, L.F.B., Freire, M.M., Inacio, P.R.M.: Randomness in virtual machines. In: 2013 IEEE/ACM 6th International Conference on Utility and Cloud Computing, pp. 282–286. IEEE (Dec 2013)
Fiat, A., Shamir, A.: How to prove yourself: practical solutions to identification and signature problems. In: Crypto (1987)
Fischlin, M.: Communicationefficient noninteractive proofs of knowledge with online extractors. In: Crypto (2005)
Fleischhacker, N., Jager, T., Schröder, D.: On tight security proofs for Schnorr signatures. J. Cryptol. 32(2), 566–599 (2019)
Fuchsbauer, G., Kiltz, E., Loss, J.: The algebraic group model and its applications. In: Crypto (2018)
Fuchsbauer, G., Plouviez, A., Seurin, Y.: Blind Schnorr signatures and signed elgamal encryption in the algebraic group model. In: Eurocrypt (2020)
Bundesamt für Sicherheit in der Informationstechnik (BSI). Elliptic curve cryptography, Technical Guideline TR03111 (2009)
Gennaro, R., Leigh, D., Sundaram, R., Yerazunis, W.S.: Batching Schnorr identification scheme with applications to privacypreserving authorization and lowbandwidth communication devices. In: Asiacrypt (2004)
Hamburg, M.: Ed448goldilocks, a new elliptic curve. Cryptology ePrint Archive, Report 2015/625 (2015). http://eprint.iacr.org/2015/625
Hazay, C., Lindell, Y.: Efficient Secure TwoParty Protocols: Techniques and Constructions, 1st edn. SpringerVerlag, Berlin (2010)
Hazay, C., Lindell, Y.: A note on zeroknowledge proofs of knowledge and the ZKPOK ideal functionality. IACR Cryptol. ePrint Arch. 2010, 552 (2010)
Heninger, N., Durumeric, Z., Wustrow, E., Halderman, J.A.: Mining your PS and QS: detection of widespread weak keys in network devices. In: USENIX Security Symposium (2012)
Itakura, K., Nakamura, K.: A publickey cryptosystem suitable for digital multisignatures. In: NEC Research & Development (1983)
Josefsson, S., Liusvaara, I.: Edwardscurve digital signature algorithm (EdDSA) (2017)
Kerrigan, B., Chen, Yu.: A study of entropy sources in cloud computers: random number generation on cloud hosts. In: Kotenko, I., Skormin, V. (eds.) MMMACNS 2012. LNCS, vol. 7531, pp. 286–298. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642337048_24
Komlo, C., Goldberg, I.: Frost: flexible roundoptimized Schnorr threshold signatures. IACR Cryptol. ePrint Arch (2020)
Kumari, R., Alimomeni, M., SafaviNaini, R.: Performance analysis of linux RNG in virtualized environments. In: ACM Workshop on Cloud Computing Security Workshop (2015)
Ma, C., Weng, J., Li, Y., Deng, R.: Efficient discrete logarithm based multisignature scheme in the plain public key model. Designs Codes Cryptograph. 54(2), 121–133 (2010)
Maxwell, G., Poelstra, A., Seurin, Y., Wuille, P.: Simple Schnorr multisignatures with applications to bitcoin. Cryptology ePrint Archive, Report 2018/068 (2018). https://eprint.iacr.org/2018/068
Maxwell, G., Poelstra, A., Seurin, Y., Wuille, P.: Simple Schnorr multisignatures with applications to bitcoin. Designs Codes Cryptograph. 87(9), 2139–2164 (2019)
Micali, S., Ohta, K., Reyzin, L.: Accountablesubgroup multisignatures. In: ACM CCS (2001)
Michaelis, Kai, Meyer, Christopher, Schwenk, Jörg.: Randomly failed! the state of randomness in current java implementations. In: Dawson, Ed. (ed.) CTRSA 2013. LNCS, vol. 7779, pp. 129–144. Springer, Heidelberg (2013). https://doi.org/10.1007/9783642360954_9
Neven, G., Smart, N.P., Warinschi, B.: Hash function requirements for Schnorr signatures. J. Math. Cryptol. 3(1), 69–87 (2009)
Nick, J., Ruffing, T., Seurin, Y.: Musig2: Simple tworound Schnorr multisignatures. IACR Cryptol. ePrint Arch. Technical Report (2020)
Nick, J., Ruffing, T., Seurin, Y., Wuille, P.: Musigdn: Schnorr multisignatures with verifiably deterministic nonces. In: ACM CCS (2020)
Pass, R.: On deniability in the common reference string and random oracle model. In: Crypto (2003)
Pieter, W., Jonas, N., Tim.: BIP: 340, Schnorr signatures for secp256k1 (2020)
Pointcheval, D., Stern, J.: Security proofs for signature schemes. In: Eurocrypt (1996)
Pointcheval, D., Stern, J.: Security arguments for digital signatures and blind signatures. J. Cryptol. 13(3), 361–396 (2000)
Ristenpart, T., Yilek, S.: When good randomness goes bad: virtual machine reset vulnerabilities and hedging deployed cryptography. In: NDSS (2010)
Ristenpart, T., Yilek, S.: The power of proofsofpossession: securing multiparty signatures against roguekey attacks. In: Eurocrypt (2007)
Schnorr, C.P.: Efficient signature generation by smart cards. J. Cryptol. 4(3), 161–174 (1991)
Seurin, Y.: On the exact security of Schnorrtype signatures in the random oracle model. In: Eurocrypt (2012)
Shoup, V.: Lower bounds for discrete logarithms and related problems. In: Eurocrypt (1997)
Syta, E.: Keeping authorities “honest or bust” with decentralized witness cosigning. In: IEEE S&P (2016)
Yilek, S., Rescorla, E., Shacham, H., Enright, B., Savage, S.: When private keys are public: Results from the 2008 Debian OpenSSL vulnerability. In: ACM SIGCOMM Internet Measurement Conference IMC (2009)
Zhao, Y.: Aggregation of gammasignatures and applications to bitcoin. IACR Cryptol. ePrint Arch. 2018, 414 (2018)
Acknowledgement
The authors would like to thank Payman Mohassel (Novi/Facebook) and Isis Lovecruft for insightful discussions at the early stages of this work; and all anonymous reviewers of this paper for comments and suggestions that greatly improved the quality of this paper.
Author information
Authors and Affiliations
Editor information
Editors and Affiliations
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 FiatShamir 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 nonrepudiation 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 UFsecurity of different Schnorr variants, while in [31] a tight reduction of the UFsecurity of Schnorr signatures to discrete log in the Algebraic Group Model [30] (AGM)+ROM was presented.
1.2 Appendix A.2 Multisignatures
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 multisignature is to allow cosigning 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 cosigners 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 tworound Musig2 [49] which also supports preprocessing (before cosigners learn the message to be signed) of all but the first round, effectively enabling a noninteractive signing process. Musig2 security is proven in the AGM+ROM model and it relies on the hardness of the OMDL problem.
Another promising tworound 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 preprocessing, Musig2 requires an initial setup with broadcasting and maintaining state. Compared to halfaggregation 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 cosigners 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(Rm)\) instead of \(H_0(RAm)\) [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(mR)\). 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(RAm)\) versus any other combination.

\(H_0\) takes as inputs only the xcoordinate of R, such as the ECSDSAopt in [32] and BIPSchnorr [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 SUFCMA security at the target security level of 128 bits. While this allows 48byte 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 semistrong unforgeability, while the original 48byte Schnorr only normal unforgeability. In short, because finding collisions in a short hash function is easy, a malicious signer can break message binding (nonrepudiation) 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 128bit truncated \(H_0\) require a 64bit effort. But because the SUFCMA model assumes honest signers, in multisig scenarios where potentially distrusting signers cosign, some malicious coalition can try to obtain a valid signature on a message that an honest cosigner did not intend to sign.

Due to the above, and because compact signatures do not seem to support noninteractive 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 halfaggregation achieves an asymptotic 50% size reduction and compares favorably against multiple compact Schnorr signatures.
1.4 Appendix A.4 NonSchnorr schemes
Some of the best applications of noninteractive 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 postquantum 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 noninteractive 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 multisig constructions for Lamportbased postquantum 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 pairingfriendly curves and hashing to point functions for which there are ongoing standardization efforts and limited HSM support. Also, the verification function of a roguekey 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.
Halfaggregation 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 nonstandard 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 nonmalleable discrete logarithm (NMDL) assumption, although the authors claim that it could easily be proven secure against the stronger explicit knowledgeofexponent 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 dropin 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 EUFCMA security of the signature scheme if \(\mathcal {A}\) runs in time at most t and wins the EUFCMA game with probability \(\epsilon \). A signature scheme is \((t, \epsilon )\)EUFCMAsecure if no forger \((t, \epsilon )\)breaks it.
Likewise, if the scheme is \((t, \epsilon )\)EUFCMAsecure, 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 )\)SBSsecure 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 ROmodel, 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 nonzero 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 Rcomponents (\(R_1, \ldots , R_n\)), but possibly different Scomponents \((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^{i1} = \sum _{i = 1}^n S'_i \cdot e'^{i1}\) 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 SBSforgery can be constructed: \((m_i, \textsf {pk}_i, m'_i, \textsf {pk}'_i, \sigma = (R_i, S_i))\). \(\square \)
Appendix F Parameter selection for almosthalfaggregation
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 tradeoff 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 onebyone, 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
We can estimate the aggregator’s time through \(r = n (2c  1)\) as \(O(n^3 \cdot (2c  1) \cdot 2^{\lambda /n/(2c1)})\). For a fixed compression rate c it achieves minimum at a batchsize 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 batchsize to tradeoff 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.
Appendix G Formal analysis for the impossibility of noninteractive compression by more than a half
This section expands on the impossibility of noninteractive 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
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}\)^{Footnote 5}. 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:
Assuming unforgeability of the aggregated signature scheme, \(\varepsilon \) must be negligible. \(\square \)
Rights and permissions
Copyright information
© 2021 Springer Nature Switzerland AG
About this paper
Cite this paper
Chalkias, K., Garillot, F., Kondi, Y., Nikolaenko, V. (2021). Noninteractive HalfAggregation of EdDSA and Variants of Schnorr Signatures. In: Paterson, K.G. (eds) Topics in Cryptology – CTRSA 2021. CTRSA 2021. Lecture Notes in Computer Science(), vol 12704. Springer, Cham. https://doi.org/10.1007/9783030755393_24
Download citation
DOI: https://doi.org/10.1007/9783030755393_24
Published:
Publisher Name: Springer, Cham
Print ISBN: 9783030755386
Online ISBN: 9783030755393
eBook Packages: Computer ScienceComputer Science (R0)