Pixel: Multi-signatures for Consensus

Manu Drijvers Sergey Gorbunov Gregory Neven DFINITY Algorand and University of Waterloo DFINITY Hoeteck Wee∗ Algorand and CNRS, ENS, PSL

Abstract to agree on changes to the ledger, while ensuring that changes In Proof-of-Stake (PoS) and permissioned , a com- once confirmed cannot be altered. mittee of verifiers agrees and sign every new block of trans- In the first generation of implementations, such actions. These blocks are validated, propagated, and stored as , , , the nodes with the largest by all users in the network. However, posterior corruptions computational resources choose the next block. These im- pose a common threat to these designs, because the adversary plementations suffer from many known inefficiencies, low can corrupt committee verifiers after they certified a block throughput, and high transaction latency [17, 27, 49]. To over- and use their signing keys to certify a different block. De- come these problems, the current generation of blockchain im- signing efficient and secure digital signatures for use in PoS plementations such as Algorand, Cardano, Ethereum Casper, blockchains can substantially reduce bandwidth, storage and and Dfinity turn to proofs of stake (PoS), where nodes with computing requirements from nodes, thereby enabling more larger stakes in the system —as measured, for instance, by the efficient applications. amount of money in their account— are more likely to partic- ipate in choosing the next block [21,24,29,32,34,39,47]. Per- We present Pixel, a pairing-based forward-secure multi- missioned blockchains such as Ripple [54] and signature scheme optimized for use in blockchains, that Fabric [4] take yet another approach, sacrificing openness achieves substantial savings in bandwidth, storage require- for efficiency by limiting participation in the network to a ments, and verification effort. Pixel signatures consist of two selected set of nodes. group elements, regardless of the number of signers, can be verified using three pairings and one exponentiation, and sup- All PoS-based blockchains, as well as permissioned ones, port non-interactive aggregation of individual signatures into have a common structure where the nodes run a consensus a multi-signature. Pixel signatures are also forward-secure sub-protocol to agree on the next block to be added to the and let signers evolve their keys over time, such that new keys ledger. Such a consensus protocol usually requires nodes cannot be used to sign on old blocks, protecting against pos- to inspect block proposals and express their agreement by terior corruptions attacks on blockchains. We show how to digitally signing acceptable proposals. When a node sees integrate Pixel into any PoS blockchain. Next, we evaluate sufficiently many signatures from other nodes on a particular Pixel in a real-world PoS blockchain implementation, show- block, it appends the block to its view of the ledger. ing that it yields notable savings in storage, bandwidth, and Because the consensus protocol often involves thousands block verification time. In particular, Pixel signatures reduce of nodes working together to reach consensus, efficiency of the size of blocks with 1500 transactions by 35% and reduce the signature scheme is of paramount importance. Moreover, block verification time by 38%. to enable outsiders to efficiently verify the validity of the chain, signatures should be compact to transmit and fast to verify. Multi-signatures [35] have been found particularly 1 Introduction useful for this task, as they enable many signers to create a compact and efficiently verifiable signature on a common Blockchain technologies are quickly gaining popularity for message [15, 40, 58, 59]. payments, financial applications, and other distributed appli- cations. A blockchain is an append-only public ledger that is The Problem of Posterior Corruptions. Chain integrity maintained and verified by distributed nodes. At the core of in a PoS blockchain relies on the assumption that the adver- the blockchain is a consensus mechanism that allows nodes sary controls less than a certain threshold (e.g., a third) of the ∗Authors are listed alphabetically. total stake; an adversary controlling more than that fraction may be able to the chain, i.e., present two different but N public keys into a single multi-signature of the same size equally valid versions of the ledger. Because the distribution as a single signature. of stake changes over time, however, the real assumption be- To validate Pixel’s design, we compared the performance hind chain integrity is not just that the adversary currently of a Rust implementation [1] of Pixel with previous forward- controls less than a threshold of the stake, but that he never secure tree-based solutions. We show how to integrate Pixel did so at any time in the past. into any PoS blockchain. Next, we evaluate Pixel on the Al- This assumption becomes particularly problematic if stake gorand blockchain, showing that it yields notable savings in control is demonstrated through possession of signature keys, storage, bandwidth, and block verification time. Our exper- as is the case in many PoS and permissioned blockchains. imental results show that Pixel is efficient as a stand-alone Indeed, one could expect current stakeholders to properly primitive and in use in blockchains. For instance, compared protect their stake-holding keys, but they may not continue to to a set of N = 1500 tree-based forward-secure signatures do so forever, especially after selling their stake. Nevertheless, (for T = 232) at 128-bit security level, a single Pixel signature without additional precautions, an adversary who obtains keys that can authenticate the entire set is 2667x smaller and can that represent a substantial fraction of stake at some point in be verified 40x faster (c.f. Tables 1 and 3). Pixel signatures the past can compromise the ledger at any point in the future. reduce the size of Algorand blocks with 1500 transactions The problem is further aggravated in efficient blockchains that by ≈ 35% and reduce block verification time by ≈ 38% (c.f. delegate signing rights to a small committee of stakeholders, Figures 3 and 4). because the adversary can gain control of the chain after corrupting a majority of the committee members. Referred to by different authors as long-range attacks [20], 1.2 Related Work costless simulation [52], and posterior corruptions [12], this Multi-signatures can be used to generate a single short sig- problem is best addressed through the use of forward-secure nature validates that a message m was signed by N different signatures [3,9,41,46]. Here, each signature is associated with parties [6,10,13,31,35,43,44,48,50], Multi-signatures based the current time period, and a user’s secret key can be updated on the BLS signature scheme [13, 15, 16, 53] are particularly in such a way that it can only be used to sign messages for well-suited to the distributed setting of PoS blockchains as future time periods, not previous ones. An adversary that cor- no communication is required between the signers; anybody rupts an honest node can therefore not use the compromised can aggregate individual signatures into a multi-signature. key material to create forks in the past of the chain. However, these signatures are not forward-secure. Tree-based forward-secure signatures [9, 36, 41, 46] can be 1.1 Our Results used to meet the security requirements, but they are not very efficient in an N-signer setting because all existing construc- We present the Pixel signature scheme, which is a pairing- tions have signature size at least O(N logT) group elements, based forward-secure multi-signature scheme for use in PoS- where T is an upper bound on the number of time periods. based blockchains that achieves substantial savings in band- Some schemes derived from hierarchical identity-based en- width and storage requirements. To support a total of T cryption (HIBE) [14, 18, 22] can bring that down to O(N) time periods and a committee of size N, the multi-signature group elements, which is still linear in the number of signers. comprises just two group elements and verification requires The only forward-secure multi-signature schemes that ap- only three pairings, one exponentiation, and N − 1 multipli- peared in the literature so far have public key length linear cations. Pixel signatures are almost as efficient as BLS multi- in the number of time periods T [45] or require interaction signatures, as depicted in Figure 1, but also satisfy forward- between the signers to produce a multi-signature [55], neither security; moreover, like in BLS multi-signatures, anybody of which is desirable in a blockchain scenario. The forward- can non-interactively aggregate individual signatures into a secure multi-signature scheme of Yu et al. [61] has signature multi-signature. length linear in the number of signers, so is not really a multi- Our construction builds on prior forward-secure signatures signature scheme. based on hierarchical identity-based encryption (HIBE) [14, Combining the generic tree-based forward-secure signature 18,22,26] and adds the ability to securely aggregate signatures scheme of Bellare-Miner [9] with BLS multi-signatures [13, on the same message as well as to generate public parameters 16] gives some savings, but still requires O(T) “certificates” without trusted set-up. to be included in each multi-signature. Batch verification [8] We achieve security in the random oracle model under a can be used to speed up verification of the certificates to some variant of the bilinear Diffie-Hellman inversion assumption extent, but does not give us any space savings. Compared with [11, 14]. At a very high level, the use of HIBE techniques existing tree-based forward-secure signatures in [9,36,41,46], allows us to compress O(logT) group elements in a tree- our savings are two-fold: based forward-secure signature into two group elements, and secure aggregation allows us to compress N signatures under • we reduce the size of the signature set for N commit- scheme key update sign verify |σ| |pk| |sk| forward security BLS multi-signatures [13, 15, 53] – 1 exp 2 pair 1 1 O(1) no Pixel multi-signatures (this work) 2 exp 4 exp 3 pair + 1 exp 2 1 O((logT)2) yes

Figure 1: Comparing our scheme with BLS signatures. Here, “exp” and “pair” refer to number of exponentiations and pairings respectively. T denotes the maximum number of time periods. We omit additive overheads of O(logT) multiplications. The column “key update” refers to amortized cost of updating the key for time t to t + 1. The columns |σ|, |pk|, and |sk| denote the sizes of signatures, public keys, and secret keys, respectively, in terms of group elements. Aggregate verification for N signatures requires an additional N − 1 multiplications over basic verification.

tee members from O(N logT) group elements1 to O(1) where the function F(t,M) can be computed with some public group elements; and parameters (two group elements in G1 in addition to h ∈ G1) r • we reduce the verification time from O(N) exponentia- and is fresh randomness used for signing. Verification relies tions to O(1) exponentiation and O(N) multiplications. on the relation: 0 00 e(σ ,g2) = e(h,y) · e(F(t,M),σ ) 1.3 Paper Organization and completeness follows directly: 0 x r The rest of this paper is organized as follows: e(σ ,g2) = e(h · F(t,M) ,g2) x r • In Section 2, we give a high level technical description = e(h ,g2) · e(F(t,M) ,g2) x r of our new pairing-based forward-secure multi-signature = e(h,g2) · e(F(t,M),g2) scheme. = e(h,y) · e(F(t,M),σ00) . • In Sections 4 and 5, we describe the scheme in details. Note that e(h,y) can be precomputed to save verification We prove the security of the construction in the random computation. oracle model under a variant of a bilinear Diffie-Hellman Given N signatures σ1,...,σN ∈ G1 × G2 on the same inversion problem. x1 xN message M at time t under N public keys g2 ,...,g2 , we • In Section 6, we explain how to apply Pixel to PoS can produce a multi-signature Σ on M by computing the blockchains to solve posterior corruptions. coordinate-wise product of σ1,...,σN. Concretely, if σi = (hxi · F(t,M)ri ,gri ), then • In Section 7, we evaluate the efficiency savings for stor- 2 0 0 age, bandwidth, and block verification time from using Σ = (hx1+···+xN · F(t,M)r ,gr ) Pixel on the Algorand PoS blockchain. 2 0 where r = r1 +···+rN. To verify Σ, we first compute a single aggregate public key that is a compressed version of all N 2 Technical Overview individual public keys

Our construction builds on prior forward-secure signatures apk ← y1 · ... · yN , based on hierarchical identity-based encryption (HIBE) [14, apk 18,22,26] and adds the ability to securely aggregate signatures and verify Σ against using the standard verification equa- on the same message as well as to generate public parameters tion. without trusted set-up. How to generate and update keys. To complete this overview, we describe a simplified version of the secret keys Overview of our scheme. Starting with a bilinear group and update mechanism, where the secret keys are of size O(T) (G1,G2,Gt) with e : G1 × G2 → Gt of prime order q and instead of O((logT)2). The construction exploits the fact that generators g1,g2 for G1,G2 respectively, a signature on M ∈ F x the function satisfies Zq at time t under public key g2 is of the form: F(t,M) = F(t,0) · F0M 0 00 x r r σ = (σ ,σ ) = (h · F(t,M) ,g2) ∈ G1 × G2 for some constant F0. This means that in order to sign mes- 1 Each tree-based signature comprise O(logT) group elements corre- sages at time t, it suffices to know sponding to a path in a tree of depth logT (see Section 7 for details), and x r 0r r there are N such signatures, one for which committee member. ske t = {h · F(t,0) ,F ,g2} x r r from which we can compute (h · F(t,M) ,g2). (ii) a long-range variant as explained earlier. Dfinity [34], The secret key skt for time t is given by: Ouroboros [39] and Casper [21] cope with the short-range attacks by assuming a delay in attacks that is longer than the ske t ,ske t+1,··· ,ske T running time of the consensus sub-protocol. For long-range attacks, Casper adopts a fork choice rule to never revert a final- generated using independent randomness. To update from ized block, and in addition, assumes that clients log on with the key skt to skt+1, we simply erase ske t . Forward security sufficient regularity to gain a complete update-to-date view of follows from the fact that an adversary who corrupts a signer the chain. We note that forward-secure signatures provide a at time t only learns skt and, in particular, does not learn ske t0 0 clean solution against both attacks, without the need for fork for t < t, and is unable to create signatures for past time slots. choice rules or additional assumptions about the adversary 2 To compress the secret keys down to O((logT) ) without and the clients. increasing the signature size, we combine the tree-based ap- proach in [22] with the compact HIBE in [14]. Roughly speak- ing, each skt now contains logT sub-keys, each of which con- Application to permissioned blockchains. Consensus tains O(logT) group elements and looks like an “expanded” protocols, such as PBFT, are also at the core of many per- version of ske t . (In the simplified scheme, each skt contains missioned blockchains (e.g. Hyperledger), where only ap- T −t + 1 sub-keys, each of which contains three group ele- proved parties may join the network. Our signature scheme ments.) can similarly be applied to this setting to achieve forward secrecy, reduce communication bandwidth, and produce com- Security against rogue-key attacks. The design of multi- pact block certificates. signature schemes must take into account rogue-key attacks, where an adversary forges a multi-signature by providing 3 Preliminaries specially crafted public keys that are correlated with the public keys of the honest parties. We achieve security against rogue- Let , , be multiplicative groups of prime order q with key attacks by having users provide a proof of possession G1 G2 Gt a non-degenerate pairing function e : × → . Let g of their secret key [13, 53]; it suffices here for each user to G1 G2 Gt 1 and g be generators of and , respectively. provide a standard BLS signature y0 on its public key y (cf. 2 G1 G2 In analogy with the weak bilinear Diffie-Hellman inver- the proof π in the key generation and verification algorithms sion problem `-wBDHI∗ [14], which was originally defined in Section 5.2). for Type-1 pairings (i.e., symmetric pairings where we have G1 = G2), we define the following variant for Type-3 pairings Avoiding trusted set-up. Note that the common parame- ∗ denoted `-wBDHI3. ters contain uniformly random group elements h,h0,...,hlogT in G2 which are used to define the function F. These elements (α2) (α`) A = gα , A = g ,..., A = g , can be generated using a indifferentiable hash-to-curve algo- Input: 1 1 2 1 ` 1 ` rithm [19,60] evaluated on some fixed sequence of inputs (e.g. α (α2) (α ) B1 = g2 , B2 = g2 ,..., B` = g2 , determined by the digits of pi), thereby avoiding any trusted γ γ set-up. C1 = g1 , C2 = g2 $ for α,γ ← Zq (γ·α`+1) 2.1 Discussion Compute: e(g1,g2)

Related works. The use of HIBE schemes for forward se- `-wBDHI∗ The advantage Adv 3 (A) of an adversary A is defined crecy originates in the context of encryption [22] and has G1×G2 been used in signatures [18,26], key exchange [33] and proxy as its probability in solving this problem. re-encryption [30]. Our signature scheme is quite similar As shown in [14], the assumption holds in the generic bi- p to the forward-secure signatures of Boyen et al. [18] and linear group model, with a lower bound of Ω( q/`) (with achieves the same asymptotic complexity; their construction a matching attack in [25]). Concretely, for the BLS12-381 is more complex in order to achieve security against untrusted pairing-friendly curve with ` = 32, the best attack has com- updates. The way we achieve aggregation is similar to the plexity roughly 2125. multi-signatures in [43]. Alternatively, our scheme could be proved secure under a variant of the above assumption where the adversary has to (α`+1) Alternative approaches to posterior security. There are output g1 given as input A1,...,A`,B1,...,B` and given x x two variants of the posterior attack: (i) a short-range vari- access to an oracle ψ : g2 7→ g1. Because of the ψ oracle, ant, where an adversary tries to corrupt a committee mem- this assumption is incomparable to the `-wBDHI assumption ber prior to completion of the consensus sub-protocol, and described above. 4 Forward-Secure Signatures Security.

We begin by describing a forward-secure signature scheme, Unforgeability under chosen-message attack for forward- and then extend the construction to a multi-signature scheme secure signatures is defined through the following game. The in Section 5. experiment generates a fresh key pair (pk,sk1) and hands the public key pk to the adversary A. The adversary is given 4.1 Definition access to the following oracles: We use the Bellare-Miner model [9] to define syntax and Key update. If the current time period t (initially set to t = 1) security of a forward-secure signature scheme. A forward- is less than T, then this oracle updates the key skt to skt+1 secure signature scheme FS for a message space M consists and increases t. of the following algorithms: Signing. On input a message M, this oracle runs the signing $ Setup: pp ← Setup(T). All parties agree on the public pa- oracle with the current secret key skt and message M, and rameters pp. The setup algorithm mainly fixes the distribu- returns the resulting signature σ. tion of the parameters given the maximum number of time periods T. The parameters may be generated by a trusted Break in. The experiment records the break-in time t¯ ← t third party, through a distributed protocol, or set to “nothing- and hands the current signing key skt¯ to the adversary. This up-my-sleeve” numbers. The public parameters are taken to oracle can only be queried once, and after it has been queried, be an implicit input to all of the following algorithms. the adversary can make no further queries to the key update

$ or signing oracles. Key generation: (pk,sk1) ← Kg. The signer runs the key generation algorithm on input the maximum number of time At the end of the game, the adversary outputs its forgery periods T to generate a public verification key pk and an (t∗,M∗,σ∗). It wins the game if σ∗ verifies correctly under initial secret signing key sk for the first time period. 1 pk for time period t∗ and message M∗, if it never queried the $ ∗ ∗ Key update: skt+1 ← Upd(skt ). The signer updates its secret signing oracle on M during time period t , and if it queried ¯ ∗ key skt for time period t to skt+1 for the next period using the break-in oracle, then it did so in a time period t > t . fu-cma the key update algorithm. The scheme could also offer a We define A’s advantage AdvFS (A) as its probability in $ 0 0 “fast-forward” update algorithm skt0 ← Upd (skt ,t ) for any winning the above game. t0 > t that is more efficient than repetitively applying Upd. We also define a selective variant of the above notion, re- ferred to as sfu-cma, where the adversary first has to commit $ Signing: σ ← Sign(skt ,M). On input the current signing key to t¯, t∗, and M∗. More specifically, A first outputs (t¯,t∗,M∗), skt and message M ∈ M, the signer uses this algorithm to then receives the public key pk, is allowed to make signature compute a signature σ. and key update queries until time period t = t¯ is reached, at ∗ Verification. b ← Vf(pk,t,M,σ). Anyone can verify a sig- which point it is given skt¯ and outputs its forgery σ . nature σ for on message M for time period t under public key pk by running the verification algorithm, which returns 1 4.2 Encoding time periods to indicate that the signature is valid and 0 otherwise. Following [22], we associate time periods with all nodes of Correctness. the tree according to a pre-order traversal. Prior tree-based forward-secure signatures [9, 46] associate time periods with M ∈ M Correctness requires that for all messages and for all the only leaf nodes; using all nodes allows us to reduce the t ∈ [T] time periods it holds that amortized complexity of key updates from O(logT) exponen- tiations to O(1) exponentiations. Pr[Vf(pk,t,M,Sign(skt ,M)) = 1] = 1 Recall that a tree of depth ` − 1 has 2` − 1 nodes, which $ $ ` where the coin tosses are over pp ← Setup(T), (pk,sk1) ← then correspond to time periods in [2 − 1]. We will identify ≤`−1 Kg, and ski ← Upd(ski−1) for i = 2,...,t. the nodes of the tree of depth ` − 1 with strings in {1,2} Moreover, if the scheme has a fast-forward update algo- where 1 denotes taking the left branch and 2 denotes taking rithm, then the keys it produces must be distributed identically the right branch. We work with {1,2} instead of {0,1} for to those produced by repetitive application of the regular up- technical reasons: roughly speaking, in the scheme, we need date algorithm. Meaning, for all t,t0 ∈ [T] with t < t0 ≤ T to work with strings of length exactly ` − 1, which we obtain 0 $ 0 0 ≤`−1 and for all skt it holds that skt0 ← Upd (skt ,t ) follows the by padding strings in {1,2} with zeroes. $ same distribution as skt produced as ski ← Upd(ski−1) for We can also describe the association explicitly as a bijec- 0 ≤`−1 ` i = t + 1,...,t . tion between t = t1kt2k... ∈ {1,2} and t ∈ [2 − 1] for any integer ` given by to bit strings of length κ such that 2κ < q. Apart from the description of the groups, the common system parameters |t| ` `−i also contain the maximum number of time slots T = 2 − 1 t(t) = 1 + (1 + 2 (ti − 1)) . $ ∑ and random group elements h,h0,...,h` ← 1. These pa- i=1 G rameters could, for example, be generated as the output of a For instance, for ` = 3, this maps ε,1,11,12,2,21,22 to hash function modeled as a random oracle.

1,2,3,4,5,6,7. The inverse of the bijection can be described $ Key generation. Each signer chooses x ← Zq and computes as x y ← g2. It sets its public to pk = y and computes its initial r x r r r t(1) = ε secret key sk1 ← {ske ε} where ske ε = g2 , h h0 , h1,...,h` $ t(t) = t(t − 1)k1 if |t(t − 1)| < ` − 1 for r ← Zq. t(t) = t¯k2 if |t(t − 1)| = ` − 1 Key update. We associate with each w ∈ {1,2}k with k ≤ ` − 1 a key ske w of the form where t¯ is the longest string such that t¯k1 is a prefix of t(t −1). The bijection induces a natural precedence relation over ske w = (c,d,ek+1,...,e`) ≤`−1 0 0 ¯ k {1,2} where t  t iff either t is a prefix of t or exists t  w  0 r x j r r r s.t. t¯k1 is a prefix of t and t¯k2 is a prefix of t . We also write = g2 , h (h0 ∏ h j ) , hk+1 ,..., h` (1) t,t + 1 corresponding to t,t + 1. j=1 ≤`−1 Next, we associate any t ∈ {1,2} with a set Γt ⊂ $ 0 ≤`−1 for r ← Zq. Given ske w, one can derive a key for any w ∈ {1,2} given by 0 {1,2}k which contains w as a prefix as   Γt := t ∪ t¯k2 : t¯k1 prefix of t  k0 k0 0 0 0 0 r0 w j w j r0 (c ,d ,e 0 ,...,e ) = c·g , d · e ·(h h ) , that corresponds to the set containing t and all the right-hand k +1 ` 2 ∏ j 0 ∏ j j=k+1 j=1 siblings of nodes on the path from t to the root, which also  happens to be the smallest set of nodes that includes a prefix r0 r0 ek0+1 · hk0+1 ,..., e` · h` (2) of all t0  t. For instance, for ` = 3, we have

0 $ for r ← Zq. Γ1 = {1,2},Γ11 = {11,12,2},Γ12 = {12,2} . The secret key skt at time period t is given by The sets Γt satisfy the following properties: skt = {ske w : w ∈ Γt} , 0 0 • t  t iff there exists u ∈ Γt s.t. u is a prefix of t ; which, by the first property of Γt, contains a key ske w for a • For all t, we have Γ = Γ \{t} if |t| = `−1 or Γ = t+1 t t+1 prefix w of all nodes t0  t. (Γt \{t}) ∪ {tk1,tk2} otherwise; 0 0 To perform a regular update of skt to skt+1, the signer users • For all t t, we have that for all u ∈ Γt0 , there exists 0 the second property of Γt. Namely, if |t| < ` − 1, then the u ∈ Γt such that u is a prefix of u . signer looks up ske t = (c,d,e|t|+1,...,e`) ∈ skt, computes The first property is used for verification and for reasoning about security; the second and third properties are used for ske tk1 ← (c,d · e|t|+1,e|t|+2,...,e`) , key updates. and derives ske tk2 from ske t using Equation (2). The signer then sets skt+1 ← (skt \ ske t) ∪ {ske tk1,ske tk2} and securely 4.3 Construction 0 deletes skt as well as the re-randomization exponent r used ` We assume the bound T is of the form 2 − 1. We use in the derivation of ske tk2. the above bijection so that the algorithms take input t ∈ If |t| = ` − 1, then the signer simply sets skt+1 ← skt \{ske t} {1,2}≤`−1 instead of t ∈ [T]. The following scheme is roughly and securely deletes sk . the result of applying the Canetti-Halevi-Katz technique to t 0 obtain forward security from hierarchical identity-based en- To perform a fast-forward update of its key to any time t  t, 0 cryption (HIBE) [23] to the signature scheme determined by the signer derives keys ske w0 for all nodes w ∈ Γt0 \ Γt by the key structure of the Boneh-Boyen-Goh HIBE scheme [14]; applying Equation (2) to the key ske w ∈ skt such that w is a 0 we describe the differences at the end of this subsection. prefix of w , which must exist due to the third property of 0 Γt. The signer then sets skt0 ← {ske w0 : w ∈ Γt0 } and securely Setup. Let M be the message space of the scheme and let deletes skt as well as all re-randomization exponents used in κ Hq : M → {0,1} be a hash function that maps messages the key derivations. Signing. To generate a signature on message M ∈ M In a regular update, assume that skt is well-formed. If ≤`−1 in time period t ∈ {1,2} , the signer looks up ske t = |t| = `−1, then the update procedure sets skt+1 ← skt \{ske t}, 0 $ (c,d,e|t|+1,...,e`) ∈ skt , chooses r ← Zq, and outputs which by the second property of Γt and the induction hy- pothesis means that skt+1 is also well-formed. If |t| < ` − 1, |t|  0  the update procedure adds keys sk and sk and re- Hq(M) t j Hq(M)r r0 e tk1 e tk2 (σ1,σ2) = d · e` · h0 · ∏ h j · h` , c · g2 . j=1 moves ske t from skt, which by the second property of Γt indeed corresponds to {w : w ∈ Γt+1}. Moreover, ske tk1 is derived from sk = sk ← (c,d,e ,...,e ) as sk ← Verification. Anyone can verify a signature (σ1,σ2) ∈ G1 × e t e tk1 |t|+1 ` e tk1 (c,d · e ,e ,...,e ), which satisfies Equation (1) with G2 on message M under public key pk = y in time period t |t|+1 |t|+2 ` by checking whether randomness r that is independent from all other keys in skt+1 because ske t 6∈ skt+1. Similarly, ske tk2 satisfies Equation (1) |t| because it is generated as t j Hq(M)  e(σ1,g2) = e(h,y) · e h0 · ∏ h j · h` , σ2 . j=1

Note that the pairing e(h,y) can be pre-computed from the public key ahead of time, so that verification only requires 0 0 c0 = c · gr = gr+r two pairing computations. 2 2 k 0 t j wk+1 r0 d = d · ek+1 · (h0 ∏ h j · hk+1 ) Differences from prior works. We highlight the differ- j=1 ences between our scheme and those in [14,18,22], assuming k x t j 2 r+r0 some familiarity with these prior constructions. = h (h0 ∏ h j · hk+1) j=1 • We rely on asymmetric bilinear groups for efficiency, and 0 r0 r+r0 2 ek+2 = ek+2 · hk+2 = hk+2 our signature sits in G2 × G1 instead of G2. This way, it is sufficient to give out the public parameters h ,...,h in . 0 ` . G1 (which we can then instantiate using hash-to-curve 0 r0 r+r0 without trusted set-up) instead of having to generate e` = e` · h` = h` 0 xi xi “consistent” public parameters (hi,hi) = (g1 ,g2 ) ∈ G1 × G2. • Our key-generation algorithm also deviates from that in the Boneh-Boyen-Goh HIBE, which would set satisfying Equation (1) with randomness r + r0, which is inde- x r x r r r pendent of the randomness of other keys in skt+1 due to the pk = e(g1,g2) ,h = g1,ske ε = g2,g1h0,h1,...,h` . uniform choice of r0. x In our scheme, pk = g2 lies in G2 instead of Gt and is therefore smaller. Setting h to be random instead of g 1 For the fast-forward update procedure, one can see that if also allows us to achieve security under weaker assump- 0 x skt is well-formed, then the updated key skt0 for t t is well- tions. In fact, setting h = g1 and pk = g would yield 2 formed as well. Indeed, by adding the keys for nodes in Γ 0 \Γ an insecure scheme in symmetric pairing groups where t t x x x and removing those for Γt \Γt0 , we have that skt0 contains keys g1 = g2, since h = g1 = g2 = pk. ske w for all w ∈ Γt0 . The randomness independence is guar- anteed by the random choice of r0 in Equation (2). In the 4.4 Correctness optimized variant, all keys still have independent randomness because one key ske w0 ∈ skt0 will have the same randomness We say that a secret key skt for time period t is well-formed 0 r as some key ske w ∈ skt where w is a prefix of w . That ran- if skt = {ske w : w ∈ Γt}, where each ske w is of the form of domness is independent from all other keys in sk 0 , however, Equation (1) for an independent uniformly distributed expo- t 0 $ because the key ske w does not occur in skt . Indeed, by the nent r ← q. We first show that all honestly generated and Z definition of Γ 0 , one can see that Γ 0 cannot have elements updated secret keys are well-formed, and then proceed to the t t w 6= w0 with w a prefix of w0. verification of signatures. The key skt is trivially well-formed for t = 1, i.e., t = ε, as can be seen from the key generation algorithm. We now show To see why signature verification works, observe that a that skt is also well-formed after a regular update from time t signature for time period t and message M is computed from 0 to t + 1 and after a fast-forward update from t to t t. a key ske t = (c,d,e|t|+1,...,e`) in a well-formed key skt. The left-hand side of the verification equation is therefore and additionally has the following algorithms:

 |t| 0  Key verification: b ← KVf(pk,π). The key verification al- Hq(M) t j Hq(M)r e(σ1,g2) = e d · e` · h0 · ∏ h j · h` , g2 gorithm returns 1 if the proof pk is valid for pk and returns 0 j=1 otherwise.  |t| 0  x t j Hq(M)r+r Key aggregation: apk ←$ KAgg(pk ,...,pk ). On input a = e h h0 · ∏ h j · h` , g2 1 n j=1 list of individual public keys (pk1,...,pkn), the key aggre-  |t| r+r0 gation returns an aggregate public key apk, or ⊥ to indicate x t j Hq(M) = e(h ,g2) · e h0 · ∏ h j · h` , g2 that key aggregation failed. j=1 Signature aggregation. Σ ←$ SAgg((pk ,σ ),...,  |t|  1 1 t H (M) j q (pkn,σn),t,M). Anyone can aggregate a given list of = e(h,y) · e h0 · ∏ h j · h` , σ2 . j=1 individual signatures (σ1,...,σn) by different signers with public keys (pk1,...,pkn) on the same message M and for 4.5 Security the same period t into a single multi-signature Σ. Theorem 1. For any fu-cma adversary A against the above Aggregate verification. b ← AVf(apk,t,M,Σ). Given an ag- forward-secure signature scheme in the random-oracle model gregate public key apk, a message M, a time period t, and for T = 2` − 1 time periods, there exists an adversary B with a multi-signature Σ, the verification algorithm returns 1 to essentially the same running time and advantage in solving indicate that all signers in apk signed M in period t, or 0 to ∗ indicate that verification failed. the `-wBDHI3 problem 2 `-wBDHI∗ 1 q Adv 3 (B) ≥ · Advfu-cma(A) − H , Correctness. Correctness requires that KVf(pk,π) = 1 G1×G2 FS κ $ T · qH 2 with probability one if (pk,π,sk1) ← Kg and that for all mes- sages M ∈ M, for all n ∈ , and for all time periods t ∈ where qH is the number of random-oracle queries made by Z A. {0,...,T −1}, it holds that AVf(apk,t,M,Σ) = 1 with proba- $ $ bility one if (pki,πi,ski,1) ← Kg, apk ← KAgg(pk1,...,pkn), $ $ We refer the interested reader to Appendix A for the full ski, j ← Upd(ski, j−1) for i = 1,...,n and j = 2,...,t, σi ← $ proof of security. Sign(ski,t ,M) for i = 1,...,n, and Σ ← SAgg((pk1,σ1),..., (pkn,σn),t,M). 5 Forward-Secure Multi-Signatures Security. Unforgeability (fu-cma) is defined through a To obtain a multi-signature scheme, we observe that the game that is similar to that described in Section 4.1. The n n component-wise product (Σ1,Σ2) = (∏i=1 σi,1,∏i=1 σi,2) of adversary is given the public key pk and proof π of an hon- a number of signatures (σ1,1,σ1,2),...,(σn,1,σn,2) satisfies est signer and access to the same key update, signing, and the verification equation with respect of the product of public break-in oracles. However, at the end of the game, the ad- keys Y = y1 · ... · yn. This method of combining signatures is versary’s forgery consists of a list of public keys and proofs ∗ ∗ ∗ ∗ ∗ ∗ vulnerable to a rogue-key attack, however, where a malicious (pk1,π1,...,pkn,πn), a message M , a time period t , and a signer chooses his public key based on that of an honest signer, multi-signature Σ∗. The forgery is considered valid if so that the malicious signer can compute valid signatures for pk ∈ {pk∗,...,pk∗} their aggregated public key. The scheme below borrows a • 1 n , ∗ ∗ technique due to Ristenpart and Yilek [53] using proofs of • the proofs π1,...,πn are valid for public keys ∗ ∗ possession (denote by π below) to prevent against these types pk1,...,pkn according to KVf, of attack. • Σ∗ is valid with respect to the aggregate public key apk∗ ∗ ∗ ∗ ∗ of (pk1,...,pkn), message M , and time period t , 5.1 Definitions • t¯ > t∗, In addition to the algorithms of a forward-secure signa- • and A never made a signing query for M∗ during time ture scheme in Section 4.1, a forward-secure multi-signature period t∗. scheme FMS in the key verification model has a key gener- Our security model covers rogue-key attacks because the ation that additionally outputs a proof π for the public key: adversary first receives the target public key pk, and only $ ∗ ∗ Key generation: (pk,π,sk1) ← Kg. The key generation al- then outputs the list of public keys pk1,...,pkn involved in its gorithm generates a public verification key pk, a proof π, and forgery. The only condition on these public keys is that they ∗ ∗ an initial secret signing key sk1 for the first time period. are accompanied by valid proofs π1,...,πn. 5.2 Construction 6 Pixel in PoS-based Blockchains H { , }∗ → ∗ Let G1 : 0 1 G1 be a hash function. The multi- In this section, we describe how to integrate Pixel into PoS- signature scheme reuses the key update and signature algo- based blockchains that rely on forward-secure signatures to rithms from the scheme from Section 4.3, but uses different achieve security against posterior corruptions. We summarize key generation and verification algorithms, and adds signature systems that rely on forward-secure signatures, abstract how and key aggregation. signatures are used in these systems, and explain how to apply $ Pixel. Key generation. Each signer chooses x ← Zq and computes x 0 PoP PoP y ← g2 and y ← HG1 ( ,y), where is a fixed string used as a prefix for domain separation. It sets its public key PoS Blockchains Secure under Posterior Corruptions. to pk = y, the proof to π = y0, and computes its initial secret Ouroboros Genesis and Praos rely on forward-secure signa- x key as sk1 ← h . tures to protect against posterior corruptions [5,29,38]. These blockchains require users to rotate key and assume secure era- Key verification. Given a public key pk = y with proof sures. Thuderella is a blockchain with fast optimistic instant = y0, the key verification algorithm validates the proof π confirmation [51]. The blockchain is secure against poste- of possession by returning 1 if rior corruptions assuming that a majority of the computing 0 PoP power is controlled by honest players. Similarly, the protocol e(y ,g2) = e(HG1 ( ,y),y) relies on forward-secure signatures. Pixel can be applied in and returning 0 otherwise. all these blockchains to protect against posterior attacks and

Key aggregation. Given public keys pk1 = y1,..., potentially reduce bandwidth, storage, and computation costs pkn = yn, the key aggregation algorithm computes in instances where many users propagate many signatures on n the same message (e.g., a block of transactions). Ouroboros Y ← ∏i=1 yi and returns the aggregate public key apk = Y. Crypsinous uses forward-secure encryption to protect against Signature aggregation. Given signatures σ1 = the same attack [37]. Snow White shows that under a mild (σ1,1,σ1,2),...,σn = (σn,1,σn,2) ∈ G1 × G2 on the setup assumption, when nodes join the system they can access same message M, the signature aggregation algorithm a set of online nodes the majority of whom are honest, the outputs system can defend against posterior corruption attack [28]. n n  The system does not rely on forward-secure signatures. Σ = (Σ1,Σ2) = ∏σi,1 , ∏σi,2 . i=1 i=1 Background on PoS Blockchains. A blockchain is an Aggregate verification. Multi-signatures are verified with append-only public ledger to which anyone can write and respect to aggregate public keys in exactly the same way read. The fundamental problem in blockchains is to agree on as individual signatures with respect to individual public a block of transactions between users. In Proof-of-Stake pro- keys. Namely, given a multi-signature (Σ1,Σ2) ∈ G1 × G2 tocols, users map the stake or tokens they own in the system on message M under aggregate public key apk = Y in time to “voting power” in the agreement protocol. Various types period t, the verifier accepts if and only if apk 6= ⊥ and of PoS systems exist that use different formulas for determin- |t| ing the weight of each vote. For instance, in bounded PoS t j Hq(M)  protocols, users must explicitly lock some amount A of their e(Σ1,g2) = e(h,Y) · e h0 · ∏ h j · h`+1 , Σ2 . j=1 tokens to participate in the agreement. The weight of each vote is A/Q, where Q is the total number of locked tokens 5.3 Security who’s users wish to participate in the agreement. Users that misbehave are punished by a penalty applied to their locked Theorem 2. For any fu-cma adversary A against the above tokens. ` forward-secure multi-signature scheme for T = 2 − 1 time To tolerate malicious users, all PoS protocols run a Byzan- periods in the random-oracle model, there exists an adver- tine sub-protocol to agree on a block of transactions. The sary B with essentially the same running time that solves the system is secure, assuming that that majority (often 2/3) of ∗ `-wBDHI3 problem with advantage the tokens participating in the consensus is honest. Each block 2 is valid if a majority of committee members, weighted by their `-wBDHI∗ 1 q 3 (B) ≥ · fu-cma(A) − H , Adv × AdvFMS κ stake, approved it. G1 G2 T · qH 2 where q is the number of random-oracle queries made by H Pixel Integration. In order to vote on a block B, each mem- A. ber of the sub-protocol signs B using Pixel with the current We defer the interested reader to Appendix B for proof block number. The consensus is reached when we see a col- details. lection of N committee member signatures σ1,...,σN on the same block B, where N is some fixed threshold. Finally, we as soon as it signs a block, updates its key to skt+1 and then will aggregate these N signatures into a single multi-signature propagates the signature. In particular, there is no need for key Σ, and the pair (B,Σ) constitute a so-called block certificate updates when a user is not selected to be on the committee. and the block B is appended to the blockchain. 7 Evaluation on Algorand Blockchain Registering public keys. Each user who wishes to partic- ipate in consensus needs to register a participation signing In order to measure the concrete efficiency gains of Pixel, we key. A user first samples a Pixel key pair and generates a evaluate it on the Algorand blockchain [56, 57]. corresponding PoP. The user then issues a special transaction (signed under her spending key) registering the new participa- Algorand Overview. Algorand is a Pure PoS (PPOS) sys- tion key. The transaction includes PoP. PoS verifiers who are tem, where each token is mapped to a single vote in the con- selected to run an agreement at round r, check (a) validity of sensus without any explicit bonding [56,57]. Some users may the special transaction, and (b) validity of PoP. If both checks opt-out from participation, in which case their tokens are ex- pass, the user’s account is updated with the new participation cluded from the total number of participating tokens (i.e., the key. From this point, if selected, the user signs on blocks using denominator in the weight). Each user maintains an account Pixel. state on-chain that specifies her spending key, balance, consen- sus participation status, participation key, and other auxiliary Vote generation. To generate a vote on a block number t, information. A user wishing to perform a transaction must users first update their keys to correspond to the round number. sign it with her corresponding secret key. Users run a Byzan- Subsequently, they sign the block using the correct secret key tine consensus algorithm to agree on a block of transactions and propagate the signature to the network. following the high-level structure we outlined in the previous section. We call a block certificate to denote a collection of Propagating and aggregating signatures. Individual votes above a certain threshold approving a block. All users committee signatures will be propagated through the network in the network validate and store block certificate (and the until we see N committee member signatures on the same corresponding transactions) on disk. We refer to a node as block B. Note that Pixel supports non-interactive and incre- a computer system running Algorand client software on the mental aggregation: the former means that signatures can user’s behalf. be aggregated by any party after broadcast without commu- nicating with the original signers, and the latter means that Verifier Vote Structure and Block Certificates. In Algo- we can add a new signature to a multi-signature to obtain a rand, each valid vote for a block proposal includes (a) a proof new multi-signature. In practice, this means that propagating that the verifier was indeed selected to participate in the con- nodes can perform intermediate aggregation on any number sensus at round r, and (b) a signature on the block proposal. of committee signatures and propagate the result, until the In more detail, each vote includes the following fields: block certificate is formed. Alternatively, nodes can aggregate all signatures just before writing a block to the disk. That is, • Sender identifier which is represented by a unique public upon receiving enough certifying votes for a block, a node key registered on-chain (32 bytes). can aggregate N committee members’ signatures into a multi- • Round and sub-step identifiers (8 bytes). signature and then write the block and the certificate to the • Block header proposal (32 bytes). disk. To speed up verification of individual committee mem- ber signatures, a node could pre-compute e(h,y) for the y’s • A seed used as an input to a VRF function for crypto- corresponding to the users with the highest stakes. graphic sortition (32 bytes). • VRF credential that proves that the sender was indeed Key updates. When using Pixel in block-chains, time cor- chosen to sign on the block (96 bytes). responds to the block number or sub-steps in consensus pro- • Forward-secure signature authenticating the vote (256 tocols. Naively, when associating time with block numbers, bytes). this means that all eligible committee members should update their Pixel secret keys for each time a new block is formed Overall, each vote is about 500 bytes (including some addi- and the round number is updated. Assume for simplicity that tional auxiliary information), half of which is for the forward- each committee member signs at most one block (if not, sim- secure signature. ply append a counter to the block number and use that as the Algorand has two voting sub-steps for each round. In the time). If a user is selected to be on the committee at block first sub-step, a supporting set (of expected size 3000) of number t, it should first update its key to skt (Pixel supports verifiers is chosen to vote on a block proposal. In the second 0 “fast-forward” key updates from skt to skt0 for any t > t), and sub-step, a certifying set (of expected size 1500) of verifiers keygen key sign aggregate verify agg. aggregate verify agg. |pk| |σ| |skt | update (N = 1500) (N = 1500) (N = 1500) (N = 3000) pk ∈ G1 1.03 ms 1.8 ms 2.8 ms 7.2 ms 6.7 ms 13.9 ms 8.3 ms 48 B 144 B 43 kB Figure 2: Performance figures of the Pixel signature scheme algorithms, and the size of public keys, signatures, and secret keys when using a BLS12-381 curve. N denotes the amount of signatures and keys aggregated, respectively. Maximum number of time periods is T = 232 − 1. is chosen to finalize the block proposal. All verifiers’ votes Sig. set size BM-Ed25519 BM-BLS Pixel propagate in the network during the agreement, but only the 1 256 B 192 Bytes 144 B certifying votes are stored long-term and sufficient to validate 1500 375 KB 141 KB 144 B a block in the future. Larger recovering set (of expected size 3000 750 KB 281 KB 144 B 10000) is chosen during a network partition for recovery. 10000 2.4 MB 938 KB 144 B

Table 1: Total size of signature sets using various forward- Algorand’s Existing Solution to Posterior Corruptions. secure signature schemes for 232 time periods. BM-Ed25519 Algorand solves posterior corruptions using forward-secure is instantiated using Algorand’s parameters with 10,000-ary signatures instantiated with a d-ary certificate tree [9], which tree of depth 2. BM-BLS is instantiated using the same pa- we call BM-Ed25519 for convenience. The root public key of rameters with public keys in G1 and signatures in G2. an Ed25519 signature scheme is registered on-chain, and keys associated with the leaves (and subsequently used to sign at each round) are stored locally by the potential verifiers. For verification time. In Pixel, the signature set corresponds to a each block at round r a verifier must (a) produce a valid certifi- single multi-signature. cate chain from the root public key to the leaf associated with r, and (b) signature of the vote under the leaf key. Algorand assumes secure erasures and that users delete old keys from their nodes. BM-Ed25519 is instantiated with 10000-ary tree Storage Savings. In Table 1, we compare the sizes of sig- . and depth 2 (supporting approximately 226 6 time periods). nature sets that are propagated (for supporting and verifying Ed25519-based signatures have public keys of 32 bytes and votes) and stored (for verifying votes) by all participating 64 bytes signatures. Hence, since a valid certificate chain nodes. We instantiate BM-Ed25519 with Algorand param- must include the intermediary public keys, the resulting size eters of 10000-ary and depth 2. For BM-BLS we place the × + × = of each forward-secure signature is 3 64 2 32 256 public key in G1 and signatures in G2. Since BLS supports bytes. aggregation of signatures, we can compress all signatures in a certificate chain and the signature of the block into 96 B (note that the public key in the certificate chain cannot 7.1 Efficiency Evaluation be compressed and adds an additional 96 B per signature). Pixel signatures can serve as a replacement of BM-Ed25519 Furthermore, we can compress all signatures across votes. in Algorand following the same design as outlined Section 6. Pixel signatures authenticating a block with 1500 signatures are 2667x and 1003x times smaller than signature sets using BM-Ed25519 and BM-BLS, respectively. Setup. Our experiments are performed on a MacBook Pro, In Figure 3, we show long-term blockchain storage im- 3.5 GHz Intel Core i7 with 16 GB DDR3. We use Alogrand’s provements using Pixel signatures. We evaluate storage as- open-source implentations of Pixel signatures, VRF functions, suming various number of transactions in each block. Each Ed25519 signing, and verification [1,2]. For blockchain ap- transaction in Algorand is about 232 bytes. We also assume plications, since the public key must live on-chain, we choose that the entire expected number of certifying verifiers (1500) to place Pixel public keys in G1, obtaining smaller public are selected for each block. Given today’s block confirmation keys and faster key aggregation during verification. We set time of just under 4.3 seconds per block, Algorand blockchain the maximum time epoch to T = 232 − 1, which is sufficient should produce 106 blocks every ≈ 50 days and 108 blocks to rotate a key every second for 136 years. every ≈ 13 years. Pixel signatures improve blockchain size Figure 2 shows the runtime of individual Pixel algorithms, by about 40% and 20% on blocks packed with 1500 and aggregation, and object sizes for the BLS12-381 curve [7]. 5000 transactions, respectively. This improvement translates Next, we measure quantities that affect all nodes participating to smaller overall storage requirements and faster catch-up in the system: the size of signature sets, bandwidth, and block speed for new nodes. Sig. set size BM-Ed25519 Pixel Improvement 1 99.9 1 0.18 ms 4.9 ms 27x slower 0.8 78 0.6 64.9 1500 270 ms 6.7 ms 40x faster 3000 540 ms 8.3 ms 65x faster 10000 1.8 sec 15.6 ms 115x faster

Blockchain size (TB) Table 3: Total runtime to verify signature sets authenticating a block. Pixel verification includes the time to aggregate public 106 blocks; 1500 txs/block 108 blocks; 1500 txs/block keys.

1.7 173.7 1.5 151.9 1.4 138.8 resources it makes available. A relay must propagate a block of transactions and the corresponding certificate (with 1500 votes) to each node that it serves. During consensus, however, an additional 3000 supporting votes are propagated for every block. Each node connects to 4 randomly chosen relays. Ev- Blockchain size (TB) ery vote that the node receives from a relay, it propagates to 6 8 10 blocks; 5000 txs/block 10 blocks; 5000 txs/block the remaining 3 relays. Duplicate votes are dropped, so each BM-Ed25519 BM-BLS Pixel vote propagates once on each connection. In Table 2, we sum- marize savings for 4500 votes propagated during consensus Figure 3: Size of blockchain measured for different total num- for each block. From the table, we see that a relay with 10 ber of blocks. The top two plots assume average of 1500 connections saves about 44% of bandwidth. Bandwidth can transactions per block and the bottom plots assume 5000 be improved even further if Algorand relays were to aggregate transactions per block. All plots assume average of 1500 cer- multiple votes before propagating them to the users. tifying votes per block. Block Verification Time Savings. Since verifying a Pixel Number of connections BM-Ed25519 Pixel multi-signature requires only 3 pairings in addition to multi- 4 4.4 MB 2.5 MB plying all the public keys in the signature set, they are faster 10 11 MB 6.2 MB to verify than BM-Ed25519 signatures sets. Table 3 shows 100 109.9 MB 61.8 MB that a set of 3000 signatures can be verified about 65x faster. In Figure 4, we measure the overall savings on block verifica- Table 2: Total bandwidth to propagate a set of 4500 signatures tion time. Block verification time is broken into three main during consensus to agree on a block of transactions. intervals: (a) time to verify vote signatures, (b) time to verify vote VRF credentials, and (c) time to verify transactions. In each interval, signature verification dramatically exceeds the We clarify that the savings we obtain from Pixel are com- time of any additional checks (e.g., check that the transaction plementary to those of Vault [42], which is another system amount is higher than the user’s balance). Blocks with 1500 built on top of Algorand to improve storage and catch-up and 5000 transactions can be verified 38% and 29% faster, speed. In particular, Vault can be used in conjunction with respectively. Pixel to obtain further storage savings. Vault creates “jumps” between blocks so that the system can confirm block r know- ing only block r − k for some parameter k (e.g., k = 100). Instead of downloading every block, a catch-up node in Vault only needs to download every kth block. Even using Vault, 8 Conclusion users would need to download and store about 106 blocks for every ≈ 13 years of blockchain operation. In this work, we focus on improving the speed and secu- rity of PoS consensus mechanisms via optimizing its core building block – digital signature scheme. We design a new pairing-based forward-secure multi-signature scheme, Pixel. Bandwidth Savings. Algorand uses a relay-based propaga- We prove that Pixel is secure in the random oracle model tion model where users’ nodes connect to a network of relays under a variant of Diffie-Hellman inversion problem over bi- (nodes with more resources). Without aggregation during linear groups. Pixel is efficient as a stand-alone primitive and propagation, Pixel savings for the bandwidth for both relays results in significant performance and size reduction com- and regular nodes come from smaller signatures sizes. Each pared to the previous forward-secure signatures applied in set- relay can serve dozens or hundreds of nodes, depending on the tings where multiple users sign the same message (block). For 1,000 Computer and Communications Security, CCS 1997, 900 Zurich, Switzerland, April 1–4, 1997, September 2000.

800 [4] Elli Androulaki, Artem Barger, Vita Bortnikov, Chris- 690 636.7 tian Cachin, Konstantinos Christidis, Angelo De Caro, 600 600 600 David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, 426.7 400 336.7 336.7 Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, 270 270 Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko 200 Vukolic, Sharon Weed Cocco, and Jason Yellick. Hyper- ledger fabric: a distributed operating system for permis- Block verification time (ms) 6.7 6.7 0 sioned blockchains. In Rui Oliveira, Pascal Felber, and Y. Charlie Hu, editors, Proceedings of the Thirteenth EuroSys Conference, EuroSys 2018, pages 30:1–30:15. ACM, 2018. 1500 txs; BM 5000 txs; BM 1500 txs; Pixel 5000 txs; Pixel [5] Christian Badertscher, Peter Gaži, Aggelos Kiayias, Vote sigs VRF Txs sigs Alexander Russell, and Vassilis Zikas. Ouroboros gen- esis: Composable proof-of-stake blockchains with dy- Figure 4: Overall Algorand block verification time using BM- namic availability. In Proceedings of the 2018 ACM Ed25519 and Pixel signatures. Each block is assumed to con- SIGSAC Conference on Computer and Communications tain 1500 certifying votes. The two plots on the left assume Security, CCS ’18, pages 913–930, New York, NY, USA, 1500 txs/block; whereas the two plots on the right assume 2018. ACM. 5000 txs/block. [6] Ali Bagherzandi, Jung Hee Cheon, and Stanislaw Jarecki. Multisignatures secure under the discrete loga- instance, compared to a set of 1500 tree-based forward-secure rithm assumption and a generalized forking lemma. In signatures, a single Pixel signature that can authenticate the Peng Ning, Paul F. Syverson, and Somesh Jha, editors, entire set is 2667x smaller and can be verified 40x faster. We ACM CCS 2008, pages 449–458. ACM Press, October explained how to integrate Pixel to any PoS blockchains to 2008. solve posterior corruptions problem. We also demonstrate [7] Paulo S. L. M. Barreto, Ben Lynn, and Michael Scott. that Pixel provides significant efficiency gains when applied Constructing elliptic curves with prescribed embed- to Algorand blockchain. Pixel signatures reduce the size of ding degrees. In Stelvio Cimato, Clemente Galdi, and Algorand blocks with 1500 transactions by ≈ 35% and reduce Giuseppe Persiano, editors, SCN 02, volume 2576 of block verification time by ≈ 38%. LNCS, pages 257–267. Springer, Heidelberg, September 2003.

Acknowledgments [8] Mihir Bellare, Juan A. Garay, and Tal Rabin. Fast batch verification for modular exponentiation and digital signa- We would like to thank Zhenfei Zhang for implementing Pixel tures. In Kaisa Nyberg, editor, EUROCRYPT’98, volume as well as his help with Section 7. In addition, we thank Jens 1403 of LNCS, pages 236–250. Springer, Heidelberg, Groth, Nickolai Zeldovich, our shepherd Ari Juels, and the May / June 1998. anonymous reviewers for useful feedback. [9] Mihir Bellare and Sara K. Miner. A forward-secure digital signature scheme. In Michael J. Wiener, editor, References CRYPTO’99, volume 1666 of LNCS, pages 431–448. Springer, Heidelberg, August 1999. [1] Algorand’s official implementation in go. https:// github.com/algorand/go-algorand, 2019. [10] Mihir Bellare and Gregory Neven. Multi-signatures in the plain public-key model and a general forking [2] Algorand’s official pixel implementation. https:// lemma. In Ari Juels, Rebecca N. Wright, and Sabrina De github.com/algorand/pixel, 2019. Capitani di Vimercati, editors, ACM CCS 2006, pages 390–399. ACM Press, October / November 2006. [3] Ross Anderson. Two remarks on public-key cryptology. Manuscript. Relevant material presented by the author [11] Mihir Bellare and Phillip Rogaway. Random oracles are in an invited lecture at the 4th ACM Conference on practical: A paradigm for designing efficient protocols. In Dorothy E. Denning, Raymond Pyle, Ravi Ganesan, [22] Ran Canetti, Shai Halevi, and Jonathan Katz. A forward- Ravi S. Sandhu, and Victoria Ashby, editors, ACM CCS secure public-key encryption scheme. In Eli Biham, ed- 93, pages 62–73. ACM Press, November 1993. itor, EUROCRYPT 2003, volume 2656 of LNCS, pages 255–271. Springer, Heidelberg, May 2003. [12] Iddo Bentov, Rafael Pass, and Elaine Shi. Snow white: Provably secure proofs of stake. Cryptology ePrint [23] Ran Canetti, Shai Halevi, and Jonathan Katz. A forward- Archive, Report 2016/919, 2016. http://eprint. secure public-key encryption scheme. Journal of Cryp- iacr.org/2016/919. tology, 20(3):265–294, July 2007.

[13] Alexandra Boldyreva. Threshold signatures, multisig- [24] Jing Chen, Sergey Gorbunov, Silvio Micali, and Geor- natures and blind signatures based on the gap-Diffie- gios Vlachos. Algorand agreement: Super fast and par- Hellman-group signature scheme. In Yvo Desmedt, tition resilient byzantine agreement. Cryptology ePrint editor, PKC 2003, volume 2567 of LNCS, pages 31–46. Archive, Report 2018/377, 2018. Springer, Heidelberg, January 2003. [25] Jung Hee Cheon. Security analysis of the strong Diffie- [14] Dan Boneh, Xavier Boyen, and Eu-Jin Goh. Hierarchical Hellman problem. In Serge Vaudenay, editor, EU- identity based encryption with constant size ciphertext. ROCRYPT 2006, volume 4004 of LNCS, pages 1–11. In Ronald Cramer, editor, EUROCRYPT 2005, volume Springer, Heidelberg, May / June 2006. 3494 of LNCS, pages 440–456. Springer, Heidelberg, May 2005. [26] Sherman S. M. Chow, Lucas Chi Kwong Hui, Siu-Ming Yiu, and K. P. Chow. Secure hierarchical identity based [15] Dan Boneh, Manu Drijvers, and Gregory Neven. Com- signature and its application. In Javier López, Sihan pact multi-signatures for smaller blockchains. In Qing, and Eiji Okamoto, editors, ICICS 04, volume 3269 Thomas Peyrin and Steven Galbraith, editors, ASI- of LNCS, pages 480–494. Springer, Heidelberg, October ACRYPT 2018, Part II, volume 11273 of LNCS, pages 2004. 435–464. Springer, Heidelberg, December 2018. [27] M. Conti, E. Sandeep Kumar, C. Lal, and S. Ruj. A [16] Dan Boneh, Ben Lynn, and Hovav Shacham. Short survey on security and privacy issues of bitcoin. IEEE Journal of Cryptology signatures from the Weil pairing. , Communications Surveys Tutorials, 20(4):3416–3452, 17(4):297–319, September 2004. Fourthquarter 2018. [17] Joseph Bonneau, Andrew Miller, Jeremy Clark, Arvind [28] Phil Daian, Rafael Pass, and Elaine Shi. Snow white: Narayanan, Joshua A. Kroll, and Edward W. Felten. Robustly reconfigurable consensus and applications to SoK: Research perspectives and challenges for bitcoin provably secure . In Financial Cryptogra- and . In 2015 IEEE Symposium on phy and Data Security FC, 2019. Security and Privacy, pages 104–121. IEEE Computer Society Press, May 2015. [29] Bernardo David, Peter Gazi, Aggelos Kiayias, and Alexander Russell. Ouroboros praos: An adaptively- [18] Xavier Boyen, Hovav Shacham, Emily Shen, and Brent secure, semi-synchronous proof-of-stake blockchain. In Waters. Forward-secure signatures with untrusted up- Jesper Buus Nielsen and Vincent Rijmen, editors, EU- date. In Ari Juels, Rebecca N. Wright, and Sabrina De ROCRYPT 2018, Part II, volume 10821 of LNCS, pages Capitani di Vimercati, editors, ACM CCS 2006, pages 66–98. Springer, Heidelberg, April / May 2018. 191–200. ACM Press, October / November 2006.

[19] Eric Brier, Jean-Sébastien Coron, Thomas Icart, David [30] David Derler, Stephan Krenn, Thomas Lorünser, Sebas- Madore, Hugues Randriam, and Mehdi Tibouchi. Ef- tian Ramacher, Daniel Slamanig, and Christoph Striecks. ficient indifferentiable hashing into ordinary elliptic Revisiting proxy re-encryption: Forward secrecy, im- curves. In Tal Rabin, editor, CRYPTO 2010, volume proved security, and applications. In Michel Abdalla 6223 of LNCS, pages 237–254. Springer, Heidelberg, and Ricardo Dahab, editors, PKC 2018, Part I, volume August 2010. 10769 of LNCS, pages 219–250. Springer, Heidelberg, March 2018. [20] Vitalik Buterin. Long-range attacks: The serious prob- lem with adaptive . https://blog. [31] Manu Drijvers, Kasra Edalatnejad, Bryan Ford, Eike ethereum.org, 2014. Kiltz, Julian Loss, Gregory Neven, and Igors Stepanovs. On the security of two-round multi-signatures. In 2019 [21] Vitalik Buterin and Virgil Griffith. Casper the friendly IEEE Symposium on Security and Privacy, pages 1084– finality gadget. CoRR, abs/1710.09437, 2017. 1101. IEEE Computer Society Press, May 2019. [32] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vla- [42] Derek Leung, Adam Suhl, Yossi Gilad, and Nickolai chos, and Nickolai Zeldovich. Algorand: Scaling byzan- Zeldovich. Vault: Fast bootstrapping for the algorand tine agreements for cryptocurrencies. In Proceedings of . In 26th Annual Network and Distributed the 26th Symposium on Operating Systems Principles, System Security Symposium, NDSS 2019, San Diego, SOSP ’17, pages 51–68, New York, NY, USA, 2017. California, USA, February 24-27, 2019, 2019. ACM. [43] Steve Lu, Rafail Ostrovsky, Amit Sahai, Hovav [33] Felix Günther, Britta Hale, Tibor Jager, and Sebastian Shacham, and Brent Waters. Sequential aggregate Lauer. 0-RTT key exchange with full forward secrecy. In signatures and multisignatures without random oracles. Jean-Sébastien Coron and Jesper Buus Nielsen, editors, In Serge Vaudenay, editor, EUROCRYPT 2006, volume EUROCRYPT 2017, Part III, volume 10212 of LNCS, 4004 of LNCS, pages 465–485. Springer, Heidelberg, pages 519–548. Springer, Heidelberg, April / May 2017. May / June 2006.

[34] Timo Hanke, Mahnush Movahedi, and Dominic [44] Changshe Ma, Jian Weng, Yingjiu Li, and Robert H. Williams. Dfinity technology overview series, Deng. Efficient discrete logarithm based multi-signature consensus system, 2018. scheme in the plain public key model. Des. Codes Cryptography, 54(2):121–133, 2010. [35] K. Itakura and K. Nakamura. A public-key cryptosystem [45] Di Ma and Gene Tsudik. Forward-secure sequential suitable for digital multisignatures. Technical report, aggregate authentication. In 2007 IEEE Symposium on NEC Research and Development, 1983. Security and Privacy (S&P 2007), pages 86–91. IEEE Computer Society, 2007. [36] Gene Itkis and Leonid Reyzin. Forward-secure signa- tures with optimal signing and verifying. In Joe Kilian, [46] Tal Malkin, Daniele Micciancio, and Sara K. Miner. Ef- editor, CRYPTO 2001, volume 2139 of LNCS, pages ficient generic forward-secure signatures with an un- 332–354. Springer, Heidelberg, August 2001. bounded number of time periods. In Lars R. Knud- sen, editor, EUROCRYPT 2002, volume 2332 of LNCS, [37] Thomas Kerber, Aggelos Kiayias, Markulf Kohlweiss, pages 400–417. Springer, Heidelberg, April / May 2002. and Vassilis Zikas. Ouroboros crypsinous: Privacy- preserving proof-of-stake. In IEEE Symposium on Secu- [47] Silvio Micali. ALGORAND: the efficient and demo- rity and Privacy SP, pages 157–174, 2019. cratic ledger. CoRR, abs/1607.01341, 2016.

[38] Thomas Kerber, Markulf Kohlweiss, Aggelos Kiayias, [48] Silvio Micali, Kazuo Ohta, and Leonid Reyzin. and Vassilis Zikas. Ouroboros crypsinous: Privacy- Accountable-subgroup multisignatures: Extended ab- preserving proof-of-stake. Cryptology ePrint Archive, stract. In Michael K. Reiter and Pierangela Samarati, Report 2018/1132, 2018. https://eprint.iacr. editors, ACM CCS 2001, pages 245–254. ACM Press, org/2018/1132. November 2001.

[39] Aggelos Kiayias, Alexander Russell, Bernardo David, [49] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic and Roman Oliynykov. Ouroboros: A provably secure cash system,” http://bitcoin.org/bitcoin.pdf, 2008. proof-of-stake blockchain protocol. In Jonathan Katz [50] Kazuo Ohta and Tatsuaki Okamoto. A digital multisig- and Hovav Shacham, editors, CRYPTO 2017, Part I, nature scheme based on the Fiat-Shamir scheme. In volume 10401 of LNCS, pages 357–388. Springer, Hei- Hideki Imai, Ronald L. Rivest, and Tsutomu Matsumoto, delberg, August 2017. editors, ASIACRYPT’91, volume 739 of LNCS, pages [40] Eleftherios Kokoris-Kogias, Philipp Jovanovic, Nicolas 139–148. Springer, Heidelberg, November 1993. Gailly, Ismail Khoffi, Linus Gasser, and Bryan Ford. [51] Rafael Pass and Elaine Shi. Thunderella: Blockchains Enhancing bitcoin security and performance with strong with optimistic instant confirmation. In EUROCRYPT, consistency via collective signing. In Thorsten Holz and pages 3–33, 2018. Stefan Savage, editors, USENIX Security 2016, pages 279–296. USENIX Association, August 2016. [52] Andrew Poelstra. On stake and consensus. https: //download.wpsoftware.net/bitcoin/pos.pdf, [41] Hugo Krawczyk. Simple forward-secure signatures 2015. from any signature scheme. In Dimitris Gritzalis, Sushil Jajodia, and Pierangela Samarati, editors, ACM CCS [53] Thomas Ristenpart and Scott Yilek. The power of 2000, pages 108–115. ACM Press, November 2000. proofs-of-possession: Securing multiparty signatures 2 ` ` against rogue-key attacks. In Moni Naor, editor, EURO- (α ) (α ) α (α ) g1 ,...,A` = g1 ,B1 = g2 ,...,B` = g2 ,C), algorithm B CRYPT 2007, volume 4515 of LNCS, pages 228–245. proceeds as follows. Springer, Heidelberg, May 2007. ∗ ∗ It first runs A to obtain (t¯,t ,M ). That is, A receives skt¯ and produces a forgery on t∗,M∗. Let w∗ ∈ {0,1,2}`−1 such [54] David Schwartz, Noah Youngs, and Arthur Britto. The ∗ that w∗ = w∗k...kw∗ = t∗k0`−1−|t |. It then sets the public Ripple protocol consensus algorithm. Ripple Labs Inc 1 `−1 White Paper, https://ripple.com/files/ripple_ key and public parameters as consensus_whitepaper.pdf, 2014. y ← B1 [55] N. R. Sunitha and B. B. Amberker. Forward-secure γ h ← g · A` multi-signatures. In Manish Parashar and Sanjeev K. 1 `−1 ∗ ∗ Aggarwal, editors, Distributed Computing and Internet γ0 −wi −M h0 ← g1 · ∏ A`−i+1 · A1 Technology, 5th International Conference, ICDCIT 2008, i=1 volume 5375 of Lecture Notes in Computer Science. γ h ← g i · A for i = 1,...,` , Springer, 2009. i 1 `−i+1

$ [56] Algorand Team. Algorand blockchain features specifi- where γ,γ0,...,γ` ← Zq. cation version 1.0. Github, 2019. By setting the parameters as such, B implicitly sets x = α `+1 and hx = Aγ · g(α ). The reduction allows us to achieve two [57] Algorand Team. Algorand byzantine fault tolerance 1 1 goals: protocol specification. Github, 2019.

[58] The Elrond Team. Elrond: A highly scalable pub- • extract the value of hx from a forgery on t∗,M∗ (provided 0 ∗ lic blockchain via adaptive state sharding and se- by A ), allowing B to easily compute its `-wBDHI3 so- https://elrond.com/files/ (α`+1) cure proof of stake. lution e(g1,C) ; Elrond_Whitepaper_EN.pdf, 2019. 0 ≤`−1 • simulate ske w0 for all w ∈ {0,1,2} which are not a [59] The ZILLIQA Team. The zilliqa technical whitepa- prefix of w∗; this would be useful for simulating both per, 2017. http://docs.zilliqa.com/whitepaper. the signing and the break-in oracle. pdf. 0 [60] Riad S. Wahby and Dan Boneh. Fast and simple Algorithm B responds to A ’s oracle queries as follows. constant-time hashing to the BLS12-381 elliptic curve. IACR TCHES, 2019(4):154–179, 2019. Key update. There is no need for B to simulate anything https://tches.iacr.org/index.php/TCHES/ beyond keeping track of the current time period t. article/view/8348. Signing. We first describe how to answer a signing query for [61] Jia Yu, Fanyu Kong, Xiangguo Cheng, Rong Hao, ∗ Yangkui Chen, Xuliang Li, and Guowen Li. Forward- a message M in time period t 6= t , and then describe the case that t = t∗ and M 6= M∗. Let w ∈ {0,1,2}`−1 be such secure multisignature, threshold signature and blind sig- `−1−|t| nature schemes. Journal of Networks, 5(6):634–641, that w = tk0 . 2010. Case 1: t 6= t∗. It is easy to see that t 6= t∗ ⇒ w 6= w∗. (This crucially uses the fact that t,t∗ ∈ {1,2}∗.) Then, let 0 A Security Proof of Forward-Secure Signa- w = w1k···kwk denote the shortest prefix of w which ∗ tures is not a prefix of w . Extending the notation of ske w0 to w0 ∈ {0,1,2}≤`−1, we describe how B can derive a valid Proof. We prove the theorem in two steps. First, we show key ske w0 , from which it is straight-forward to derive both ske w that the scheme is selectively secure when the message space and a signature for t,M. Recall that sk 0 has the structure κ e w M = {0,1} and Hq is the identity function, meaning, inter- preting a κ-bit string as an integer in Zq. (c,d,ek+1,...,e`) = Step 1: sfu-cma. We show that the above scheme with mes-  k  κ r x wi r r r sage space M = {0,1} and Hq the identity function is g , h h0 h , h ,..., h ∗ 2 ∏ i k+1 ` sfu-cma-secure under the `-wBDHI3 assumption by describ- i=1 ing an algorithm B that, given a successful sfu-cma forger 0 ∗ α A , solves the `-wBDHI3 problem. On input (A1 = g1 ,A2 = for a uniformly distributed value of r. Focusing on the second component d first, we have that Case 2: t = t∗,M 6= M∗. For a signing query with t = t∗ ∗ r but M 6= M , B proceeds in a similar way, but derives the k ! x wi signature (σ1,σ2) directly. Algorithm B can generate a d = h · h0 · ∏hi i=1 valid signature using a similar approach as above, but us- r ing the fact that M 6= M∗ instead of w 6= w∗. Namely, letting `−1 k wi ! k k  ∗ ∗    γ α γ0 −wi −M γi w = tk0`−1−|t|, B computes a signature = g1A` · g1 ∏ A`−i+1A1 · ∏ g1 A`−i+1 i=1 i=1 !r r `−1 `−1 ! x wi M `+1 k ∗ ∗ ∗ = h · h · h · h γ (α ) γ0+∑i=1 γiwi wk−wk −wi −M σ1 0 ∏ i ` = A1g1 · g1 A`−k+1 · ∏ A`−i+1A1 , i=1 i=k+1 `−1  ∗ ∗  ∗ γ α γ0 −wi −M where the third equality holds because wi = wi for 1 ≤ i < k = g1A` · g1 · ∏ A`−i+1 · A1 · ∗ `−1 i=1 and wk 6= w . (Note that in the product notation ∏ k i=k+1 !r above, we let the result of the product simply be the unity `−1  wi γi γ` M element if k + 1 > ` − 1.) Let us denote the four factors ∏ g1 · A`−i+1 · (g1 · A1) F F F i=1 between parentheses in the last equation as 1, 2, 3, and r `+1  + `−1 w + M ∗  F4, and denote their product as F. If we let γ (α ) γ0 ∑i=1 γi i γ` M−M = A1 · g1 · g1 · A1 k 0 α r r ← r + ∗ mod q σ2 = g2 wk − wk by setting for a random r0 ←$ , then we have that Zq α` r ← r0 + mod q αk ∗ `+1 0 ∗ M − M γ (α ) r w −wk d = A · g · F · F k . 0 $ 1 1 for r ← Zq, so that B can compute (σ1,σ2) from its inputs ∗ The first and third factors in this product are easy to compute. A1,...,A`,B1,...,B` similarly to the case that t 6= t . The second factor would allow B to compute the solution ∗ ¯ `+1 Break in. Here, B needs to simulate skt¯ where t ≺ t. This its `-wBDHI∗ problem as e(g(α ),C), so B cannot simply 3 1 in turn requires simulating ske w for all w ∈ Γt¯. By the first αk w∗−w property of Γt¯ (described in Section 4.2), all of these w are compute it. The last factor F k k can be written as the not prefixes of t∗ and also not prefixes of w∗, and we can product of therefore simulate ske w exactly as before. k αk γ0+∑i=1 γiwi ∗ ∗ Forgery. When A0 outputs a forgery ( ∗, ∗) that satisfies wk −wk wk −wk σ1 σ2 F1 = Ak the verification equation αk ∗ `+1 ∗ w −wk k −(α ) |t | ∗ k −α t ∗ F2 = A`−k+1 = g1 ∗ j M ∗ e(σ1,g2) = e(h,y) · e h0 · ∏ h j · h` , σ2 , k −w∗ −w∗ α `−1 i `−k−2 k+2+i j=1 w∗−w w∗−w w∗−w F k k = A k k = A k k 3 ∏ `+k−i+1 ∏ `−i then there exists an r ∈ q such that i=k+1 i=0 Z αk −M∗ |t∗| w∗−w w∗−w t∗ ∗ r k k k k ∗ = hα · h · h i · hM  F4 = Ak+1 . σ1 0 ∏ i ` i=1 Because 1 ≤ k ≤ ` − 1, it is clear that all but the second of ∗ r σ2 = g2 . these can be computed from B’s inputs, and that the second `+1 (α ) From the way that B chose the parameters h,h0,...,h`, one cancels out with the factor g1 in d, so that it can indeed compute d this way. The other components of the key are can see that ∗ ( `+1) |t | ∗ ∗ also efficiently computable as ∗ γ α r γ0+∑i=1 γiti +γ`M σ1 = A1 · g1 · (g1) 1 0 ∗ r w −wk r c = g2 · Bk k Note that we do not know g1, so we cannot directly extract `+1 r0 g(α ) ∗ ei = hi · A`+k−i+1 for i = k + 1,...,` 1 from σ1. Instead, observe that we have 0 r γ (α`+1) = hk+i · A`−i for i = 0,...,` − k − 1 . ∗ e(σ1,C2) = e(A1,C2) · e(g1 ,C2) 0 ∗ From this key (c,d,e ,...,e ) for w , B can derive a key ∗ + |t | t∗+ M∗ k+1 ` · e(C ,σ )γ0 ∑i=1 γi i γ` , for w and compute a signature as in the real signing algo- 1 2 rithm. (α`+1) Random oracle H . On input (PoP,z), A0 checks whether from which B can easily compute its output e(g1 ,C2) = G1 `+1 e(g ,g )(γ·α ). It does so whenever A0 is successful, so that there already exists a tuple (z,·,v) ∈ L. If so, it returns v. If 1 2 $ ∗ r not, it chooses r ← Zq, computes v ← h , adds a tuple (z,r,v) `-wBDHI∗ to L and returns v.y Adv 3 (B) ≥ Advsfu-cma(A0) . G1×G2 FS Step 2: extracting a forgery. When A outputs its forgery Step 2: fu-cma. Full fu-cma security for M = {0,1}∗ and with H : M → {0,1}κ modeled as a random oracle then q (pk∗, ∗,...,pk∗, ∗),M∗,t∗, ∗, follows because, given an fu-cma adversary A in the random- 1 π1 n πn Σ oracle model, one can build a sfu-cma adversary A0 that ∗ 0 ∗ ∗ guesses the time period t and the index of A’s random-oracle algorithm A first verifies the proofs π1,...,πn for public ∗ ∗ 0 ∗ ∗ ∗ query for Hq(M ), and sets t¯ ← t +1. If A correctly guesses keys pk1,...,pkn and computes the aggregate public key apk , ∗ ∗ xi t , then it can use skt¯ to simulate A’s signature, key update, creating additional entries in L if necessary. Let pki = yi = g2 ∗ 0 ∗ and break-in queries after time t¯ until A’s choice of break-in and πi = yi. Looking ahead, if pki passes key verification, ¯0 then we have y0 = (hxi )ri and since we know r , we will be time t , at which point it can hand over skt¯0 . i i 0 ∗ xi If A moreover correctly guessed the index of Hq(M ), able to “extract” h ∈ G1. A H (M) = H (M0) 0 PoP xi and if never made colliding queries q q for If all keys are valid, then it holds that yi = HG1 ( ,yi) M 6= M0, then A’s forgery is also a valid forgery for A0. Note for all i = 1,...,n. Let apk∗ = Y be the aggregate public key. that for A to be successful, it must hold that t¯0 > t∗, so it must From the aggregate verification equation hold that t¯0 ≥ t¯. The advantage of A0 is given by ∗ |t | ∗ ∗ 2 t j Hq(M ) 0 1 q ∗ ∗ sfu-cma(A ) ≥ · fu-cma(A) − H , e(Σ1,g2) = e(h,Y) · e h0 · ∏ h j · h` , Σ2 AdvFS AdvFS κ (3) T · qH 2 j=1 where qH is an upper bound on A’s number of random-oracle n ∑ xi n i=1,yi6=y queries. Together with Equation (3), we obtain the inequality and the fact that Y = ∏i=1 yi = y · g2 , we have that of the theorem statement. n ∗ ∑i=1,y 6=y xi e(Σ1,g2) = e(h,y) · e(h,g2) i ·

B Security Proof of Forward-Secure Multi- ` ∗ ∗ t j Hq(M ) ∗ signatures e h0 · ∏ h j · h`+1 , Σ2 j=1 n −∑ xi Proof. We show how to construct a forger A for the multi- ∗ i=1,yi6=y 0 ⇔ e(Σ1 · h ,g2) = e(h,y)· signature scheme yields a forger A for the single-signer ∗ |t | ∗ ∗ scheme of Section 4.3 such that t j Hq(M ) ∗ e h0 · ∏ h j · h` , Σ2 . fu-cma 0 fu-cma j=1 AdvFS (A ) ≥ AdvFS (A) . 0 The theorem then follows from Theorem 1. For all yi 6= y, A looks up the tuple (yi,ri,vi) in L. We know ri 0 rixi Step 1: simulating A’s view. On input the parameters that vi = h , and hence that yi = h . By comparing the last equation above to the verification equation of the single-signer (T,h,h0,...,h`) and a public key y for the single-signer 0 rixi 0 $ ∗ scheme, and by observing that yi = h , we know that the scheme, the single-signer forger A chooses r ← Zq and r 0 r pair stores (y,⊥,g1) in a list L. It computes y ← y and runs A on the same common parameters and target public key pk = y 0 n = y −1/ri and proof π . Observe that π is indeed a valid proof for σ∗ ← Σ∗ · y0 pk since e(y0,g ) = e(H (PoP,y),y). 1 1 ∏ i 2 G1 i=1,yi6=y Algorithm A0 answers all of A’s key update, signing, and σ∗ ← Σ∗ break-in oracle queries, as well as random-oracle queries for 2 2 Hq, by simply relaying queries and responses to and from 0 A0’s own oracles. Queries to the random oracle for H are is a valid forgery for the single-signer scheme, so A can G1 ∗ ∗ ∗ ∗ answered as follows. output M ,t ,(σ1,σ2) as its forgery.