Forward-Secure Multi-User Aggregate Signatures Based on zk-SNARKs

As a solution to mitigate the key exposure problems in the digital signature, the forward security has been proposed. The forward security guarantees the integrity of the messages generated in the past despite leaks of a current time period secret key by evolving a secret key on each time period. In this paper, we propose a new forward secure aggregate signature scheme utilizing recursive zk-SNARKs (zero knowledge Succinct Non-interactive ARguments of Knowledge). Our proposal has constant complexities in key/signature sizes, signature generation, and verification time. The proposed forward secure signature scheme can aggregate signatures generated by multiple users as well as a single user. The security of the proposed scheme is formally proven under zero-knowledge assumption and random oracle model. The experiment results show that our signature scheme yields 12 s for signing time, 1 ms for verification time, 25 s for aggregation time, with the 1.6 KB secret key size and signature size independent of the number of time periods.


I. INTRODUCTION
A digital signature is used widely in many of fields as an authentication such as IoT, blockchain, etc. [1]- [3]. However, the digital signature has a key managing issue since if the secret key is exposed, a signature can be forged. The forward security which assigns a different signing key to each time period alleviates a problem induced by the key exposure. After the security notion is firstly proposed by Anderson [4], several forward secure signature schemes have been devised [5]- [11] for decades. However, these works have a limitation in that the maximum time period T should be fixed in setup for the constant public key size. It causes the necessity of remaking the signing key and the public key when the maximum time period T ends. To avoid the problem, the maximum time period T is set to a large value.
The associate editor coordinating the review of this manuscript and approving it for publication was Chien-Ming Chen .
However, it results in the inefficiency of the signature scheme of which complexities are dependent on the maximum time period [5]- [7]. For instance, Abdalla's construction [6] has O(T ) time complexity in setup, signing, and the verification. Although recent optimization of Abdalla's construction [12] reduces signing cost to O(1) with some setup time tradeoff, the verification cost remains O(T ). While the verification time is constant in several works [7], [9], [13], still one of the metrics is dependent on the maximum time period in every approach.
In the different view of the signature, aggregation is a useful tool for alleviating a storage problem. Specifically, the aggregate signature is used in blockchain applications to reduce the space required for the signature storage, and it mitigates the burden of blockchain network caused by the immense size of the transactions [14]. Although there exist many aggregate signature schemes to merge the signatures [15]- [19], only a few researches support an aggregation VOLUME 9, 2021 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ of forward secure signatures [20]- [24]. However, the aggregate signature schemes are able to either aggregate signatures generated from a single user [20]- [23] or multi-user signatures at which period is equivalent [20]- [23]. This requirement makes difficult to be deployed in a decentralized environment where the time periods are often not synchronized. In this paper, we propose a forward secure multi-user aggregate signature scheme where all the complexities are totally independent of the time period T . The aggregation supports different messages and different users flexibly applicable for the decentralized environment. In our construction, we use a simulation extractable zk-SNARK (zero-knowledge Succinct Non-interactive Argument of Knowledge) [25]- [28] as a building block of the signature scheme. The zk-SNARK enables proving arbitrary statements and the arbitrariness of the statements facilitates the removal of restrictions in existing signature schemes. That is, it is able to consider zk-SNARK proof as a signature if the proof proves the statements that suit the requirement of the signature. Naively, we can have an idea to construct a forward secure signature scheme by proving following statements.
• A public verification key and a secret signing key are well constructed.
• The secret signing key is connected with a message.
• The secret signing key is updated correctly. Though all of the statements can be proven by simply including these statements in a zk-SNARK circuit, it is not enough for the forward secure signature since signing keys of all time periods are required as witnesses in the proof generation. Furthermore, it causes the inefficiency in that the circuit size increases proportional to the number of key updates. We resolve the issue by adopting PCD (Proof Carrying Data) [29] where a proof proves the verification result of the other proof to prove the update process without the previous signing key.
In Fig.1, we describe the flow of our forward secure aggregate signature construction. Sign, update, and aggregate algorithms are designed by subsuming zk-SNARK proof construction that proves required statements respectively. All the statements consist of verification of previous proof and additional computation. As described in 1) in Fig.1, when the initial signing key sk A,0 and sk B,0 are assumed to be composed of user secret value and the proof that proves a relation of user secret value and the verification key, the secret signing key can be updated recursively by proving statements for update. The statement stipulates that the verification result of the previous signing key is passed and the signing key of the next time period is generated correctly. By updating the signing key recursively, we can keep the circuit size constant regardless of how many times the signing key is updated. When the updated signing key sk A,j and the message m A are given, the signature generation is conducted similar to the update. For instance, when Alice proves that the secret signing key for j period sk A,j is verified and the message m A and the time period j is connected with the secret signing key, the proof can be a forward secure signature itself. In aggregation described in 3), the third party aggregator verifies σ A,j and σ B,k that are signatures of Alice and Bob in j,k time period respectively. The third party aggregator proves the verification results and the aggregation of two signatures. That is, if the verification of two signatures is converged into one zk-SNARK proof, it can be an aggregate signature itself. Since the aggregation needs only the public information required in the verification, it can be conducted publicly.

A. OUR CONTRIBUTIONS 1) GENERIC CONSTRUCTION OF A FORWARD SECURE SIGNATURE USING zk-SNARK
We propose a generic construction of the forward secure signature via zk-SNARKs. In our construction, any kind of simulation extractable zk-SNARK from the pre-processing SNARKs such as GM17 [25], and KLO20 [30] to universal structured reference string based SNARKs such as MBKM19 [31], GWC19 [32], and BBB+18 [33] can be utilized as a building block. Various zk-SNARK libraries including libsnark [34], and snarkjs [35] can be used in the signature construction freely.

2) O(1) EFFICIENCY
We construct a forward secure signature of which complexities are independent of the time period. In fact, our scheme does not require any maximum time period in the scheme setup. In our forward secure signature, all of the metrics in setup, update, sign, and verify algorithms have O(1) time and space complexities. Note that the verification key size, secret key size and the signature size are constant. Table 1 compares performance and space requirement of forward secure signature schemes [5]- [7], [9], [12]. While all metrics are constant in our signature scheme, the other schemes have at least one metric that is dependent on the maximum period T . Except Boyen et al. [9] and our scheme, at least one metric is O(T ) while the key size is not constant in [9].

3) MULTI-USER SIGNATURE AGGREGATION FOR ANY TIME PERIOD
We propose a generic aggregate construction that aggregates multi-user signatures removing all restrictions on the time period and the message. While the time period and the message should be fixed [24] or the time periods should be sequential in existing schemes [21], [23], our scheme can aggregate signatures of different messages generated by multi-user in unsequential time periods. In summary, our public aggregation technique not only allows the aggregation of multi-user signatures without any constraint of the time period, and the message but maintains O(1) complexity in the signature size and the key size. Table 2 shows the aggregation possibility, the performance, and the size requirement in various forward secure aggregate signature schemes. While our scheme and MT07 can aggregate signatures in arbitrary periods, YNR12 and KO19 can aggregate signatures in consecutive periods. In addition, our scheme can aggregate signatures generated by multiple users while the other forward secure schemes can only aggregate signatures generated by a single user. YNR12 scheme can aggregate signatures by only a signer while the other schemes allow anyone to aggregate signatures.
In summary, we present a new forward secure signature methodology whose complexities are fully independent of the time period and its aggregation has high flexibility. Our new forward secure signature scheme can be utilized usefully in a decentralized environment where entities have their own time periods independently. However, we should bear zk-SNARK computation that is relatively heavier than other schemes to obtain a time period independent efficiency and the flexibility in the aggregation. Though the computation is independent VOLUME 9, 2021 of the time period and message length, it is reliant on zk-SNARK circuit size. Thus, we measure the actual performance of our signature scheme via the implementation.
We describe related works in section II. In section III, we explain preliminaries of our design and define the security notion. We demonstrate specific construction of our signature scheme in section IV. Section V presents an extension of our forward secure signature scheme to the forward secure multi-user aggregate signature. Section VI presents the security proofs of all constructions. Section VII analyzes the experiment results of our scheme. We draw a conclusion in section VIII.

II. RELATED WORK
The forward security notion is firstly introduced by Anderson [4] aiming to alleviate the damage from the key exposure problem. The forward security divides overall time periods into separate time period and utilizes a different secret key in each period. A subsequent secret key is derived from the one in the previous time period, and extracting the previous one from the current secret key is computationally hard. Because of the hardness of the extraction, a past signature cannot be fabricated even if the secret key in the current time period is exposed. Bellare and Miner [5] formalize the security notion and present the first practical forward secure signature scheme. After the formalization, many pieces of research try to improve the efficiency of forward secure signature since it is ideal that all the operations have O(1) time complexity, O(1) signature size and O(1) key size respectively. Abdalla [6] reduces the secret key size from O(l) to O(1) where l is message length while maintaining all the time complexity of operations. While Kozlov et al. [8] design a forward secure signature scheme updating a key in O(1) time complexity, it has a limitation in that its signing time complexity and verification time complexity are linear with overall time period T . Itkis and Reyzin [7] present a forward secure signature scheme whose signing and verification have the time complexity irrelevant to overall time period T while taking a trade-off in the update time. Malkin et al. [10] construct a generic forward secure signature scheme that has almost unbounded time period. Boyen et al. [9] propose the forward secure signature methodology whose signing key can be updated as an encrypted form. Kim and Oh [12] make AR [6] have the O(1) signing time complexity with adding some computations in the setup time. Despite the results of many pieces of research, any research could not reach a methodology where all operations can be conducted in O(1) time while maintaining O(1) space. In a different view, several pieces of research resolve an issue that occurs when the forward security is applied to certificate-based cryptography. Lu and Li first apply the forward security notion into certificate-based cryptography, and they propose a forward secure certificate based signature scheme without a random oracle model [36]. They solve an issue that occurs when a certificated authority is malicious [37] and propose a certificate-based key-insulated signature that improves the security in certificate-based cryptography [38].
Meanwhile, several kinds of research introduce aggregation technique to existing forward secure signature schemes to reduce the space required to store multiple signatures [21], [22]. Ma and Tsudik [20] firstly construct a forward secure aggregate signature, however, the methodology has O(T ) verification key space complexity. Although Ma [22] evolves BM [5] and AR [6] into a forward secure aggregate signature scheme that has a constant size of verification key, the scheme is ascertained insecure by Kim and Oh [21]. Yavuz et al. [23] propose the aggregation technique that can be conducted by only a single addition. However, the technique has a drawback in that the verification key size is linear with T . Kim and Oh [21] devise the aggregation technique where the verification key size is irrelevant to overall time period T . However, these techniques [21], [23] only allow the aggregation of single-user signatures whose time periods are consecutive.
We use a simulation extractable zk-SNARK [25]- [28] as a building block of signature scheme where many zk-SNARK schemes work in pairing-based environment [25], [28], [39], [40]. Gennaro et al. [41] firstly propose a non-interactive argument system where a general function is supported. Groth [40] reduces the number of verification equations from three to one and the number of elements in a proof from eight to three. Groth and Maller [25] propose a simulation extractable zk-SNARK firstly maintaining the proof size as three. However, Groth and Maller construction supports SAP (Square Arithmetic Program) representation only that incurs double size of common reference string compared with QAP (Quadratic Arithmetic Program) representation. Several researches try to develop SE-SNARK that can be represented as QAP representation. Bowe and Gabizon [26] construct QAP based SE-SNARK that has five proof elements. Lipmaa [27] reduces the proof size required in QAP representation to four, and Kim et al. [28] have three proof elements in QAP representation and a single verification equation.
We use PCD (Proof Carrying Data) as a specific building block of our construction. PCD is a special case of zk-SNARK, and the proof proves the result of verification of other proofs recursively. Chiesa and Tromer define the notion firstly [42], and Bitansky et al. [29] devise the recursive proof composition where any zk-SNARK can be used as a building block. Ben-Sasson et al. [43] enhance the practicality of the notion via using 2-cycles of pairing friendly elliptic curves. In addition, Bowe et al. [44] propose the recursive proof composition that does not require a trusted setup using Bulletproof [33] and Sonic [31] as building blocks. Chiesa et al. [45] not only grant the transparency as Bowe's construction [44] but enable the recursive proof composition to work in post-quantum environments.

III. BACKGROUND A. NOTATION
We write y ← x for substitution x on y. We write y ← S for sampling y from S if S is a set. We write y ← A(x) for a probabilistic algorithm on input x returning output y. When a probabilistic algorithm A(x) has a private input r, we denote A(x; r). We state f (λ) is negligible if f (λ) ≈ 0. We denote a concatenation as ||. Given a scheme , its all operations are denoted by .name. Let R be a relation generator that given a security parameter λ in unary returns a polynomial time decidable relation R ← R(1 λ ). We denote R λ as the set of relations that R(1 λ ) outputs. We call φ the instance and w the witness for (φ, w) ∈ R. We denote all of A's inputs and outputs for an algorithm A by trans A .

B. CRYPTOGRAPHIC ASSUMPTION
We use a hash extractability assumption [46] stated as below.
Definition 1: A hash function H is extractable for a PPT adversary A when there exists an extractor ε such that, for large enough security parameter λ and auxiliary input aux ∈ {0, 1} poly(λ) , the adversary A wins the game below with negligible probability. We The hash extraction game needs the function Check which allows the verifier to check the well-formedness of hashes received from the adversary [47].

C. SIMULATION EXTRACTABLE zk-SNARK
We adopt a simulation extractable zero-knowledge succinct non-interactive arguments of knowledge (SE-SNARK) [25] there is a PPT algorithm Check(pp, σ ) that returns 1 if ∃x such that H (pp, x) = σ and 0 otherwise. as a building block of our signature scheme. A formal definition of SE-SNARK is described as follows.
Definition 2: A zero-knowledge succinct non-interactive arguments of knowledge (zk-SNARK) for R is a set of quadruple algorithms = (Setup, Prove, Verify, SimProve) as follows.
• Setup is a PPT setup algorithm that takes as input a relation R ∈ R λ and returns a common reference string crs and a simulation trapdoor τ .
• Prove is a PPT algorithm that takes as input a common reference string crs, an instance φ and a witness w for (φ, w) ∈ R, and returns a proof π .
• Verify is a deterministic polynomial time algorithm which takes as input a common reference string crs, an instance φ and a proof π, and returns 0 (reject) or 1 (accept).
• SimProve is a PPT algorithm which takes as input a common reference string crs, a simulation trapdoor τ , and an instance φ. The algorithm returns a simulated proof π .
zk-SNARK satisfies completeness, knowledge soundness, zero-knowledge, and succinctness as described below.

1) PERFECT COMPLETENESS
Perfect completeness stipulates that a prover with a witness who is given a true statement can convince a verifier.
For all λ ∈ N, for all R ∈ R λ and for all (φ, w) ∈ R: Computational knowledge soundness states that the prover must know a witness and the witness should be extracted efficiently from a knowledge extractor. Proof of knowledge requests every adversarial prover A to generate an accepting proof, there must be an extractor χ A which outputs a valid witness taking a same input of A. Formally, we define Adv sound Arg,A,χ A is defined as follows.
An argument system Arg is considered computationally sound if for any PPT adversary adversary A, there exists a PPT extractor A wins if Verify(crs, φ, π ) = 1 and (φ, w) / ∈ R and fails otherwise.

3) PERFECT ZERO-KNOWLEDGE
Perfect zero-knowledge stipulates that a proof does not disclose any information about the witness besides the truth of the instance. The statement is certified by a simulator which cannot access a witness but has some trapdoor information that allows simulating proofs. Formally, we define Adv zk Arg, is defined as follows.
The argument system is considered perfect zero-knowledge if Adv zk Arg,A (λ) = 0 for all PPT adversaries A.

4) SIMULATION-EXTRACTABILITY
Simulation-Extractability stipulates that any adversary A who can access a simulated proof for a false instance cannot forge the proof to another proof for a false instance. In a simulation extractable zk-SNARK, the adversary cannot generate a new valid proof even if the adversary acquire proofs of other statements. Formally, we define Adv Arg,A,χ A is defined as follows. Compared to the knowledge soundness game described in Algorithm 2, the adversary can access the simulated proof via SimProve queries additionally. zk-SNARK is considered simulation extractable if there exists an extractor χ A , for any PPT adversary A, where Adv proof −ext Arg,χ A ,A (λ) ≈ 0. Proof-Carrying Data: Proof-carrying data (PCD) [42], [48] is a cryptographic primitive that guarantees the validity ∈ R and (φ, π) / ∈ Q and fails otherwise. of all previous proofs via the recursive proof composition. It is a special case of zk-SNARK where the relation R is composed of some functions that are required for the verification of other proofs. To guarantee the verification result of the other proof in the proof circuit, the instance φ includes a proof set π and inputs needed for the verification of the proof additionally. It has a proof size independent of the number the recursion, and it has O(1) verification time regardless of the number of recursion. PCD inherits all the properties of zk-SNARK such as the completeness, the knowledge soundness and zero-knowledge. The concrete proofs of these properties are described in Ben-Sasson et al.'s work [43].

D. FORWARD SECURE SIGNATURES
A forward secure signature scheme is a key evolving digital signature algorithm. All of the operations are divided into time period t and a signer signs a message using a different signing key which is issued at each time period. A key update is conducted by a one-way update function that computes a secret key for the new time period from the secret key at the current time period. A formal definition of the forward secure signature is as follows.
Definition 3: A forward secure signature is a set of four algorithms FSS = (Keygen, Update, Sign, Verify) where • Keygen takes as input a security parameter λ and returns a key pair sk 0 , vk the initial signing key and the verification key and the time period j.
• Update takes as input a secret key sk j , the time period j and returns the secret key sk j+1 and the next time period j + 1.
• Sign takes as input a message m, the secret key sk j , the time period j, the verification key vk and returns σ j that is a signature for time period j.
• Verify takes as input a message m, the time period j, the verification key vk, the signature σ and returns 1 if the σ is valid signature or 0, otherwise.
We define the security of FSS similarly to the existing works [5]- [7], [9]. The only difference is that we do not assume the maximal period anymore. Informally, an adversary who wants to succeed a valid signature forgery executes

E. FORWARD SECURE MULTI-USER AGGREGATE SIGNATURES
We extend the forward secure signature notion to a forward secure multi-user aggregate signature that supports the aggregation of multi-user signatures whose messages and time periods are different. A formal definition is as follows.
Definition 4: A forward secure multi-user aggregate signature FSMAS is a set of six algorithms by including additional algorithms in FSS. The additional algorithms are defined as follows.
• AggVerify takes as input a set (m 1 , j 1 , vk 1 ), .., (m n , j n , vk n ), the aggregate signature σ agg and returns 1 if σ agg is a valid signature or 0, otherwise. We define the security of forward secure multi-user aggregate signature similar to Algorithm 5. An adversary F can freely choose all of the user verification keys vk = (vk 1 , . . . , vk n ) except the verification key of one honest user vk * . When the adversary F is given the verification key of the honest user vk * , the adversary tries to forge an aggregate signature that involves the signature of the honest user. An adversary F can access a sign oracle and an update oracle freely, and can request break-in query also. Since the aggregation is allowed to everyone, the j 1 , vk 1 , ), . . . , (m * , b, vk * ), . . . , (m n , j n , vk n )), σ * agg ) ← F(forge, sk * j ) if AggVerify ((m 1 , j 1 , vk 1 ), . . . , (m n , j n , vk n ), σ * agg ) = 1 and vk * ∈ {vk 1 , . . . , vk n } and m * was not queried of Sign(·, b) and 0 ≤ b < j then return 1 else return 0 end if adversary does not need to request an oracle of aggregation. If the adversary outputs an aggregate signature σ * agg where AggVerify((m 1 , j 1 , vk 1 ), . . . , (m n , j n , vk n ), σ * agg ) = 1 and the aggregate signature includes the signature of m * that was not queried of Sign(·, b) and 0 ≤ b < j and vk * ∈ vk, then the adversary wins the forgery game. A formal security notion is described in Algorithm 6. Formally, we define Adv

A. MAIN IDEA
In this section, we describe a formal construction of the proposed scheme. We represent intuition of our construction first then specify details of the construction. Verification of forward secure signature [5]- [7] checks whether the signature satisfies the following properties.
• A verification key is generated from a secret signing key which is implied in the signature.
• The signing key is updated correctly corresponding to a time period.
• The signing key is connected to a correct message with the time period. While it is not easy to construct a signature scheme which satisfies the above properties simultaneously, it is more straightforward to devise a circuit to satisfy the above properties by stating them. Even if more properties are required, it is not difficult to include them in a circuit. Hence, we devise a relation circuit to efficiently represent each property in zk-SNARKs.
In key generation, a signing and verification key pair is generated with a proof which proves a connectivity between the signing key and the verification key. When the secret signing key is updated, the existing key is checked and it is updated through one-way hash function. In a sign relation, the secret key should be checked against the verification key, .verify(π j , s j , vk, crs) = 1 φ sig = H (m||j||vk) and a signature is a hash output of the message, the time period, and the verification key. When aggregation of signatures is required, a circuit checks two signatures to be aggregated and generates a single hash output from two input data.

B. FORWARD SECURE SIGNATURE CONSTRUCTION
We provide a formal construction of the proposed forward secure signature scheme. Note that we use simulation-extractable zk-SNARK as a building block in our signature scheme. We assume that a common reference string crs is hard-coded as an integer value in algorithm. Algorithm 7 describes zk-SNARK relation of update and signing process. In key generation (a time period j is set to 0), a proof that proves a correlation of the signing key and the verification key is generated. update relation describes a key generation relation and update relation. If the time period j is 0, the proof proves that the verification key vk is a hash output of signing key s j . When the signer updates the signing key (the time period j > 0), the signer proves that a verification output of π j which proves correctness of s j is 1 and an updated signing key s j is hash output of s j . As described in sign relation , the signer should prove verification of the proof π j . Then the signer proves that the committed value φ sig is a hash output of a message m, the time period j and the verification key vk.
Algorithm 8 shows an overall construction of our proposed forward secure signature. Let H be a collision-resistant hash function H : {0, 1} * → {0, 1} l where l is a bit length of hash function output. In Setup, this algorithm takes as input a relation for update R update , and relation for sign R sig . The algorithm generates all common reference strings for relations and hardcodes crs update , crs sig into the algorithms respectively.
Keygen takes a security parameter λ as input. The algorithm sets an initial secret signing key s 0 from Z p randomly and yields a verification key vk which is a hash output of concatenation of s 0 and the random value r. An initial time period j is set to 0. The algorithm computes a proof π init which proves the correctness of verification key vk based on update_relation. Keygen sets (s j , π j ) to sk j and outputs sk j , j, vk. Update takes as input a previous signing key sk j , time if .verify(π j , s j , j, vk, crs update ) = 1 then if verify(π j , s j , j, vk, crs update ) = 1 then φ sig ← H (m||j||vk) π sig ← .prove(φ sig , crs sig ; π j , s j , j, vk) else abort end if type ← 0 σ ← (π sig , φ sig , type) return σ Verify(m, j, vk, σ ) period j, and verification key vk. The algorithm verifies the proof π j that implies the correctness of signing keys in all previous periods first. If it is verified, it updates the signing key by computing a new signing key s j+1 that is a hash output of s j . Update generates a proof π j+1 for update_relation taking s j+1 , j + 1, vk as input and π j , s j , j as witness then deletes the previous signing key sk j . The algorithm outputs the updated signing key sk j+1 and the new time period j + 1.
Sign takes as input a message m, a signing key sk j , a time period j, and a verification key vk. If the proof π j which proves validity of s j on update_relation is verified, φ sig that is a hash output of m||j||vk is generated. The algorithm makes a proof π sig taking φ sig as input based on sign_relation.
And then type that reveals the type of signatures is 0. The algorithm finally outputs σ = (φ sig , π sig , type). Since the normal signature verification and the aggregate signature verification have different relations, the type of signature should be available to a verifier (and an aggregator) for efficient aggregation. Though a secret signing key is connected with a message directly in the normal signature scheme, our scheme connects a message m with the verification key vk to support aggregation of multi-user signatures.
Verify first checks the correctness of φ sig by computing H (m||j||vk). Verify calls .verify and returns b which is a verification result of π sig taking input φ sig .

V. EXTENDED CONSTRUCTION
A. FORWARD SECURE AGGREGATE SIGNATURE CONSTRUCTION Algorithm 9 represents a relation for the signature aggregation. We assume that the aggregation proceeds one by one repeatedly regardless of the signature's time period, message, and verification key. The intuitive idea of the aggregation is that a proof can be an aggregate signature if the proof proves verification of the multiple signatures. For instance, when Alice wants to aggregate Bob's two signatures which have different time periods and messages, she can aggregate two signatures by verifying signatures respectively and proving the verification process. As described in Algorithm 9, an aggregator verifies two signatures then generates a hash value that implies all the components of signatures (the message, the time period, and the verification key).
Algorithm 10 shows a whole construction of aggregation. AggSetup takes as input a relation R agg that is described in Algorithm 9, and generates a common reference string for aggregation crs agg and it is hardcoded in the algorithm. The aggregate algorithm Agg takes as input n signature sets (m 1 , j 1 , vk 1 , σ 1 ), . . . , (m n , j n , vk n , σ n ) where m i ,j i ,vk i are the message, the time period, and the verification key, respectively. The algorithm first checks the validity of φ sig i value of all σ i by computing H (m i ||j i ||vk i ) then verifies first two signatures by running .verify with crs sig . After they are verified, the algorithm generates a new signature value φ agg which is a hash output of (φ sig 1 ||φ sig 2 ). The algorithm proves Algorithm 10 Aggregation Construction AggSetup(R agg ) crs agg ← .setup(R agg ) return crs agg Agg ((m 1 , j 1 , vk 1 , σ 1 ), . . . , (m n , j n , vk n , σ n )) parse AggVerify((m 1 , j 1 , vk 1 ), . . . , (m n , j n , vk n ), σ agg ) parse σ agg as (φ agg , π agg ) the aggregation result according to algorithm 9. If more than two signatures are aggregated, the aggregator verifies the previous aggregate signature with crs agg and input signature σ i with crs sig . Similarly to the above aggregation, the aggregator generates a hash output value φ agg and proves the verification results repeatedly. The algorithm returns aggregate signature (φ agg , π agg , type) lastly.
A verification algorithm AggVerify takes n messages, time periods, verification keys and the aggregate signature σ agg . A verifier first checks the validity of φ agg in σ agg using the VOLUME 9, 2021 hash-chain computation, and verifies the aggregate signature using .verify.

VI. SECURITY PROOF
Proof Idea: We construct our signature scheme based on an extractable hash assumption described in Algorithm 1. By designing a hash extraction adversary A that utilizes a signature forgery F as a subroutine to succeed in the extraction of a hash pre-image, we prove the forward security of our signature scheme. Intuitively, the adversary A acquires a trapdoor of a proof in the setup phase and the trapdoor enables the adversary A to generate a simulated proof in the query phase. Finally, the adversary A that has a witness extractor of the proof extracts the hash pre-image from the proof where the forgery F outputs as a signature. We describe the formal security proof as follows.
Theorem 1: Let FSS be our key evolving signature scheme. Then for parameters modulus size λ, the execution time t, the common reference generation time t crs , and the number of sign queries q sig , where t = t + t crs Theorem 2: Let FSMAS be our forward secure multi-user aggregate signature scheme. Then for parameters modulus size λ, the execution time t, the common reference generation time t crs , and the number of sign queries q sig , where t = t + t crs

A. PROOF OF THEOREM 1
We construct an adversary A that conducts a hash extraction game described in Algorithm 1. The adversary A utilizes the adversary F which executes G fwsec FSS,F (λ) experiment described in Algorithm 5 as a subroutine. We suppose the adversary F succeeds with Adv fwsec FSS,F (λ) in execution time t.

1) INITIAL KEY GENERATION
The adversary A gets a hash value σ from the challenger, and then set σ to vk. The adversary runs Setup and acquires common reference strings crs update , and crs sig . Note that since the adversary has a trapdoor of the common reference string, the adversary can generate simulated proof using .SimProve. Unusually, the adversary does not need to choose an initial secret signing key s 0 , since the correctness of vk is guaranteed by a simulated proof which deceives a relation between vk and the blank input. The adversary runs subroutine F taking as input vk, crs update , and crs sig .

2) INTERACTIVE QUERY PHASE
• Update query: When F requests to update the signing key, A runs .SimProve and acquires a simulated proof on any arbitrary signing key at the queried time period.
Since the simulated proof can prove any relation of false input, A can update the signing key fraudulently.
• Sign query: A generates a signature dishonestly without the secret signing key when A receives a sign query (a message m, time period j). A sets H (m||j||vk) as φ sig and generates a simulated proof π sig . Finally A outputs a signature where σ =(π sig ,φ sig ,type) to F.
• Break-in query: A randomly chooses a secret signing key s b that is unrelated to the previous signing key and the vk. Likewise the above, relation between s b and vk is proven by simulated proof π b . A outputs current time period signing key s b and π b to F.

3) FINAL FORGERY
When F acquires a signing key s b and π b where b is the time period at break-in, F outputs forged signature (π sig * , φ sig * , type) on a new message m * where m * was not queried of Sign(·, j) and 0 ≤ j < b. After receiving the forged signature set, A runs extractor E and extracts a secret signing key s j which is a witness of π sig * . The adversary A can compute a pre-image of s b through hashing s j repeatedly.

4) SUCCESS PROBABILITY
We analyze a probability of above execution. Note that we do not need to guess the time period of break-in since all the signing keys are irrelevant to the signing key at the time period of break-in via the simulated proof. Likewise, there is no probability to fail responding the sign query because all the queries can be responded through the simulated proof. Therefore, a success probability of A converges on the success probability of extractor E completely.

B. PROOF OF THEOREM 2
A proof of Theorem 2 is almost identical to the proof of Theorem 1. The adversary F forges an aggregate signature on behalf of forging the normal forward secure signature. Thus, all the proof procedure proceeds as subsection VI-A except for the final forgery. When A is given a forged aggregate signature, A should run the extractor E recursively until the extractor outputs the sk j of signature on message m * where 0 ≤ j < b. Since the aggregate signature proves only the aggregation result, an inner proof which is a witness of the forged aggregate signature should be extracted n times in worst case (n is the number of aggregations). Thus the success probability of A converges on n where is the success probability of extractor E. Note that if the aggregation is performed balanced then n becomes O(log(N )) where N denotes the total number of signatures in an aggregate signature and the success probability is N .

VII. EXPERIMENT
In this section, we measure the performance of our forward secure signature. Basically, our forward secure signature scheme supports the aggregation of multi-user signatures regardless of their time periods, and all the efficiencies are not dependent on the time period. In particular, only zk-SNARK circuit size affects the time efficiencies of our construction, and the performance of the construction can differ depending on the zk-SNARK proof scheme. We implement the forward secure signature scheme using Plonk [32] proposed by Aztec as the zero-knowledge proof scheme [49]. We compare the performance of our signature scheme with BM [5], AR [6], IR [7], KO17 [12], and KO19 [21]. The experiment is performed on Intel i7 4.2GHz desktop with 64GB RAM under Ubuntu 18.04. Figure 2 represents the key setup time, the signing time, the update time, and the verification time of all comparative signatures by varying the total time period T . The security parameter is fixed to 2048 bits in cases of RSA-based signature schemes [5]- [7], [12], [21] and 256 bits in our case since the construction utilizes a pairing function. The message length is fixed to 160 bits in all cases.
As shown in Figure 2(a), the setup time is proportional to the total time periods T in BM, AR, and IR (optimized version). Specifically, the setup time of IROpt reaches about 2000 seconds when the total time period is 2 20 . In case of KO17, while the time complexity is O(lT ) originally, the setup is optimized by using the RSA group order in the implementation. Our scheme has 19 seconds in all time periods cases. Figure 2(b) illustrates the signing time of the signature schemes. IROpt, KO17, and our signature scheme have a constant signing time. Note that it takes 12 seconds in our scheme where the circuit size affects the signing time. Meanwhile, BM and AR have a signing time that is proportional to total time periods T in the same manner, the signing time of AR takes more than those of BM since the computation in AR is composed of exponentiation. In case of the update time, as shown in Figure 2(c), all the signature schemes have a constant update time. Like in the case of the signing time, our update time is affected by the zk-SNARK circuit size and it takes 12 seconds identical to the signing time. Figure 2(d) illustrates the verification time of all signature schemes. Only IROpt and our signature scheme have a constant verification time. On the other hand, other signature schemes have a maximum period dependent verification time. Table 3 shows detailed data of the performance when T = 2 20 , and the message bits l = 160. Table 4 represents the experiment results on the forward secure aggregate schemes. We implement forward secure aggregate schemes via applying KO19 [21] technique to BM and AR respectively. The total time period, the message bits, and the security parameter are equivalent to Table 3 and the number of signatures is two. As shown in Table 4, the aggregation time in our signature scheme has a relatively heavy computation compared with the other forward secure signatures since a large size circuit is required like 1.6M gates for the aggregation. However, the verification time of the aggregate signature is equal to the single signature  verification. In addition, the circuit is optimizable using Halo technique [44] that performs the proof verification outside the proof circuit via the proof aggregation.

VIII. CONCLUSION
In this paper, we propose a new forward secure multi-user aggregate signature using zk-SNARK. Our new forward secure signature scheme supports all constant complexities and a flexible aggregation where all restrictions that exist in previous works are eliminated. Specifically, our signature scheme has constant complexities of setup time, update time, signing time and verification time. In terms of the size, signature and key sizes are also constant. Our signature scheme supports the aggregation of multi-user signatures with all different messages and different time periods. We use zk-SNARK as a building block of the forward secure signature scheme. Through the characteristic of zk-SNARK that proves any arbitrary relation in key evolving structure, we remove time period dependent operations and aggregate multi-user signatures flexibly. The security of the proposed scheme is formally proven in the random oracle model. Our experimental results demonstrate the practicality of our signature scheme. In future, we will extend our methodology to cover more properties such as group signatures, blind signatures, etc. and improve the performance in zk-SNARK computation.
JEONGHYUK LEE received the B.S. degree in information systems engineering from Hanyang University, Seoul, South Korea, where he is currently pursuing the Ph.D. degree in information systems engineering. His current research interests focus on applied cryptography, in particular on provable security for cryptographic schemes, including protocols for public-key encryption, blockchain, and zero-knowledge proof systems.
JIHYE KIM (Member, IEEE) received the B.S. and M.S. degrees from the School of Computer Science and Engineering, Seoul National University, South Korea, in 1999 and 2003, respectively, and the Ph.D. degree in computer science from the University of California at Irvine, in 2008. She is currently an Associate Professor with the Department of Electrical Engineering, Kookmin University. Her research interests include network security, applied cryptography, and zero-knowledge proof.
HYUNOK OH (Member, IEEE) received the B.S., M.S., and Ph.D. degrees in computer engineering from Seoul National University, Seoul, South Korea, in 1996Korea, in , 1998Korea, in , and 2003, respectively. He is currently a Full Professor with the Department of Information Systems, Hanyang University, Seoul. His research interests include applied cryptography, zero-knowledge proof, and blockchain. VOLUME 9, 2021