1 Introduction
Proofofstake (PoS) protocols have been heralded as a more ecological way to come to consensus on blockchain since it does not rely on expensive hardware using vast amounts of electricity to compute mathematical puzzles as bitcoin’s proofofwork mechanism. In a proofofstake blockchain protocol, roughly speaking, participants randomly elect one party to produce the next block by running a “leader election” process with probability proportional to their current stake (a virtual resource) held on blockchain.
In spite of high efficiency, proofofstake blockchains only account for a tiny percentage of existing digital currencies market, mainly due to the fact that most existing proofofstake protocols suffer from the wellknown longrange attacks [36][22][18](stemming from its weak subjectivity and costless simulation) which degrades security in the blockchain. A oftcited longrange attack is caused by secret key leakage (abbreviated as LRSL attack in this paper). Specifically, an adversary can attempt to bribe (or corrupt) the secret keys corresponding to accounts that have low or no stake currently but possessed substantial stake at some past moment, and then construct a fork and alter the history from the point in the past with (past) majority stake. Note that the accounts with small or (even zero) stake are highly susceptible to secret key leakage since they might not be protected as other active accounts which further facilitates this attack.
Puncturable signature (PS), introduced by Bellare et al. [9], provides a satisfying solution to construct practical proofofstake blockchain protocols resilient to LRSL attack. Loosely speaking, a puncturable signature scheme provides a Puncture functionality that, given a secret key and a message , produces an updated secret key that is able to sign all messages except for the punctured message . In this paper, we further generalize the definition of the puncturable signature, particularly, the strings associated with the punctured signing key can be any part of signed messages (e.g. its prefix). In proofofstake protocols, the leader (elected for issuing block) signs the block with the puncturable signature by the secret key at some time slot , where is the part of block , and then performs puncturing operation on message which results in an updated . More specifically, if no empty block is allowed, the punctured message can be instead of , where is the part of block and is the previous block of . The security of puncturable signature guarantees that anyone cannot sign another data block with the same (or ) even though is exposed, and thus LRSL attack can be avoided.
A natural way to remedy the LRSL attack in proofofstake blockchain protocols is to use the forward secure signature [8], which preserves the validity of past signatures even if the current secret key is compromised. However, the computation performance of the forward secure signature depends on either the time periods set in advance or the time periods elapsed so far logarithmically (even linearly), which brings undesirable consumption and becomes a fatal issue for blockchain applications. Moreover, most signers have no chance to do any signing within one period but they have to update the signing key as long as the current period ends, which makes the update operation a vain effort in the proofofstake blockchain. In fact, the forward secure signature can be treated as one special kind of the puncturable signature where the punctured message is the earlier period of time.
Puncturable signatures can also be used in many other scenarios such as asynchronous transaction data signing services. Transaction data signing is a process which guarantees the integrity and authenticity of the sensitive transaction data, such as payment instruction or transaction information of buying a real estate offering. In many cases, using ordinary digital signatures is not enough for these application, as they often fail to ensure the integrity of past messages in the case when a user’s key is compromised. This is particularly challenging in the noninteractive and asynchronous message system, where users may not be online simultaneously and messages may be delayed for substantial periods due to delivery failures and connectivity issues. Similar problem also exists in the theoretical part. For instance, in noninteractive multiparty computation (NIMPC) [24], where a group of completely asynchronous parties can evaluate a function (e.g. for the purpose of voting) over their joint inputs by sending a signed message to an evaluator who computes the output. The adversary would control the final output if he can corrupt some parties within a period of time. In these examples, the transaction session ID can be used as a prefix, and after the honest user signs the transaction data (or message), the prefix is punctured so that no other signature exists for messages agreeing on the same prefix. Therefore, the integrity of transaction data (or message) is ensured by puncturable signatures.
1.1 Our Contributions
In this work, we provide an indepth study of the puncturable signature and its applications in the proofofstake blockchain protocols. Our overall goal is to design a puncturable signature that allows for finegrained revocation of signing capability with minimum computation cost, and make it a suitable building block to construct secure and practical proofofstake blockchain protocol. More specifically, our technical contributions are as follows. Puncturable signature and its construction. We introduce the notion of puncturable signature with extended puncturing functionality where the secret key can be updated by puncturing any particular part of message (for simplicity, we use the prefix of message in this paper) instead of puncturing the whole message. In the security model we propose, in addition to making adaptive signing and puncturing queries, adversary also has (onetime) oracle access to a featured Corruption oracle, by which the adversary can obtain the current secret key if the challenging string is in the puncturing set . Then we show a construction of puncturable signature based on the probabilistic Bloom filter data structure [10] that is secure under our security model. Our PS construction is inspired by an elegant work [19], where the authors show how to construct puncturable encryption based on Bloom filter. However, different from the expanded ( times) ciphertext size of underlying encryption scheme in [19], in our construction, the signature size is almost equal to that of the underlying signature scheme.
In comparison with two prior puncturable signature schemes [9][24], our construction achieves significant efficiency improvement in both signing and puncturing operations. More specifically, the construction in [9] relies on indistinguishability obfuscation, which incurs prohibitive computational burden in practice, while the other one [24] needs update public key for every puncturing, which has some theoretical merits but hard to implement in real world deployment. On the contrary, in our construction, a puncturing operation only involves a small number of efficient computations (i.e. hashing), plus the deletion of certain parts of the secret key, which outperforms previous schemes by orders of magnitude. Indeed, the puncturable signature is not a simple inverse operation of the puncturable encryption, which is also the reason for no efficient puncturable signature scheme even though efficient puncturable encryption constructions have been proposed for a long time. The crucial difficulty in designing the puncturable signature scheme is how to bind the private key with punctured messages such that the updated private key cannot sign for punctured messages.
Applications in Proofofstake blockchain protocol. We use puncturable signature to construct practical proofofstake blockchain protocols that are resilient to the LRSL attack. Ouroboros Paros [17], a proofofstake blockchain protocol, has a realworld implementation in Cardano platform. We present an ideal functionality of the puncturable signature scheme, and replace of the forward secure signature scheme in Ouroboros Paros [17] protocol with . Then we show that the properties (common prefix, chain quality and chain growth) of Ouroboros Paros protocol remain true in the replaced setting. However, most of the existing forward secure signatures have poor performance on key update as well as other operations, often depending on the time period number linearly, which is unsuitable for blockchain application. We conduct experiments evaluating the overhead of deploying our puncturable signature construction and existing forward security signature schemes [29][38] at both 128bit and 192bit security levels. Figure 1 illustrates the efficiency comparison and the results show that our scheme performs substantially better on signature size, signing and verification efficiency, significantly on key update efficiency, which reduces both communication and computation complexity. In fact, we can replace the ordinary signature with our puncturable signature construction in any other proofofstake protocols such as Ouroboros [32] and Snow White [16] protocols. Due to the fact that our construction can retain the efficiency of the underlying scheme on signing and verifying, with additional hash computations, the improved protocols can provide resilience to the LRSL attack at almost no additional computing cost.
1.2 Related Work
Puncturable signature. A puncturable signature scheme allows to update its signing key for an arbitrary message such that the resulting punctured signing key can produce signatures for all messages except for . It is introduced by Bellare et al. [9] as a tool to prove a negative results on differinginputs obfuscation. However, their construction is based on indistinguishability obfuscation [21] and oneway function, thus, do not yield practical schemes. Moreover, it requires that the punctured signing key is associated with the full signed message. In contrast our construction is based on the SDH assumption, and the string associated with the punctured signing key can be any particular part of the message to be signed (e.g. the prefix of the message), which is more flexible and applicable. Halevi et al. [24] also propose a puncturable signature scheme which is puncturable at any prefix of the signed message. However, their puncturable operation needs to update public keys repeatedly. In practice, it is inefficient to verify the updated public keys continuously and it is also difficult to let each user in the system maintain other users’ public keys updated. Delegatable Signature. Policybased signature, introduced by Bellare et al. [7], allows a signer to only sign messages conforming to some authorityspecified policy. It elegantly unifies existing work, capturing other forms of signatures as special cases. Puncturable signature differs from this work, as the secret key is updated adaptively with respect to the message prefix. Another related primitive, called functional signature is introduced in work [12]. In the functional signature, in addition to a master signing key that can be used to sign any message, there are signing keys for a function , which allow one to sign any message in the range of . Delegatable functional signature is introduced in work [3] and supports the delegation of signing capabilities to another party, called the evaluator, with respect to a functionality. Appendonly signatures (AOS) [33] is also a related primitive, in particular, any party given an AOS signature on a message can compute an AOS signature on any message . Different from above primitives, puncturable signature provides a puncture functionality that may repeatedly update the secret key to revoke signing capability for selected messages besides providing delegation function. Forward secure signature. A forward secure signature scheme guarantees the adversary with the compromised secret key at some point in time cannot forge signatures relative to previous time periods. It is introduced by Anderson [2] and formalized by Bellare et al. [8]. The constructions of prior forward secure signatures are divided into two categories: using arbitrary signature schemes in a black box manner [38][35], and modifying specific signature schemes [8][29][1]. All these forward secure schemes except for [38], the number of time periods (arbitrarily large) must be set in advance, such that the performance depends on logarithmically or even linearly. Nevertheless, the performance in [38] still depends on the time periods elapsed so far. Proofofstake blockchain protocols. Proofofstake protocols were first initiated in online forums and subsequently a number of proofofstake protocols were proposed and implemented by the academic community. In order to provide forward security (and also achieve resilience against the LRSL attack and other longrange attacks), Ouroboros Paros [17] and Ouroboros Genesis [4] formalize and realize in the universal composition setting a forward secure digital signature scheme, Algorand [23] considers it as one of future work and implements ephemeral key pairs in its updated full version [15], whereas Snow White [16] and Ouroboros [32] adopt a weak adaptive corruption model and cannot avoid LRSL attack. In addition, several countermeasures have been proposed, such as punishment by revealing the real identity [36], revealing the signing key [20] or slashing the stake [13] of the malicious stakeholder, the trusted execution environments [36], and checkpointing mechanism [40].
2 Preliminaries
Notation. Let denote the security parameter, denote the greatest integer less than or equal to , denote the set of the first positive integers, and ppt denote probabilistic polynomial time. For an array , we let denote the th bit of the array, if .
We say a function is negligible, if for every constant , for sufficiently large .
2.1 Bloom Filter
A Bloom filter [10] is a probabilistic data structure for the approximate set membership problem. It allows a succinct representation of a set of elements from a large universe , where the price for succinctness is allowing errors. Put simply, for any the Bloom filter always outputs 1 (“yes”), and for any it outputs 1 only with small probability (called the falsepositive errors).
Definition 1 (Bloom Filter[19]).
A Bloom filter for set consists of algorithms , which are defined as follows.

[leftmargin=*]

: On input two integers , the algorithm first samples universal hash functions , where (). Set and ( is an bit array with all bits set to 0). Output .

: On input , , and , the algorithm defines the updated state by first assigning . Then, it sets for all , and returns .

: On input , and , the algorithm returns a bit .
Properties of Bloom filter. The properties of Bloom filter relevant to our work can be summarized as follows:

[leftmargin=*]

Perfect completeness: A Bloom filter always outputs 1 for elements that have already been added to the set . More precisely, let
be any vector of
elements of . Let and for , set . Then for any and any , we have 
Compact representation of set : The size of representation is a constant number of bits, and independent of the size of set and the representation of individual elements of . The increase in size of set only increases the falsepositive probability, but not the size of representation .

Bounded falsepositive errors: Given the size of set , the probability that an element which has not yet been added to the Bloom filter is erroneously “recognized” as being in the filter can be made arbitrarily small, by choosing and accordingly. More precisely, let be any vector of elements of , for any , we have where , = (, , for , and the probability is taken over the random coins of algorithm .
Discussion on the choice of parameters. In bloom filter, assuming the optimal number of hash function to achieve the smallest falsepositive probability , we obtain a size of the bloom filter given by , and the optimal is given by . For example, when and , we have MB and .
2.2 Bilinear Groups
We say that is a bilinear group generator if given the security parameter , it outputs a tuple , where , and are three groups have prime order , is the generator of for , and is a nondegenerate map satisfying:

[leftmargin=*]

Bilinearity: For any and , we have .

Nondegeneracy: For any , for any iff .

Computability: There is an efficient algorithm to compute for any .

There exists an efficiently, publicly computable isomorphism such that .
The security of our scheme is based on the strong DiffieHellman (SDH) assumption, which was previously formalized in [11] and [39].
Definition 2 (Strong DiffieHellman Assumption (Sdh)).
Let , and let , , ,,…, be a tuple for . We say SDH assumption holds if for any ppt adversary , with .
3 Puncturable Signatures
In this section, we formalize the syntax and security definition of puncturable signature, and then we propose a puncturable signature scheme and prove its security under the SDH assumption.
3.1 Syntax and Security Definition
Let the message space be . A puncturable signature scheme consists of a tuple of ppt algorithms with descriptions as follows:

[leftmargin=*]

: On input the security parameter , parameters and for the Bloom filter, the setup algorithm outputs the public key as well as the secret key .

: On input the secret key and a string , the puncturing algorithm outputs the updated secret key which is also called the punctured secret key. We also say that has been punctured.

: On input the secret key and a message , it outputs a signature .

: On input the public key , a signature and message , the verification algorithm outputs 1 if is a valid signature for . Otherwise, it outputs 0.
Correctness of puncturable signatures. Intuitively, the correctness requires that (1) signing is always successful with the initial, nonpunctured secret key, (2) signing fails when attempting to sign a message with a prefix that has been punctured, and (3) the probability that signing fails is bounded by some nonnegligible function, if the prefix of the message to be signed has not been punctured.
Definition 3 (Correctness).
For any message with prefix , any , and any sequence of invocations of , we have

, where is the initial, nonpunctured secret key.

If has been punctured, then .

Otherwise, it holds that , where is some (possibly nonnegligible) bound.
Remark 1.
We note that the puncturing functionality defined above is for messageprefix, whose length can be determined in specific implementation (e.g., the slot parameter in proofofstake blockchain). In specific applications, the message to be signed can be split into () parts denoted by , where different parts may have different lengths and different semantics, for example, denotes the time stamp and the remaining denotes the message specifics. We can extend the puncturing functionality by puncturing strings at arbitrarily predefined position (even the whole message), e.g. th part, which means the signing algorithm fails for message = if has been punctured. For simplicity, we still use prefixpuncturing through this paper, but both the definitions and our constructions can be easily extended to support the general puncturing functionality.
Security Definition. For the security definition of the puncturable signature scheme , we use the following experiment to describe it. Intuitively, the security definition of requires that the adversary cannot forge signatures on messages having been punctured even though the punctured secret key is compromised. Formally, for any ppt adversary , we consider the experiment between and the challenger :

Setup: computes and sends to adversary . The initializes two empty sets and .

Query Phase: Proceeding adaptively, the adversary can submit the following two kinds of queries:

[leftmargin=*]

Signature query: On input message from the adversary , computes and updates . Then sends back .

Puncture query: On input a string , updates by running , and updates = .


Challenge Phase: sends the challenge puncture string to challenger, and can still submit signature and puncture queries as described in the Query phase.

Corruption query: The challenger returns if and otherwise.

Forgery: outputs a forgery pair .
We say that adversary wins the experiment if is the prefix of and
Definition 4 (Unforgeability with adaptive puncturing).
We say the puncturable signature scheme is unforgeable with adaptive puncturing, if for any ppt adversary , the probability of winning experiment is , where the probability is over the randomness of the challenger and adversary.
3.2 Our Construction
We present a puncturable signature construction based on the Chinese IBS, an identitybased signature scheme standardized in ISO/IEC 148883 [28].
The key idea of our construction is to derive secret keys for all Bloom filter bits using IBS schemes, and then bind the prefix string with positions where the secret keys are used to sign messages with prefix . In addition, puncturing at implies the deletion of keys in the corresponding positions.
Let , and be a Bloom filter. Choose a random generator , and set . Let and be cryptographic hash functions, which we model as random oracles in the security proof. The public parameters are and all the algorithms described below implicitly take as input. The construction of the puncturable signature scheme is the following:

[leftmargin=*]

: This algorithm first generates a Bloom filter instance by running . Then it chooses and outputs
where , , and .

: Given a secret key where or , this algorithm first computes = (, , ). Then, for each define
where denotes the th bit of . Finally, the algorithm returns .

: Given a secret key and a message with the prefix , the algorithm first checks whether . (, , and outputs in this case. Otherwise, note that .(, , ) = 0 means there exists at least one index such that , where for . Then it picks a random index such that . Choose and compute , then set
The output signature on is .

: Given the public key , a message with the prefix , and a signature , the algorithm checks whether
where . If it holds, the algorithm outputs 1, and 0 otherwise.
Lemma 3.1.
Our basic construction described above satisfies correctness (c.f. Definition 3).
Proof.
If the secret key is initial and nonpunctured, we have
and then . Therefore, the first requirement of Definition 3 holds. If is punctured, by the perfect completeness of Bloom filter, we have = 1, which means all the secret keys used to sign messages with as the prefix have been deleted. Therefore, the signing of the message with the prefix fails and the second requirement of Definition 3 holds. If is not punctured, the correctness error of our construction occurs only when , which is essentially identical to the falsepositive probability of the Bloom filter and the third requirement of Definition 3 holds. ∎
Remark 2.
In this section, we assume that the falsepositive probability from Bloom filter is acceptable, which means the number of puncturings supported by our construction is below a preset parameter, depending on the application scenarios and also the upper bound of the Bloom filter. In the security proof below, we also assume that the number of puncturing queries is also bounded by the preset parameter.
Theorem 1.
Assuming that an algorithm wins in the experiment (c.f. Definition 4) to our construction , with the advantage within a running time , then the SDH assumption can be broken for within a running time , where , and are the maximum query times of the hash function , and signing respectively.
Proof.
In order to prove the security of our scheme, we consider a particular adversary with a fixed position against our signature scheme in a variant of the above experiment , denoted by . Specifically, in the Setup, the challenger returns system parameters together with a fixed position ; the following Query Phase remains unchanged and the Challenge Phase can be omitted; in the Corruption query, the challenger only returns the current secret key by excluding the key at position . We say wins the experiment , if outputs some message together with a valid signature () on .
We sketch the proof in two steps as in [6][PKC:ChoChe03]. First, we prove there exists an algorithm that wins in the experiment with a nonnegligible advantage, if the adversary has a nonnegligible advantage against our signature scheme in the experiment (c.f. Lemma 3.2). Then, assuming the existence of , we can construct an algorithm that breaks the SDH assumption (c.f. Lemma 3.3).
Lemma 3.2.
Assuming that an algorithm wins in the experiment (c.f. Definition 4) to our construction , with a probability within a running time , then there exists an algorithm that wins in the experiment as described above to which has a probability within a running time .
Proof.
Suppose there exists such an adversary , and we construct a simulator that simulates an attack environment and uses ’s forgery to win in its own experiment. The simulator can be described as follows:

[leftmargin=*]

Invocation. is invoked on a given position .

Queries. answers adaptive queries from as follows:

[leftmargin=*]

makes the query and forwards all the returned parameters to for ’s Setup query.

Before outputs the challenge string, just forwards the queries of , including , , and , to its experiment and returns the result to .

When outputs the challenge string denoted by after the series of queries, checks whether {} and aborts if this does not hold. Otherwise, provides the simulation for as follows. For the queries , , and , just passes them to its challenger and returns the result as before. While for query, firstly checks whether and returns if this does not hold. Otherwise, makes query in its experiment, and returns the response to .

Eventually, outputs a valid signature , where is the prefix of . If , then sets as its own output and apparently also wins in its experiment.
In the simulation described above, there are two events that cause to abort: (1) for the challenge string ; (2) for the forged signature .
Recall that the hash functions in Bloom filter are sampled universally and independently, and thus each position in the array is selected with an equal probability. Besides, is invisible and looks random to , then the selection of is independent of . Therefore the probability that is . Similarly, the second event happens with probability . Combing these, with probability , completes the whole simulation without aborting and wins in the experiment. ∎
Lemma 3.3.
Assuming that an algorithm wins in the experiment to our construction , with an advantage within a running time , then there exists an algorithm that breaks the SDH assumption for within a running time , where , and are the maximum query times of the hash function , and signing respectively.
Proof.
Suppose there exists such an adversary , and we construct a simulator that simulates an attack environment and uses ’s forgery to break the SDH assumption. The simulator can be described as follows:

[leftmargin=*]

Invocation. takes as input a random instance , , , ,…, and aims to find a pair () for some .

Setup. samples elements ,,, , where the () will be used as the response to ’s queries. expands the polynomial to obtain so that .
Then sets and to be new generators of and . Then the master public key is set to such that , thus the master secret key is the unknown .
To provide the secret keys corresponding to positions having been queried to , expands and
Thus, the pairs () can be computed using the left member of equation (1).
Then provides the parameters , , , , , , , , , to . In addition, also generates a Bloom filter as , then outputs the verification key (now ) and challenge position to . Then is ready to answer ’s queries during the simulation. For simplicity, we may assume as in [PKC:ChoChe03] that for any , queries at most once and any query involving is proceeded by the RO query , which means that has to query before he can obtain a signature () from Signature query and obtain the secret key from Corruption query by using a simple wrapper of .

Hash function queries. initializes a counter to 1.

[leftmargin=*]

: On input , returns a random if . Otherwise, returns and increments . In both cases, stores () in a list .

On input , outputs if is in the list (initialized to be empty). Otherwise, it outputs a random element and stores () in .
Note that, according to the query of and the computation in the setup phase, knows the secret key for .


Query Phase. answers adaptive signing and puncturing queries from as follows:

[leftmargin=*]

Signature query: On input a message with prefix , first checks and outputs in this case. Otherwise, there exists at least one index such that , where , for . picks a random , and , computes and sets , and backpatches to define . Finally, stores in , and returns the signature ( aborts in the unlikely collision event that is already defined by other query results of or , the probability of which is negligible since is random [JC:PoiSte00]).

Puncture query: On input a string , first updates . Then for each , update
The updated signing key is .


Corruption query: For Corruption query, recovers the matching pair () from and returns the previously computed .

Forgery. If adversary forges a valid tuple in a time with probability , where the message has prefix , according to the forking lemma [JC:PoiSte00], can replay adversary with different choices of random elements for hash function and obtain two valid tuples and , with in expected time .
Now a standard argument for outputs of the forking lemma can be applied as follows: recovers the pair () from , and note that with probability at least . Since both forgeries satisfies the verification equation, we can obtain the following relations:
where . Then we have
and hence . From , can proceed as in [11] to extract : first writes the polynomial as for some polynomial and some by using long division method, and eventually computes
Comments
There are no comments yet.