Abstract
Aggregate signature scheme allows each signer to sign a different message and then all those signatures are aggregated into a single short signature. In contrast, multisignature scheme allows multisigners to jointly sign only one message. Aggregate multisignature scheme is a combination of both aforementioned signature schemes, where signers can choose to generate either a multisignature or an aggregate signature. This combination scheme has many concrete application scenarios such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, and so on. On the other hand, to deal with the problems of expensive certificates in certified public key cryptography and key escrow in identity-based cryptography, the notion of certificateless public key cryptography has been introduced by Riyami and Paterson at Asiacrypt’03. In this paper, we propose the first certificateless aggregate multisignature scheme that achieves the constant-size of signature and is secure in the standard model under a generalization of the Diffie-Hellman exponent assumption. In our scheme, however, the signature is generated with the help of the authority.
1. Introduction
Certificateless Cryptography. In public key cryptography, a public key is just a random number, to certify that a public key belongs to a specific user we need to provide for this public key a certificate. Public Key Infrastructure () was introduced for such purpose; however implementing such in the real world requires using a lot of resources since we need to provide, maintain, and revoke a large amount of certificates. Shamir [1] came up with an idea that if a public key is an identity of a specific user (official email address, for example), there is no need to certify this public key; this leads to the introducing of the notion of identity-based cryptography. However, since each identity is mapped to an arbitrary given fixed number, the public key is an arbitrary given fixed number. In traditional public key cryptosystems such as RSA or ElGamal, given such public key, user cannot generate the corresponding secret key. In all identity-based cryptosystems, user’s secret key is in fact generated by a private key generator () who knows the master key of the system; this leads to the fact that knows all secret keys of users in the system; this problem is so-called key escrow problem. To deal with the problems of providing, maintaining, and revoking a large amount of certificates in traditional and key escrow in identity-based cryptography, the notion of certificateless public key cryptography has been introduced by Riyami and Paterson at Asiacrypt’03 [2]. In a certificateless cryptosystem, the user’s full secret key includes two parts: the first part is a partial secret key generated by from master key and user’s identity; the second part is a secret value chosen by user himself/herself. Due to the fact that user’s public key is still associated with user’s identity and the user’s full secret key includes a secret value chosen by user himself/herself, there is no need to use certificate to certify user’s public key and does not know the user’s full secret key.
Certificateless signature scheme was first introduced in [2] and then has been deeply studied in [6–15] to name a few. Regarding the certificateless signature schemes secured in the standard model, there are currently two approaches to construct. First, using the Waters’ hash function [8, 9] or Yum-Lee generic transformations [6, 7], the advantage of this approach is that the resulting schemes can be secure under standard assumptions. However, due to using Waters’ hash function or Yum-Lee generic transformations, these schemes suffer relatively large public parameters and heavy computing time. Second, using direct approach [14, 15], which leads to quite efficient resulted schemes (constant-size of both public parameters and signature, as well as efficient computing time); however these schemes are only secure under strong assumptions (generalization of the Diffie-Hellman exponent assumption, assumption), although assumption introduced by Boneh and Boyen at Eurocrypt’05 [16] now has been accepted widely by researchers [17–22].
Aggregate Signature. Aggregate signature was first introduced by Boneh et al. at Eurocrypt’03 [23]. In this scheme, each signer in an aggregating set signs a different message and then all those signatures are aggregated into a single short signature, which is called aggregate signature. As shown in [5, 23–25], aggregate signature can be applied well to several practical applications such as Bitcoin blockchain, Secure BGP protocol (SBGP) [26], Healthcare, and so on. Certificateless aggregate signature was first proposed in [27], since then it has been studied in numerous of papers such as [5, 28–35], to name a few. However, all of these schemes either are insecure [29, 30, 35] or suffer a drawback that the signature size is linear in the number of signers in the aggregating set [5, 28, 31–34]. Moreover, all of these schemes need to use random oracle to prove the security. Very recently, the authors in [5] proposed a new certificateless aggregate scheme with short public parameters and achieving the highest level of security according to the classification given by Huang el al. [13] under a standard assumption. However, their scheme still suffers two drawbacks: the signature size is linear in the number of signers in the aggregating set and their scheme needs to use random oracle to prove the security. To our knowledge, the task of designing a certificateless aggregate signature scheme with short signature size and secured in the standard model is still open.
Multisignature. In contrast to aggregate signature, multisignature scheme allows multisigners to jointly sign only one message. This scheme was first introduced in [36], and then it has been the topic of many other works such as [25, 37–43], to name a few. At ACM CCS’01, Micali el al. [37] first formalized the security model for a multisignature scheme; they also proposed a multisignature scheme based on Schnorr-signature secured in this model. In [25], the authors defined a multisignature scheme with public key aggregation, for which all public keys of signers in the aggregating set are aggregated into a short aggregate public key through a new additional Key Aggregation algorithm. The advantage of this scheme is that the verifier can only take a constant-size of input (multisignature and aggregate public key) to verify the multisignature, which were showed in [25, 43] that this type of scheme can be applied well to the Bitcoin blockchain application. However, the downside of this scheme is that each aggregating set of signers needs to publish in advance its aggregate public key. Very recently, Boneh el al. [43] proposed a new such compact multisignature scheme with public key aggregation; their scheme however is secure in the random oracle model. Regarding the multisignature scheme in the certificateless setting, several schemes were proposed [3, 4, 44, 45]. The authors in [3] addressed the problem of fast verification but they did not give a formal security proof of their schemes. The authors in [4] proposed a certificateless multisignature scheme without using Pairings; they also gave a formal security proof for their scheme under standard assumption. All of these schemes achieve constant-size of signature; however they did not address the problem of public key aggregation and still need to use random oracle to prove the security.
1.1. Our Contribution and Organization of the Paper
In this paper, we extend the work in [14] to consider the combination of an aggregate signature scheme and a multisignature scheme, and in the context of certificateless. More precisely, in our server-aided certificateless aggregate multisignature scheme (- for short), an aggregating set of signers can choose to generate either an aggregate signature or a multisignature with the help of private key generator (); for simplicity such signature is called an aggregate multisignature. If the aggregating set of signers contains only one signer, the resulting signature is a usual signature and the signer does not need the help from .
More precisely, our - scheme has following properties:(i)the first certificateless aggregate multisignature scheme;(ii)the signature which contains four elements in all cases;(iii)being secure against strong Type I and strong Type II adversaries (according to the classification given by Huang el al. [13]) in the standard model under assumptions;(iv)server-aided scheme;(v)support public key aggregation;(vi)public key size, signing time, and verifying time which depend on the maximum number of signers for one aggregating set, which is fixed at the setup. More details can be found in the Tables 1 and 2.
Although our - scheme requires server-aid and is secure in a strong assumption ( assumption), our scheme might be considered as a partial answer for the question of designing a certificateless aggregate signature scheme which has short signature size and is secure in the standard model. In addition, our scheme is not only certificateless aggregate signature but also certificateless multisignature with public key aggregation. This type of scheme, recently showed in [25, 43], can be applied well to the Bitcoin blockchain application. We also note that the server-aided model is not new; this model has been used in many other contexts. Regarding the context of signature, we can find several other signature schemes in the literature which use the server-aid model [46–49]. Regarding the assumption, it is introduced by Boneh and Boyen at Eurocrypt’05 [16] and now has been accepted and used widely by researchers with a lot of papers based on it [50–52].
We give in Tables 1 and 2 the detailed comparison between our scheme and some latest relevant schemes in the literature.
In the Table 2, regarding noninteractive, to generate a multisignature, in [3] the first signer in the aggregating set signs the message and then sends the resulting signature to the second signer, the second signer based on this signature and his/her secret key to generate a new signature and sends this new signature to the third signer, and this process continues to the last signer. That means it needs rounds to generate a multisignature, is the size of the aggregating set. In [4], each signer needs to broadcast a value to other signers and receives values from other signers before generating multisignature as in usual noninteractive scheme [40–42]. In our scheme, in the first round, relies on the description of the aggregating set and messages to compute four elements and sends them to signers, all signers then based on these values to generate aggregate multisignature as in usual noninteractive scheme [40–42].
Regarding security model, we only consider the selective model where adversary has to declare the identity of target user at the beginning of security game; the challenger thus does not need to guess the identity of target user at the beginning of security game. In scheme [4, 5], the authors considered a more practical model, the adaptive model where adversary does not have to declare the identity of target user at the beginning of security game; however in their security proof, the challenger needs to guess in advance the identity of the target user at the beginning of security game; their schemes therefore lose a factor in the reduction to the corresponding assumptions. We also note that all of these schemes need to use random oracle to prove the security.
Paper organization. In the Preliminaries section, we present definition and security model for our - scheme, and then some useful tools for our construction. We next describe our - scheme and its security analysis in Section 3. Section 4 is devoted for the conclusion.
2. Preliminaries
In this section, based on security models in [4, 5, 13] we first define the security model for our - scheme; we then give some useful tools that we need to construct our scheme such as Bilinear Groups, Target Collision Resistant Hash Function, and Assumptions.
2.1. Server-Aided Certificateless Aggregate Multisignature Scheme
2.1.1. Definition
There are three entities involved in our server-aided certificateless aggregate multisignature scheme:(1)a designated authority acting as a Private Key Generator ;(2)user (or signer) who combines with and all other users in an aggregating set to generate an aggregate multisignature (either an aggregate signature or a multisignature). Note that if the aggregating set of users contains just one user, user relies solely on his/her full secret key (without the help of ) to generate the aggregate multisignature. In this case, the aggregate multisignature is exactly the usual user’s signature;(3)verifier who is able to check the validity of an aggregate multisignature.
We also note that, in a certificateless system, a user’s full secret key includes two parts: the first part is a partial secret key generated by the from master key and user’s identity; the second part is a secret value chosen by user himself/herself.
More formally, our - scheme consists of the following nine probabilistic algorithms.(i): it takes as input a security parameter ; this algorithm generates system parameters implicitly including the maximum number of users in an aggregating set and a master secret key .(ii)---: it takes as input , , and a user’s identity ; this algorithm generates the partial secret key .(iii)---: it takes as input the security parameter and a user’s identity ; this algorithm generates the user’s secret value .(iv)--: it takes as input ; this algorithm generates the user’s public key .(v)---: it takes as input and ; the algorithm generates the user’s full secret key .(vi) Aggregation: suppose that the aggregating set of users is . There are two cases: if contains just one user with identity , the algorithm takes as input a message , a user’s full secret key , and ; it generates a signature ; note that in this case the algorithm works as a usual signing algorithm. If contains more than one user, the algorithm now is run by and all users in , takes as input messages and the description of , and outputs an aggregate multisignature on messages . Note that the signature is called multisignature as usual if all are the same.(vii) Aggregation Verification: it takes as input an aggregate multisignature , the description of aggregating set of users , and messages and outputs either indicating that is a valid signature or indicating that is not a valid signature.
2.1.2. Adversary’s Oracles
We have two types of adversary in our - scheme, the first one represents a third party adversary (so-called Type I adversary) and the second one represents the malicious (so-called Type II adversary), and those adversary can ask the following oracles:(i): when adversary requests a partial secret key corresponding to identity , he/she should get the user’s partial secret key .(ii): when adversary requests a user’s secret value corresponding to identity , he/she should get the user’s secret value . Note that if adversary asks both and oracles on input , he/she will get the full secret key of user associated with identity .(iii): when adversary requests a public key corresponding to identity , he/she should get the user’s public key .(iv): adversary can choose and replace the original public key to a new public key by making a query to challenger.(v): when adversary requests an aggregate multisignature on messages corresponding to users with identities , he/she should get a valid aggregate multisignature corresponding to . In addition, in case , since in the algorithm the aggregate multisignature is generated by and all users in via public channel; adversary may also get the output of as well as the outputs of some users in .
Informally, a third party adversary (an outsider attacker) cannot know the master key; however he/she can replace any public key with a secret value of his/her choice. To exclude the trivial attack, he/she obviously cannot know the partial secret key of the target user. Regarding malicious (an insider attacker), this adversary knows the master key; however to exclude the trivial attack he/she cannot know the secret value or replace the public key of the target user.
On the other hand, according to the classification given by Huang el al. [13], there are three levels of adversary:(i)normal adversary: this adversary cannot ask oracle if at least one public key of a user in has been replaced;(ii)strong adversary: this adversary still can ask oracle even if all public keys of users in have been replaced;(iii)super adversary: this adversary is not required to supply the secret value when asking oracle, and he/she still can ask oracle even if all public keys of users in have been replaced;
In this paper, we consider the strong adversary for both type I and type II.
2.1.3. Security Model
We define two selective security games corresponding to two types of adversary, Game 1 corresponds to third party adversary (denote -strong Type I adversary), and Game 2 corresponds to malicious (denote -strong Type II adversary).
Our - scheme is secure if it resists both adversaries and .
Game 1. The first game is between and the challenger .
Initialization: runs the algorithm to generate a master secret key and public system parameters . keeps secret and gives to . declares the target user by sending the target identity to .
Queries: may adaptively ask the following oracles with : , , , , and . Note that .
Output: Finally, outputs (,), where , and is an aggregate multisignature on messages . We say that wins the game if the following conditions are verified: (1) and have never been queried.(2) which outputs is a valid aggregate multisignature on messages under public keys corresponding to .
Denote as the success probability that adversary wins the above game.
Game 2. The second game is between and the challenger .
Initialization: runs the algorithm to generate a master secret key and public system parameters . gives both public and to . declares the target user by sending the target identity to .
Queries: may adaptively ask the following oracles with : , , , and . Note that .
Output: Finally, outputs (,), where , and is an aggregate multisignature on messages . We say that wins the game if the following conditions are verified: (1), , and have never been queried.(2) which outputs is a valid aggregate multisignature on messages under public keys corresponding to .
Denote the success probability that adversary wins the above game.
Definition 3. We say that our server-aided certificateless aggregate multisignature scheme is selectively existentially unforgeable against polynomially bounded adversaries and if the success probabilities and are negligible, where is the security parameter.
2.2. Bilinear Groups
In this section, we recall the definition of bilinear map and three types of Pairings. Let is the security parameter, , and , , and are three finite multiplicative abelian groups of order . Suppose that are generators of and , respectively. Denote as an admissible asymmetric bilinear map, where for all (1);(2)for and , ;(3) is efficiently computable.
The tuple is then called a bilinear map group system and is in(1)Type 1 Pairings if (2)Type 2 Pairings if but there is an efficiently computable homomorphism (3)Type 3 Pairings if but there is no efficiently computable homomorphism between and
In [16], the authors introduced the generalization of the Diffie-Hellman exponent assumption in Type 3 Pairings bilinear map group system.
Assume , and are three -tuples of -variate polynomials over . Thus, , , and are just three lists containing multivariate polynomials each. We write , and impose that . For any function and vector , stands for , . We use a similar notation for the -tuples and . Let . It is said that depends on , which denotes , when there exists a linear decomposition
Let be as above and . The problem is defined as follows.
Definition 4 ( [16]). Given the tuple compute .
Definition 5 ( [16]). Given as above and decide whether .
2.3. Target Collision Resistant Hash Function
Definition 6. A target collision resistant hash function guarantees that given a random element which is from the valid domain of , a PPT adversary cannot find such that . We let be the advantage of in successfully finding collisions from a target collision resistant hash function , where DH is the valid input domain of ; is the security parameter. If a hash function is chosen from a target collision resistant hash function family, is negligible.
In this paper, for simplicity we call such target collision resistant hash function a hash function.
2.4. Assumptions
In this section, we recall one assumption and introduce a new assumption which are used to prove the security of our - scheme. Those assumptions are in the similar style of the PS assumption 1 in [52].
Definition 7. Assumption 1. Let be a bilinear group setting of type 3. Choose , we define the oracle on input that chooses a random and outputs the tuple .
Given and unlimited access to this oracle, no adversary can have nonnegligible success probability to generate a pair , with , for a new scalar not asked to .
Intuitively, when comparing to PS assumption 1 in [52], we set and the oracle outputs just two more elements in the group which offers no help for the adversary. It is thus obvious that our Assumption 1 holds and we refer the reader to [52] for details. We also note that this assumption was first introduced in [14].
Definition 8. Assumption 2. Let be a bilinear group setting of type 3, with (resp., ) being a generator of (resp., ). Choose ; we define two oracles: the oracle which is on input outputs the triplet, , ; the oracle which is on input for some set chooses a random and outputs the tuple , , , .
Given and unlimited access to both oracles and , no adversary can have nonnegligible success probability to generate a tuple , , , , with , and there exist at least one , not asked to , and input not asked to .
For completeness, we prove that our Assumption 2 holds in Bilinear Generic Group in Appendix A.
3. Our - Scheme
In this section, we first gives the detailed construction of our - scheme, then in the next section we give the security analysis of our - scheme.
3.1. Construction
The construction of our - scheme is detailed as follows.
: it takes as input the security parameter ; the algorithm generates a bilinear map group system . Next, it chooses random scalars , and is the maximum number of users in an aggregating set, as well as two hash functions where
Finally, it sets the public parameter
and the master secret key .
---: it takes as input , , and the user ’s identity ; let ; the algorithm generates a partial secret key
for user .
---: it takes as input user ’s identity ; the algorithm chooses and sets as user ’s secret value.
--: it takes as input and ; the algorithm sets as the public key of user .
---: it takes as input and ; the algorithm outputs as the full secret key of user .
: denote as the aggregating set of users, . There are two cases, if , the algorithm takes as input , , , and a message . The algorithm first chooses and computes and then outputs signature , where
If , the algorithm now is run by and all users in . More precisely, the algorithm consists of two separate following algorithms: note that :(1)First algorithm: takes as input , the description of as well as ; note that if all messages are the same, the signature is multisignatures. follows strictly the order of pair to compute as follows: Next, it chooses and computes are then sent to all users in via public channel or simply publishes it to the public domain. then is not involved in the second algorithm.(2)Second algorithm: it takes as input and runs by all users in . First, each user takes as input and computes the pair: Finally, select one user in as designated combiner, , other remaining users in send their above outputs to this designated combiner via public channel, and the aggregate multisignature is then built as follows: designated combiner takes as input and chooses and outputs the aggregate multisignature , where and . Note that the designated combiner computes: it take as input aggregate multisignature , the description of aggregating set of users , messages , and , the algorithm computes , and
note that he/she can compute from in .
Finally, the aggregate multisignature is accepted (output ) if the following equation holds:
Correctness. It is easy to show that
Multisignature Scheme with Public Key Aggregation. In [25], the authors defined a multisignature scheme with public key aggregation, for which the public keys of users in the aggregating set are aggregated into a short aggregate public key in advance through an additional Key Aggregation algorithm. The advantage of this scheme is that the verifier can only take a constant-size of input (multisignature and aggregate public key) to verify the multisignature, which were showed in [25, 43] that this type of scheme can be applied well to the Bitcoin blockchain application.
It is clear that our scheme is a multisignature scheme with public key aggregation as defined in [25], since we can add a new Key Aggregation algorithm which computes in advance the pair (, ) as an aggregate public key of the aggregating set . The verifier therefore just needs to take a constant-size of input to verify the validity of the signature. Note that we can use a short length of bits to describe the aggregating set .
Remark 9. We also note that, in our scheme, for an aggregate signature, we do not need to require that all messages are different.
3.2. Efficiency
Regarding the signature size, as in the construction and detailed in Table 1, the signature in our - scheme just contains four elements, three in the group and one in the group . If we decide to use NIST’s figures [53], then to achieve 80 bits or 128 bits of security (that means the adversary needs at least or operations to break the security of our scheme), each element in the group is about 160 bits or 256 bits and in the group is about 1024 bits or 3072 bits. This leads to the fact that the signature size of our scheme is 1504 bits or 3840 bits corresponding to the security parameter 80 bits or 128 bits, respectively.
Similarly, the user’s full secret key size of our scheme is 640 bits or 1024 bits corresponding to the security parameter 80 bits or 128 bits, respectively.
Regarding the signing phase, there are two cases:(1) = 1, the signing phase requires five exponentiations in , one exponentiation in , and two hash operations.(2), the signing phase requires exponentiations in , exponentiations in , and hash operations, where is the size of the aggregating set of signers.
Regarding the verification phase, there are also two cases:(1) = 1, the verification phase requires two exponentiations in , three Pairings, and two hash operations.(2), the verification phase requires exponentiations in , three Pairings, and hash operations, where is the size of the aggregating set of signers.
Overall, for both storage and computational complexity, our scheme can meet the requirements for a lightweight device, that means our scheme is suitable for resource-constrained applications such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, vehicular ad hoc networks, wireless sensor networks, Internet of Things, and so on.
3.3. Security
We give in this section two theorems which show that our - scheme is secure.
3.3.1. Secure against Strong Type I Adversary
We first prove that our - scheme is secure against strong Type I adversary.
Theorem 10. If there exists a strong Type I adversary defined in Game 1 (see Section 2.1.3), who breaks the security of our - scheme with probability , then there exists an adversary who can break the security of the Assumption 2 with the same probability .
Proof. Suppose that is an adversary against our Assumption 2; we let act as a challenger in Game 1 (see Section 2.1.3), that means simulates and then uses the output of to break the security of the Assumption 2.
At the beginning, has an instance of Assumption 2: , , , , , , , as well as the right to access two oracles and . Note that, for oracle , on input , output the triplet , , . For oracle , on input , choose a random and output , , , .
Note that does not know the values , , and .
To simulate , first receives from the target identity for which he/she intends to attack.
chooses two hash functions whereand then gives , , , , , , to as public parameters.
To simulate , must manage to answer oracles as follows.
. simply requests oracle on input and directly forwards the result to . Note that, following Game 1 (see Section 2.1.3), cannot make query on .
. chooses and gives to .
. first checks whether the has been queried before; if it is not the case first make this query on itself, using the above descriptions. In both cases, knows ; thus gives to .
. knows and then simply sets .
. computes , and , then requests oracle on input to get the tuple:Since knows (even if has been replaced), he/she can easily compute the aggregate multisignature as the algorithm and returns to .
We also note here that, in our algorithm, the output of and the outputs of users who are not designated combiner are sent via public channel (or made public), that means can request to know these outputs.
Note that the output of isand the output of each user in isfor some . However, since knows and all , can easily answer by choosing and implicitly sets .
Finally, outputs a tuple , , for which has never been queried; note that .
From , where, is computed as in algorithm, and knows all ; it is easy for to recover the tupleSince has never been queried, has never been asked to and also has never been asked to . This leads to the fact that is a valid tuple to break the security of the Assumption 2.
Since the simulation is perfect, this leads to the fact that if there exists an adversary who can break the security of our scheme with success probability , then there exists an attacker who can solve the Assumption 2 with the same success probability , which concludes our proof.
3.3.2. Secure against Strong Type II Adversary
In this section, we prove that our - scheme is secure against strong Type II adversary.
Theorem 11. If there exists an adversary defined in Game 2 (see Section 2.1.3), who breaks the security of our - scheme with probability , then there exists an adversary who can break the security of the Assumption 1 with the same probability .
Proof. Suppose that is an adversary against Assumption 1; we let act as a challenger in Game 2 (see Section 2.1.3), that means simulates and then uses the output of to break the security of the Assumption 1.
At the beginning, has the instance of assumption: as well as the right to access oracle . Note that for oracle , on input , output the tuple , , .
Note that does not know the values and .
To simulate , first receives from the target identity for which he/she intends to attack. chooses and two hash functions whereNext, implicitly sets and then gives , , , , , , to as public parameters.
To simulate , must manage to answer oracles as follows.
. If , chooses and returns to . If , implicitly sets and returns to . Note that, in this case, does not know .
. checks whether has been queried before, if it is not the case first makes this query on itself, using the above description. In both cases, knows and return to . Note that follow the definition of security model, cannot make query on the case .
. knows and then simply sets . Note that, following the definition of security model, cannot make query on the case .
. computes , and .
There are two cases, if then knows all information; thus he/she chooses and easily computes the aggregate multisignature , whereand . Finally, returns to .
In case , does not knows ; that means cannot know ; he/she therefore cannot compute . In this case, requests oracle on input to receive the tuple (note that ):Since knows (even if corresponding public keys have been replaced) and , he/she can easily computeandwhere . Finally, returns to .
We also note here that, in our algorithm, only runs the first algorithm and does not participate in the second algorithm; that means knows the output of , which is for some . On the other hand, since in algorithm, users who are not designated combiner send their outputs to designated combiner via public channel, that means can know these outputs, which are pairs:To answer , first implicitly sets user with identity as designated combiner. Since knows , he/she can choose and easily answer .
Finally, outputs a tuple , , for which has never been queried; note that .
From , where, and is computed as in algorithm.
Since knows and all , he/she computeswhere ; next he/she computesFinally, can have the pairSince has never been queried, has never been asked to ; this leads to the fact that is a valid pair to break the security of the Assumption 1. Note that .
Since the simulation is perfect, this leads to the fact that if there exists an adversary who can break the security of our scheme with success probability , then there exists an attacker who can solve the Assumption 1 with the same success probability , which concludes our proof.
4. Conclusion
Aggregate signature and multisignature have many practical applications such as Bitcoin blockchain, Healthcare, Multicast Acknowledgment Aggregation, and so on, while certificateless is an interesting technique to avoid the use of expensive certificate in and key escrow problem in identity-based cryptography. In this paper, we consider the combination of an aggregate signature scheme and a multisignature scheme in the certificateless setting. We concretely propose the first server-aided certificateless aggregate multisignature scheme which achieves the following properties:(i)the signature contains four elements in all cases. When using NIST’s figures [53], the signature size of our scheme is 1504 bits or 3840 bits corresponding to the security parameter 80 bits or 128 bits, respectively. The user’s full secret key size is 640 bits or 1024 bits corresponding to the security parameter 80 bits or 128 bits, respectively;(ii)it is secure against strong Type I and strong Type II adversaries in the standard model under assumptions;(iii)support public key aggregation;(iv)public key size, signing time, and verifying time depend on the maximum number of signers for one aggregating set, which is fixed at the setup.
Appendix
A. Proof of Assumption 2 in Bilinear Generic Group
Let be the maximum number of queries that the adversary can ask each oracle and oracle . The input for which can have comes from asking oracles , and . We can write that input as follows.
Regarding the input in the group , hasRegarding the input in the group , has where .
To prove the security of the assumption, we will show that, simultaneously from , cannot lead to and from , cannot lead to the triplet
We assume that find linear combinations of elements in which lead to the triplet denote these linear combinations which lead to , respectively. It is easy to see that
Regarding the first equation, since in , the highest degree of variables is and are unknown random constants; in we cannot have elements
Regarding the second equation, since in , the degree of variables is and are unknown random constants; in , we cannot have elements
Overall, in , we only can have elements
that means has to find constants to produce :
Similarly, suppose that finds the linear combination of elements in (denote ) which leads to ; we have
It is obvious that cannot contain the elements ; that means needs to find the constants such that the following equation holds:
From above equation, since are unknown, there are two cases:(1)if there exists at least one , to cancel out , it is obvious that . We thus can rewrite the above equation as Since , and unknown , it is obvious to deduce that cannot find the constants to make the above equation hold.(2)if for all , then to cancel out we have all . The equation now is rewritten as It is obvious that, to cancel out , . On the other hand, since , that means contains only ; we can again rewrite the equation as Since all identities are different, it is obvious that cannot find the constants to make the above equation hold.
The above two cases conclude our proof.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This paper was written while the author was visiting the Vietnam Institute of Mathematics for Advanced Study in Mathematics (VIASM). He is grateful for the VIASM for its support and hospitality. This work was conducted within the context of the Vietnamese Nafosted Project "Some Advanced Encryption Schemes for Lightweight Devices".