Abstract
Identity-based multi-proxy signatures (IBMPS) enable an original signer to delegate signing authority to multiple proxy signers, who jointly sign a common message on the original signer’s behalf using their identity-associated private keys. This supports authenticated collaborative reporting in unmanned aerial vehicle (UAV)-assisted rescue. We propose an IBMPS scheme for this application and a security model that captures adaptive queries and signer collusion. Under the computational Diffie–Hellman (CDH) assumption and the collision resistance of and , we prove unforgeability for the three forgery scenarios of Game 1 in the standard model (SM), with explicit reduction bounds and no public-key replacement. We also analyze long-term private-key recovery under proxy signing-key exposure, assuming an honestly generated target public key that remains unchanged. The scheme verifies individual partial signatures before aggregation, while final verification requires a constant number of pairings and scalar multiplications; signer-list processing still depends on group size. Under historical benchmark timings and the adopted operation counts, with ten proxy signers, the estimated total computational cost is 19.34–44.00% lower than that of five of the six baseline schemes, and the estimated final verification cost is 50.26–74.06% lower than that of all six. Under the adopted encoding assumptions, the 20-byte long-term private-key representation is the smallest among the compared schemes, the 276-byte per-proxy delegation ties for the smallest, and the 532-byte final signature matches that of Shin et al.’s scheme. The cost figures are model-based estimates, and the byte counts are per-object representation sizes rather than complete end-to-end communication costs.
1. Introduction
Natural disasters continue to cause substantial loss of life and extensive property damage worldwide. The severe floods in Central Africa and wildfires in the Amazon rainforest in 2019, together with the extreme heatwaves in North America in 2021, underscore the importance of timely disaster assessment and effective emergency response. Unmanned aerial vehicles (UAVs) are increasingly deployed to collect information from disaster-affected areas and support search-and-rescue operations. Depending on their platforms and payloads, UAVs offer advantages such as rapid deployment, wide-area coverage, nighttime operation, precise delivery of emergency supplies, and relatively low operating costs. These capabilities make UAVs valuable tools for disaster assessment and rescue coordination [1,2,3,4].
In UAV-assisted rescue missions, the ground control center relies on timely and authenticated reports about disaster locations and people in distress to inform operational decisions. An identity-based multi-proxy signature (IBMPS) scheme supports this requirement by allowing a designated group of UAVs to jointly sign a common report under signing authority delegated by a rescue commander.
Figure 1 illustrates this workflow. The rescue commander first prepares a warrant w specifying the mission identifier, the identities of all authorized UAVs, the mission objectives, the geographical scope, the authorization validity period, and the reporting requirements. The commander then generates a delegation that binds w to the ordered public-key list L of the designated UAVs and distributes the delegation and L to the authorized group.
Figure 1.
Application of IBMPS to UAV-assisted forest fire response.
Each designated UAV collects observations within the scope specified by w. To jointly endorse an incident report, the UAVs sign a common message m containing the mission identifier, the incident identifier, the incident location, the observation period, and a shared statement describing the incident. The signing procedure assumes that all designated UAVs have obtained the same encoded report m; report formation and distribution are outside the scope of the signature construction. Before signing, each UAV independently determines whether its observations support the report’s statement and whether the report satisfies the mission, geographical, temporal, and reporting constraints specified in w. Only when both conditions are satisfied does the UAV participate in the prescribed signing exchanges and generate a partial proxy signature on m.
A coordinating UAV, referred to as the clerk, collects and verifies the partial proxy signatures. The clerk belongs to the authorized group and also contributes its own partial proxy signature. After obtaining valid partial proxy signatures from all designated UAVs, the clerk aggregates them into a final multi-proxy signature and forwards the signed report to the ground control center. The center checks the report’s compliance with w, confirms that the declared UAV identities match those specified in the warrant, and verifies the multi-proxy signature using the corresponding public information. Acceptance provides authenticated evidence that the authorized group has jointly endorsed the report, thereby supporting disaster assessment and rescue decisions.
This workflow requires authentication of both the UAVs’ joint endorsement and the commander’s delegation of signing authority for the specified mission. Conventional digital signatures authenticate reports signed by individual UAVs, whereas aggregate signatures combine multiple signatures into a compact representation for aggregate verification. The unforgeability guarantees of an aggregate signature scheme depend on its underlying assumptions and the conditions imposed by its security model, including any key-registration requirements. Signature aggregation alone, however, does not establish that the rescue commander has authorized the participating UAVs to endorse reports for a particular mission within a specified validity period. An aggregate-signature-based solution therefore requires an additional mechanism to establish and verify this authorization.
IBMPS incorporates explicit delegation into the joint signing process, allowing the designated UAVs to collectively sign a common rescue report under the commander’s warrant. By verifying the resulting signature and checking the report and designated signer group against the warrant, the ground control center can authenticate the group’s joint endorsement under the specified delegation. This integration of delegated signing authority and joint report authentication motivates the use of IBMPS in UAV-assisted rescue missions.
1.1. Related Work
Proxy signatures (PS), introduced by Mambo et al. [5], allow an original signer to delegate signing authority to a proxy signer, who subsequently signs on the original signer’s behalf. Boldyreva et al. [6] established formal security foundations for this primitive by defining security requirements and presenting provably secure constructions. Malkin et al. [7] explored the relationship between proxy signatures and key-evolving signatures and developed a framework for hierarchical delegation. Schuldt et al. [8] extended the security treatment to explicitly address proxy signing-key exposure, emphasizing the need to distinguish the compromise of delegated signing keys from that of long-term private keys.
Subsequent research adapted proxy signatures to various cryptographic settings and delegation requirements. Zhang and Kim [9] developed identity-based blind and proxy signature constructions using bilinear pairings, while Lin and Jan [10] combined delegated signing with the blindness property to construct proxy blind signatures. Other extensions addressed revocation in multi-proxy signatures [11], proxy multi-signatures [12], and threshold proxy signatures [13,14,15]. These studies broadened the functionality of delegated signing to accommodate different authorization structures and operational requirements.
Multi-proxy signatures (MPS) extend signing delegation from an individual proxy to a group of cooperating proxy signers. Hwang and Shi [16] introduced a construction in which an original signer authorizes a proxy group to jointly sign on the original signer’s behalf without disclosing the original signer’s private key. Lee et al. [17] analyzed attacks against existing proxy signature schemes, developed stronger security classifications and constructions, and discussed applications to multiparty delegation. In a separate line of research, Qin et al. [18] investigated quantum multi-proxy signatures, which rely on quantum resources and signing mechanisms distinct from those of classical constructions.
Within the identity-based setting, Li and Chen [19] proposed pairing-based multi-proxy signature constructions and related variants. Their work demonstrated the integration of identity-based cryptography with collaborative delegation, although the security analysis did not include a formal reduction proof. Xu et al. [20] subsequently proposed an identity-based multi-proxy sequential signature scheme in which proxy signers contribute in a prescribed order. This construction supported sequential collaboration but also lacked a formal security proof. Cao and Cao [21] advanced the formal treatment of identity-based multi-proxy signatures (IBMPS) by defining a security model and presenting a construction with a security proof. However, Xiong et al. [22] later identified a forgery vulnerability in that construction and proposed a modification. This finding underscores the importance of distinguishing ordinary signatures from delegated signatures and accounting for their interaction in both scheme design and security analysis.
In parallel, Jin and Wen [23] introduced a certificateless multi-proxy signature (CLMPS) scheme with a formal security model capturing different adversarial capabilities. They analyzed its security under the computational Diffie–Hellman (CDH) assumption in the random oracle model (ROM). Although certificateless cryptography addresses the key-escrow issue inherent in identity-based systems, it introduces different key-management requirements and security assumptions. In the identity-based setting, Gu et al. [24] proposed an IBMPS construction in the standard model (SM), with a security framework covering self-proxy signing and proxy signing-key exposure. Its signature size and verification cost, however, grow linearly with the number of proxy signers, increasing the overhead for larger signing groups.
More recent work has emphasized computational efficiency and applications involving resource-constrained devices. Chen et al. [25] proposed an efficient IBMPS scheme with a security proof in the ROM. As noted by Shin et al. [26], the scheme generates partial signatures directly from long-term private keys and delegation information, without a separate randomized proxy signing-key generation procedure. This design raises further questions about the role of dedicated proxy signing keys in balancing signing efficiency and protection of long-term private keys.
Shin et al. [26] developed an IBMPS scheme for the Internet of Drones that incorporates randomized partial proxy signing keys. Each such key combines the proxy signer’s private key, the original signer’s delegation, and fresh randomness. Their construction supports partial signature verification and compact aggregation, and its security analysis accommodates proxy signing-key queries under the CDH assumption in the ROM. They also proposed an online/offline variant and evaluated computation time and energy consumption on a Raspberry Pi drone platform. Their surveillance and rescue scenarios demonstrate the practical relevance of delegated collaborative signing in UAV networks. Accordingly, randomized partial proxy signing keys, partial signature verification, compact aggregation, and UAV rescue applications constitute established capabilities on which subsequent IBMPS constructions can build.
The existing literature motivates further investigation of the trade-offs among delegation binding, proxy signing-key protection, security proof models, and computational efficiency. ROM proofs idealize hash functions as random oracles, whereas SM proofs avoid this idealization; this distinction alone does not establish that a ROM-based construction is insecure in practice. Taking Shin et al.’s scheme as the primary reference, our construction retains randomized proxy signing-key generation, partial signature verification, and compact aggregation while modifying the long-term key representation, the group-valued hash construction, and the binding of authorization context. Specifically, it uses an identity-associated private scalar together with an auxiliary public value, adopts Waters-style structured hashing based on collision-resistant hash functions, and binds delegation and report signing to the relevant mission and signer information. We refine the security model to account for signer collusion, proxy signing-key exposure, and released partial signatures. We establish a separate CDH-based reduction for each of the three forgery scenarios in Game 1, with explicit success-probability bounds and no public-key replacement. Finally, we estimate computational costs using a historical operation benchmark and compare the representation sizes of private keys, delegations, and signatures. These evaluations do not establish equivalent contemporary security levels or complete end-to-end communication costs.
1.2. Our Contributions
UAV-assisted rescue requires a designated group of UAVs to jointly endorse a common report under a commander’s mission-specific authorization. Meeting this requirement entails authenticating the participating UAVs, binding the delegation to the mission and designated signer group, and verifying their joint endorsement of the report. Building on the IBMPS scheme of Shin et al. [26], we retain randomized proxy signing-key generation, partial signature verification, and compact aggregation, while modifying the long-term key representation, hash construction, and authorization-context binding. Our main contributions are summarized as follows:
- Mission- and Group-Bound Delegation. We define a warrant w that specifies the mission identifier, authorized UAV identities, mission objectives, geographical scope, validity period, and reporting requirements. Whereas Shin et al. [26] use the delegation hash , our construction computesincorporating the original signer’s identity, auxiliary public value, and the ordered public-key list L of the designated UAVs. This binds the delegation to both the mission warrant and the selected proxy group. Before signing, each UAV checks the report against the warrant; before accepting the signed report, the ground control center checks report compliance and signer-group consistency. Together, these cryptographic bindings and application-level checks support reporting within the specified authorization scope.
- Scalar-Based Long-Term Keys and Conditional Key-Recovery Analysis. In contrast to the group-element representation of long-term private keys in Shin et al. [26], our construction uses an identity-associated private scalar together with an auxiliary public value. The corresponding private-key contribution to delegation and proxy-key generation takes the form . After verifying the delegation, each UAV derives its partial proxy signing key by combining the delegation, its private-key contribution, and fresh randomness:This formulation preserves randomized proxy-key generation while allowing subsequent partial signature generation to use the derived proxy signing key. We also analyze long-term private-key recovery under the specified proxy-key exposure conditions. Recovering the target user’s private scalar yields a solution to CDH, provided that the target public key is honestly generated and remains unchanged.
- Verifiable Aggregation with Authorization-Context Binding. We retain the partial signature verification and compact aggregation supported by Shin et al. [26], while extending the hash inputs used for report signing. Instead of , all designated UAVs use the common valuewhich incorporates the report, warrant, original signer’s information, and aggregate proxy-key public value into the signing context. The coordinating UAV verifies each partial signature and rejects invalid contributions before aggregation. Once valid contributions from all designated UAVs have been obtained, they are combined into a final signature containing four group elements and the warrant, with the same representation size as the signature of Shin et al. Final verification requires a fixed number of pairings and scalar multiplications, although signer-list processing remains dependent on group size. The construction requires contributions from every designated UAV and does not provide threshold signing.
- Explicit Collusion Modeling and Standard-Model Reductions. Whereas Shin et al. [26] analyze security in the random oracle model, our analysis employs Waters-style group-valued hash functions defined by public parameters, together with collision-resistant hashing, in the standard model. We refine the security model to distinguish delegation forgery, forgery of an honest proxy’s participation by a malicious original signer colluding with the remaining proxies, and forgery of the original signer’s authorization by all colluding proxies. The model also tracks proxy signing-key exposure and releases partial signatures to define the freshness requirements for a valid forgery. We establish a separate CDH-based reduction for each forgery scenario in Game 1, which excludes public-key replacement. The reductions explicitly account for adaptive query simulation, target-identity guessing, coefficient events, and negligible collision-related loss.
- Model-Based Evaluation of Computational Costs and Representation Sizes. We evaluate the computational costs of delegation, proxy-key generation, signing, and final verification, as well as the representation sizes of private keys, delegations, and final signatures. Under the adopted operation counts and historical benchmark timings, the estimated total computational cost with ten proxy signers is 19.34–44.00% lower than that of five of the six comparison schemes; the estimated final verification cost is 50.26–74.06% lower than that of the six schemes. Relative to Shin et al. [26], the corresponding estimated differences are 26.16% and 68.80%. Under the adopted encoding assumptions, the long-term private-key representation is 20 bytes, compared with 128 bytes in Shin et al.’s scheme [26]; the delegation and final signature representations are 276 bytes and 532 bytes, respectively. These are model-based comparisons, not implementation measurements or comparisons at verified equivalent contemporary security levels.
1.3. Organization
The remainder of this paper is organized as follows. Section 2 introduces the preliminary concepts required for the subsequent discussion. Section 3 presents the system model of the proposed scheme. Section 4 formalizes the corresponding security model. Section 5 describes the detailed construction of the proposed scheme. Section 6 provides the security proofs. Section 7 compares the proposed scheme with representative multi-proxy signature schemes in terms of security-related features, estimated computational costs, and key, delegation, and signature sizes. Finally, Section 8 summarizes the paper and draws the main conclusions.
2. Preliminaries
Let be an additive group of prime order q, and let be a multiplicative cyclic group of the same order. Let and denote the identity elements of and , respectively. Consider a map satisfying the following properties:
Non-degeneracy: There exist such that .
Efficient computability: The value can be computed efficiently for all .
Bilinearity: For all and , .
- Computational Diffie–Hellman (CDH) problem: Given a generator P of and the elements and , where are unknown, compute .
- CDH assumption: No probabilistic polynomial-time algorithm solves the CDH problem with non-negligible probability.
A hash function family consists of a probabilistic polynomial-time index generation algorithm and a deterministic polynomial-time evaluation algorithm . Given a security parameter , outputs a public index s that defines a function
where is the finite output space associated with s. The evaluation time is polynomial in and the input length.
The family H is collision resistant if, for every probabilistic polynomial-time adversary given s, the probability of finding distinct inputs such that is negligible in . This probability is taken over the randomness of both the index generation algorithm and the adversary.
The index s is public and is not a secret key. Once s is fixed, the hash evaluation is deterministic. In the standard model, hash functions are evaluated according to their public descriptions rather than modeled as random oracles.
3. The System Model of IBMPS
To facilitate understanding of the proposed scheme, Table 1 summarizes the principal notation used throughout this paper.
Table 1.
Notation and descriptions.
The proposed IBMPS system comprises five functional roles: a private key generator (PKG), an original signer (OS), a group of proxy signers , a clerk, and a verifier. In the UAV-assisted rescue scenario considered in this paper, the PKG serves as a trusted key-management authority, the OS represents the rescue commander, and the proxy signers correspond to the UAVs assigned to the mission. The clerk is a coordinating UAV , where , selected from the proxy signer group and also acting as a proxy signer. The verifier represents the ground control center. Figure 2 illustrates the system architecture, and the responsibilities of each role are described below.
Figure 2.
System architecture of the proposed IBMPS scheme.
PKG: The PKG generates the system parameters and issues identity-associated private keys, together with the corresponding auxiliary public values, to the original signer and the proxy signers.
OS:The rescue commander OS specifies the mission identifier, the identities of all authorized UAVs, the mission objectives, the geographical scope, the authorization validity period, and the reporting requirements in a warrant w. Using its private key, the OS generates a delegation bound to the designated proxy public-key list L. It then distributes the delegation and L to the authorized UAV group.
: Each authorized UAV verifies the received delegation and derives its partial proxy signing key from the delegation and its own private key. The UAV conducts observations within the authorized scope and assesses a common rescue report m, which specifies the mission identifier, the incident identifier, the incident location, the observation period, and a common incident statement. These five fields constitute the report m and are encoded in a fixed order using a canonical, unambiguous encoding. The mission identifier in m must match that specified in w. Each designated UAV participates in signing only if its observations support the statement and the report satisfies the constraints specified in w. It then completes the required signing exchanges, generates a partial proxy signature on m, and submits the resulting contribution to the clerk.
Clerk: The clerk is a coordinating UAV selected from the proxy signer group. It participates in observation, report assessment, and signature generation. It additionally collects and verifies the partial proxy signatures on m. Once valid contributions have been obtained from all designated UAVs, including itself, the clerk constructs the final multi-proxy signature and forwards it, together with the report, to the ground control center.
Verifier: The ground control center checks that m satisfies the constraints specified in w and that the declared proxy identities and their corresponding public values match the authorized group. It then verifies the multi-proxy signature using the required public information. If all checks succeed, the report is accepted as jointly endorsed by the authorized UAV group and used to support rescue assessment and response decisions.
The proposed IBMPS scheme is defined by the following seven algorithms.
- Setup (): Executed by the PKG, this algorithm takes a security parameter as input and generates the public system parameters and the master secret key . The PKG publishes the system parameters and keeps secret.
- PriK-Extract (params,mk, ): Executed by the PKG, this algorithm takes the system parameters , the master secret key , and a user identity as input. It generates the corresponding private key and the corresponding auxiliary public value . The PKG delivers through a secure channel and provides to the user.
- PubK-Generate (, ): This algorithm takes a user identity and the corresponding auxiliary public value as input. The user sets its public key to .
- Dele-Generate (params,w, ): Executed by the OS, this algorithm generates a delegation for a designated group of proxy signers. Before executing the algorithm, the OS constructs a warrant w specifying the mission identifier, the identities of all authorized proxy signers, the mission objectives, the geographical scope, the authorization validity period, and the reporting requirements. It also determines the ordered public-key list , where . The algorithm takes , w, the original signer’s identity , public key , and private key , together with L, as input. It outputs the delegation , which the OS distributes alongside L to the designated proxy signers. Whenever L is included in a hash input, its entries follow the order of the corresponding proxy identities listed in w and are represented using a fixed, unambiguous encoding.
- ProK-Generate (, , , , , , , ): This algorithm is executed by each proxy signer . It takes as input , the delegation , the original signer’s identity and public key , the proxy public-key list L, and the proxy signer’s own identity , public key , and private key . Before verifying the delegation, first checks whether its own identity belongs to the proxy group specified by w, and confirms that its own public key matches the corresponding entry in L. If either condition is not satisfied, it outputs ⊥ and terminates. Then, verifies the delegation . After successful verification, derives its partial proxy signing key , and simultaneously generates and broadcasts the public value . The partial proxy signing key is kept secret by and is used to participate in the joint generation of multi-proxy signatures under the authorization specified in w; is a public value used in partial signature verification and in computing . The algorithm outputs , or ⊥ on failure.
- MP-Sign : This distributed signing algorithm is jointly executed by the designated proxy signers, with acting as the clerk. The collection denotes the signers’ respective local secret inputs. The algorithm consists of two stages: (1) Partial signature generation. Each proxy signer takes as input the system parameters , the report m, the delegation , the original signer’s identity and public key , the designated proxy group’s public information, and its own partial proxy signing key and the public values generated during ProK-Generate. For , evaluates the common rescue report m, which contains the mission identifier, the incident identifier, the incident location, the observation period, and a common incident statement. Only when verifies that m satisfies the constraints specified in w does participate in the signing. It then outputs a partial proxy signature and transmits it to a designated proxy signer , who serves as the clerk to aggregate the signatures. (2) Signature aggregation. The clerk collects and verifies the n partial proxy signatures from all proxy signers, and outputs the multi-proxy signature on m.
- MP-Verify : Executed by the verifier, this algorithm takes the system parameters , the report m, the multi-proxy signature , the original signer’s identity and the public key , the identities of the proxy signers , and their public keys as input. The verifier first extracts the warrant w from and checks whether m satisfies its constraints. It checks that the supplied proxy identities correspond one-to-one to those specified in w, constructs the ordered public-key list L from the corresponding supplied public keys, and uses this list to compute for aggregate signature verification. Finally, it verifies whether is a valid multi-proxy signature on m, generated under w by the designated proxy signer group on behalf of the OS. The algorithm accepts if all checks succeed and rejects otherwise.
4. Security Model
The IBMPS system comprises one original signer and n proxy signers. We consider both collusion among proxy signers and collusion between the original signer and a subset of the proxy signers. The adversary is allowed to adaptively corrupt participants and obtain their long-term private keys. For a target forgery, may corrupt at most n of the participants, subject to the requirement that at least one participant whose authorization or signature is being forged remains uncorrupted.
We denote the identity of such a participant by . This requirement rules out the trivial case in which obtains all long-term private keys needed to generate the target delegation or signature directly. Game 1 imposes additional restrictions on proxy signing-key queries and signing queries to exclude trivial forgeries derived from keys or signatures obtained through these queries.
The identity is determined by the adversary’s final forgery and need not be fixed before the interaction. Depending on the forgery scenario, corresponds to either the original signer or a proxy signer. Under this adversarial model, we distinguish the following three forgery scenarios.
- Delegation forgery. The adversary impersonates an honest original signer with identity and produces a valid delegation , although the original signer has not authorized the designated proxy group under . The adversary may have obtained delegations from the same original signer for other warrants or proxy groups.
- Signature forgery without an honest proxy signer’s participation. A malicious original signer colludes with corrupted proxy signers to produce a valid multi-proxy signatureon a report . The signature purports to represent the participation of all n designated proxy signers, although the remaining honest proxy signer, with identity , has not signed under the target authorization. The adversary has not obtained this signer’s long-term private key or its partial proxy signing key for the target authorization. It may, however, have requested signatures from the honest signer on other reports.
- Signature forgery without the original signer’s authorization. The adversary corrupts all n proxy signers and produces a valid multi-proxy signature on a report under a warrant , although the honest original signer, with identity , has not authorized the designated proxy group under . Delegations obtained from this original signer for other warrants or proxy groups do not constitute authorization for the target signature.
Game 1. We formalize the above forgery scenarios through the following game between a challenger and a probabilistic polynomial-time adversary . An overview of the game is provided in Figure 3.
Figure 3.
Overview of Game 1.
Setup phase. The challenger runs the Setup algorithm to generate the public system parameters and the master secret key . It gives to and keeps secret.
Query phase. The adversary may adaptively issue a polynomial number of the queries defined below. When a query involves an identity that has not yet been registered, the challenger generates the corresponding key pair once, using PriK-Extract and PubK-Generate, and stores it for subsequent queries. The challenger’s internal use of a private key does not constitute disclosure of that key to . Each identity is associated with a single public key generated by the challenger. Public-key replacement is not allowed in this game. The challenger maintains the following lists, all initially empty:
- stores tuples , where is the key pair originally issued to .
- stores tuples , where is the registered public key associated with and is initially set to .
- records each identity for which has been returned to .
- stores tuples for delegations returned to , where is the delegation on w.
- stores tuples , where is the generated partial proxy signing key of , and is its corresponding public value.
- stores tuples for partial proxy signing keys returned to through .
- stores a tuple for each multi-proxy signature returned to . It also stores a tuple for each partial signature released by an honest proxy signer. Both signature forms include the warrant w, which identifies the designated proxy signers.
In the reduction, additionally maintains a reduction-only list for proxy signing keys represented implicitly during signing-query simulations. Each entry records
where and are the proxy signer’s random scalar and corresponding public value. The corresponding is not stored because cannot compute it explicitly. Entries in are internal simulation state: they are not returned to and are not recorded in .
Public-key query . On receiving an identity , the challenger returns its current public key from . Initially, , where is generated during private key extraction.
Private-key query . On receiving an identity , the challenger returns the registered private key from and records in if it is not yet recorded.
Delegation query . The adversary submits the warrant w, the original signer’s identity and public key , and the public-key list L of all designated proxy signers. The challenger checks that the supplied public keys match the current public keys of their corresponding identities and that L is consistent with the proxy group specified in w. If either check fails, it returns ⊥. Otherwise, it uses the corresponding original signer’s private key internally to run Dele-Generate. The challenger returns the delegation together with L and records in .
Proxy signing-key query . The adversary submits a delegation , the original signer’s identity and public key , a proxy signer’s identity and public key , and the designated proxy public-key list L. The challenger verifies the delegation, checks the supplied public keys, and confirms that belongs to the proxy group specified in w. If any check fails, it returns ⊥. Otherwise, the challenger proceeds as follows:
- (1)
- If contains an entry matching the delegation, the original signer, the proxy signer, and the designated proxy group, including their public keys, the challenger retrieves the stored and .
- (2)
- Otherwise, the challenger uses the corresponding private key internally to run ProK-Generate and obtains . It stores these values, together with the associated delegation, identities, and public keys, in .
- (3)
- The challenger returns to the adversary and records the corresponding key exposure in . Its internal use of does not constitute disclosure of that private key.
Multi-proxy signing query . The challenger verifies the delegation, checks that m satisfies the conditions in w, and confirms that the supplied public keys match and the designated proxy group. If any check fails, it returns ⊥. Otherwise, it carries out the following steps:
- (1)
- Partial signature generation. For each proxy signer , the challenger retrieves a matching partial proxy signing key from . If no matching entry exists, it obtains from , runs ProK-Generate internally, and stores the resulting key and public value in .The challenger then performs the partial signing steps of MP-Sign, ensuring that all participating signers use the same and . For each honest signer whose partial signature is released, it records in . If the adversary controls some participants, the challenger performs only the honest signers’ steps and exchanges the prescribed public messages and partial signatures with the adversary . Records of released partial signatures are retained even if aggregation is not completed.
- (2)
- Verification and aggregation. Once all partial signatures are available, the challenger verifies them according to MP-Sign. If any partial signature is invalid, it returns ⊥. Otherwise, it aggregates them into , returns to the adversary , and records in .
The challenger’s internal generation or use of secret keys does not constitute key disclosure. Queries involving a participant who remains honest in the final forgery are permitted, subject to the winning conditions below.
Forgery phase. Before evaluating the winning conditions, the challenger checks that all identities in the final output are registered and that their supplied public keys match the corresponding entries in . It also checks that the proxy identities are distinct and correspond exactly, in the prescribed order, to those specified in . If any check fails, the adversary loses. The adversary outputs the target original signer’s identity and public key, the identities and public keys of the designated proxy signers, and either a delegation or a report accompanied by a multi-proxy signature . The adversary wins if all conditions of at least one of the following scenarios are satisfied.
Scenario 1: Delegation forgery. The adversary impersonates an original signer with identity and outputs such that:
- (1)
- The delegation passes verification for the specified original signer and designated proxy group.
- (2)
- ; hence, the adversary has not obtained the original signer’s long-term private key through .
- (3)
- contains no delegation issued for the same original signer identity and public key, warrant , and designated proxy identities and public keys.
Scenario 2: Signature forgery without an honest proxy signer’s participation. The adversary corrupts the original signer and proxy signers and outputs on under . Without loss of generality, let be the remaining honest proxy signer. The adversary wins if:
- (1)
- MP-Verify accepts on .
- (2)
- ; hence, the adversary has not obtained this signer’s long-term private key through a private-key query.
- (3)
- contains no record showing that the adversary obtained ’s partial proxy signing key for the target warrant, original signer identity and public key, and designated proxy identities and public keys.
- (4)
- contains no record of signing under the same warrant, original signer identity and public key, and designated proxy identities and public keys. This condition applies to both released partial signatures and returned multi-proxy signatures.
Scenario 3: Signature forgery without the original signer’s authorization. The adversary corrupts all n proxy signers and outputs on under , claiming authorization from an original signer with identity . The adversary wins if:
- (1)
- MP-Verify accepts on .
- (2)
- ; hence, the adversary has not obtained the original signer’s long-term private key through .
- (3)
- contains no delegation issued for the same original signer identity and public key, warrant , and designated proxy identities and public keys.
- (4)
- contains no multi-proxy signature returned on under the same warrant, original signer identity and public key, and designated proxy identities and public keys.
These winning conditions permit queries concerning other reports and authorizations, subject to the stated private-key and proxy signing-key restrictions. We denote existential unforgeability against adaptive chosen-warrant, chosen-message, and chosen-identity attacks by EUF-CWMIA. The adversary’s advantage is its probability of winning Game 1:
The scheme is secure in this model if the advantage is negligible in for every probabilistic polynomial-time adversary .
5. Scheme Construction
The proposed IBMPS scheme comprises seven algorithms: Setup, PriK-Extract, PubK-Generate, Dele-Generate, ProK-Generate, MP-Sign, and MP-Verify. The original signer first issues a delegation that binds the authorization warrant w to the designated proxy signers. Upon validating the delegation, each proxy signer derives a partial proxy signing key using its private key and fresh randomness. To sign a common report m, the proxy signers generate partial signatures using a common hash value . A designated clerk verifies these contributions and aggregates them into a multi-proxy signature. The correctness of the aggregate verification equation follows from the signature construction and the bilinearity of the pairing.
- Setup: Given a security parameter , the PKG selects an additive cyclic group and a multiplicative cyclic group of the same prime order , together with an efficiently computable, non-degenerate bilinear pairing
Let P be a generator of . The PKG samples E uniformly from and independently samples uniformly from , where is a polynomially bounded positive integer.
It also samples , sets the master secret key to , and computes .
The PKG specifies the public indices of
where and are independently selected from collision-resistant hash families. Their indices are omitted from the notation for brevity.
For an input z, let
The group-valued functions are defined by
All multipart hash inputs are encoded canonically and unambiguously, with field boundaries and list ordering preserved. In particular, the proxy public-key list is represented as the ordered tuple
whose entries follow the order of the corresponding proxy identities specified in the warrant w.
The PKG publishes
including the public hash indices and function descriptions, and keeps the master secret key secret. The functions and are evaluated directly from these public parameters.
- PriK-Extract: For a user with identity , the PKG samples and computes
The PKG sends to the user and delivers the private key through a secure channel. The user recomputes and accepts if and only if
Otherwise, the user rejects the key.
- PubK-Generate: The user with identity sets , where is obtained from the PKG during PriK-Extract. After this step, the original signer holds the public-private key pair , and each proxy signer holds the public-private key pair , for .
- Dele-Generate: The original signer specifies an authorization warrant w and the ordered public-key listof the designated proxy signers. The warrant specifies the mission identifier, the identities of all authorized proxy signers, the mission objectives, the geographical scope, the authorization validity period, and the reporting requirements.
The original signer samples and computes
It sends the delegation and the ordered list L to each designated proxy signer . The input to binds the delegation to the warrant, the original signer’s identity and public value, and the ordered public-key list of the designated proxy group.
- ProK-Generate: Before verifying the delegation, checks that belongs to the proxy group specified in w and that matches the corresponding entry in L. If either check fails, it returns ⊥.
The proxy signer computes
and verifies the delegation by checking
If verification fails, returns ⊥. Otherwise, it samples and computes
The partial proxy signing key combines the verified delegation, the proxy signer’s private-key contribution, and fresh randomness. The signer broadcasts to the proxy group and keeps secret for subsequent partial signature generation. The public value is used in partial signature verification and in computing
The algorithm outputs , or ⊥ on failure.
- MP-Sign: To sign a common rescue report m on behalf of the original signer under the warrant w, all designated proxy signers generate partial proxy signatures. A clerk , where , verifies and aggregates their contributions. The clerk also contributes its own partial proxy signature.
(1) Partial signature generation Each proxy signer first checks whether its local observation supports the common statement in the report m and whether m satisfies the authorization conditions in w. If either check fails, it returns ⊥.
Using the public values broadcast during ProK-Generate, each proxy signer computes
This step requires the public values of all designated proxy signers to be available. All participating signers use the same report m, warrant w, and aggregate value .
The proxy signer samples and computes
It sends the partial proxy signature
and its public key to the clerk.
(2) Partial signature verification and aggregation
The clerk uses the ordered public-key list
specified in the delegation. It checks that each received contribution corresponds to a designated proxy signer and that the supplied public key matches the corresponding entry in L. If either check fails, it returns ⊥.
Using the public values of all designated proxy signers, the clerk recomputes
For each , including its own contribution, the clerk checks
This verification equation follows by expanding the partial signature as
and applying the private-key relations and the bilinearity of the pairing.
If any verification fails, the clerk returns ⊥. Aggregation is performed only after one valid partial signature has been obtained from every designated proxy signer, including the clerk. If any required contribution is unavailable, the joint signature cannot be completed. The algorithm does not permit aggregation over a subset of the designated proxy group.
Once all required partial signatures have been verified, the clerk computes
and outputs the multi-proxy signature
for the report m.
Since all partial signatures use the same and , their corresponding terms can be added in . Each partial signature contains one occurrence of ; therefore, contains . This determines the coefficients of the original signer’s terms in the aggregate verification equation.
- MP-Verify: Given the report m, the original signer’s identity–public-key pair , the proxy signers’ pairs , and the multi-proxy signaturethe verifier checks whether m satisfies the conditions specified in w. It also checks that the supplied proxy identities are distinct and correspond exactly to those specified in w. It constructs the ordered public-key listaccording to the identity order in w, where . If any check fails, it rejects the signature.
Otherwise, the verifier computes
The list L uses the same ordering and canonical encoding convention as in Dele-Generate. The verifier accepts if and only if
Otherwise, it rejects the signature.
The correctness of the scheme follows from the definition of :
Using bilinearity and the private-key relations
we obtain
Hence, every correctly generated multi-proxy signature satisfies the verification equation.
6. Security Proof
6.1. Security Proof of Unforgeability
Theorem 1.
Under the CDH assumption in and the collision resistance of , the proposed IBMPS scheme is existentially unforgeable in Game 1, which permits adaptive queries and the specified collusion but excludes public-key replacement. For any PPT adversary and each Scenario i, there exists a PPT CDH solver satisfying
where is the Scenario i winning probability, is the solver’s success probability, and
The query bounds are defined below, with , , and in Scenario 3. Simulation and extraction coefficient events are accounted for in , not assumed separately.
Proof.
Let be a probabilistic polynomial-time adversary in Game 1. The reduction algorithm receives a CDH instance for the scheme’s group parameters, where are independently and uniformly chosen from , and aims to compute .
Setup Phase. The reduction completes the setup phase in the following three steps.
(1) Generates master key and public parameters.
The reduction uniformly selects and sets
It retains privately. Since b is uniform in , E is a uniformly random generator of .
(2) Generates Waters hash parameters.
The reduction generates , , and as in the real Setup algorithm, with
Let be fixed polynomial upper bounds on the numbers of distinct inputs for which the simulation requires nonzero coefficients and , respectively. In Scenario 2, bounds all distinct inputs at which the target proxy releases a partial signature, including queries answered using explicit keys. This conservative set contains every input requiring nonzero in an implicit-key simulation. Repeated inputs are counted once. The bounds are fixed before the interaction. Set
and assume
The reduction independently and uniformly samples
and defines the integer coefficients
It independently samples
and computes
It does not resample if any or equals . Since and are sampled independently and uniformly from , and P generates , each and is uniformly distributed over , including , as in the Setup algorithm.
Parameter-distribution consistency. The value is uniformly distributed over , as specified in the real Setup. For every , since and are independently uniform in and P generates , the values
are independently uniform in , including , as in the real Setup. Moreover, the target public key is uniformly distributed over , exactly as an ordinary public key for .
For an encoded input z, let
The public hash functions are
Using its stored coefficients, can compute
so that
The coefficients are defined over the integers; group scalar operations are performed modulo q.
(3) Distributes parameters.
The reduction sends
to , including the public hash indices and descriptions. It retains and the decomposition coefficients privately.
Query phase. The reduction maintains the lists defined in Game 1. In addition to the lists defined in Game 1, maintains a reduction-only list for proxy signing keys that are represented implicitly during signing-query simulations. Each entry records the matching delegation, identities, public keys, the ordered list L, and the random scalar and public value . The corresponding proxy signing key is not stored in because cannot compute it explicitly. Entries in do not represent key disclosure and are not entries in . Let be a polynomial upper bound on the number of distinct identities registered during the interaction, including registrations triggered by queries other than . Before answering queries, uniformly guesses one of these registration positions. When the identity at the guessed registration position is registered, sets its public key to . Since a is uniform in , this public key is distributed exactly as for in the real key-generation algorithm. The identity registered at that position is denoted by . This is an internal guess by the reduction and does not require to select its target identity in advance.
: If is already registered, returns its current public key from . Otherwise, it registers as follows.
(1) If this is the guessed registration position, sets
It stores in and in , where ⊥ indicates that the corresponding private key is unknown to .
(2) Otherwise, uniformly selects and computes
It stores in and in .
In both cases, returns . The same registration procedure is used whenever another query first introduces an unregistered identity. Internal key generation does not add an entry to . Since a is uniformly distributed over , the initial public key has the same distribution as an honestly generated public key .
: If is unregistered, first registers it using the procedure described in . It then proceeds as follows.
(1) If , aborts the simulation, since the corresponding private key is unknown.
(2) Otherwise, retrieves from and returns to . It adds to if it is not already recorded. Repeated queries return the same private key.
: The reduction registers any unregistered identities using the procedure described in . It checks the supplied public keys and the designated proxy group as specified in Game 1. If any check fails, it returns ⊥.
It computes
and proceeds as follows.
(1) If , retrieves the corresponding private key , computes
samples uniformly from , and computes
(2) If , then . computes
and, using its stored hash-generation coefficients, computes the integer coefficient J and a scalar such that
If , it aborts the simulation. Otherwise, it samples t uniformly from and computes
If , it resamples t and recomputes until . It then computes
In either case, returns together with L and stores
in . No entry is added to .
: The reduction registers any unregistered identities as described in . It verifies the delegation and checks the supplied public keys and the membership of according to Game 1. If any check fails, it returns ⊥.
A matching entry is determined by the delegation, the original signer, the proxy signer, their public keys, and the ordered list L.
If a matching entry exists in , retrieves the stored . It records the corresponding exposure tuple in if it is not already present, and returns to .
If no matching entry exists in but a matching entry exists in , the corresponding proxy signing key is represented implicitly and cannot be returned to . In this case, aborts this query simulation. It does not add an entry to .
If no matching entry exists in either list, computes
and proceeds as follows.
(1) If , retrieves the corresponding private key from , uniformly selects , and computes
(2) If and , uses its stored hash-generation coefficients to compute the integer coefficient J and a scalar such that
If , aborts this query simulation. Otherwise, it uniformly selects and computes
If , it resamples t and recomputes until . It then computes
This computation is consistent with ProK-Generate. For the implicit scalar ,
If but , aborts this query simulation.
For either newly generated explicit key, stores
in . It records the corresponding exposure tuple in and returns to . Internal generation of a key does not add an entry to .
:
The reduction verifies the delegation, checks that m complies with w, and checks the supplied public keys and designated proxy group according to Game 1. If any check fails, it returns ⊥. Otherwise, it proceeds as follows.
(1) Partial signature generation.
For each honest proxy signer , searches and for a matching proxy signing-key record. A matching record has the same delegation, original signer, proxy signer, public keys, and ordered list L.
If a matching explicit key exists in , retrieves and uses it.
If a matching implicit-key record exists in , retrieves . The corresponding proxy signing key is represented as
but is not computed explicitly.
If no matching record exists and , samples and computes
It stores this explicit key and its public value in . This internal generation does not add an entry to .
If no matching record exists and , computes
If , uses the internal explicit-key simulation described in . It stores the resulting key in without recording an exposure in .
If , samples and computes
It stores the matching delegation, identities, public keys, ordered list L, and the pair in . It does not compute explicitly.
If any required internal key-generation simulation aborts, aborts this signing-query simulation.
When controls some participants, it supplies their protocol messages as specified in Game 1. Using the public values from the signing interaction, computes
For each honest signer with an explicit proxy signing key, samples and computes
For an honest signer whose proxy signing key is represented implicitly in , let
If , aborts this signing-query simulation. Otherwise, it samples and computes
If , it resamples t until . It then computes
where
This partial signature is consistent with MP-Sign. For the implicit signing scalar
and the implicitly represented key
we have
The resampling condition ensures that . For each signing query, uses fresh signing randomness and reuses the matching cached key state.
For each honest signer, forms
and records
in .
returns the prescribed public messages and partial signatures to . The records of released honest partial signatures are retained even if aggregation is not completed.
(2) Verification and aggregation.
When all n partial signatures are available, verifies them according to MP-Sign. If any verification fails, it returns ⊥. Otherwise, it computes
and returns
It stores
in .
Internal proxy-key generation does not constitute key disclosure and does not add an entry to .
Lemma 1 (Coupling of the query simulation).
The real experiment and the reduction’s simulation can be coupled so that their adversary-visible transcripts agree until the first simulation abort.
Proof.
Uniform masking in and makes the public parameters independent of the hidden coefficient vectors. For analysis, generate a complete real execution using independent real-game randomness, and sample the hidden coefficients independently of ; the corresponding masking scalars give an equivalent representation of the parameter generation.
Couple simulated randomness to real randomness by for delegation and explicit-key simulation, and for implicit-key signing, where u denotes the corresponding real key-generation or delegation randomness and denotes the real signing randomness . For the probability analysis, the target and query bit strings are read from the independently generated real execution . Whenever the denominators are nonzero, these translations preserve the required distributions and produce identical responses. Both executions reuse matching cached keys. On the sufficient coefficient event, any target proxy key later exposed has nonzero and is therefore generated explicitly from its first use.
Identical visible histories induce identical subsequent adaptive queries. Thus the executions agree without abort on this event, while the bit strings determined by remain independent of the hidden coefficients. □
Lemma 2 (Coefficient event bound).
Let , , and sample uniformly and independently from , and k uniformly and independently from . Define
For fixed bit strings , independent of these samples, with and for every i,
Proof.
Write and . The uniform choice of gives . For each i, the strings differ at some coordinate h. Conditional on the remaining coefficients, the map from to has determinant , and is therefore invertible modulo M. Hence,
By the union bound, all query residues are nonzero with conditional probability at least .
When , the bound ensures a unique , selected with probability . Nonzero query residues imply nonzero integer coefficients. Therefore,
Moreover, under the parameter condition , , so integer nonzero coefficients remain nonzero modulo q. □
Forgery Phase. The adversary outputs either a multi-proxy signature
or a delegation , together with the identities and public keys required by Game 1.
Scenario 1: Delegation forgery.
Suppose that satisfies the winning conditions of Scenario 1 in Game 1.
If , or if the public key used to verify the forgery is not , aborts. Otherwise, it computes
Using its stored hash-generation coefficients, obtains and such that
If , aborts. Otherwise, .
Since the final delegation passes verification,
By non-degeneracy and the prime order of , the map is injective. Therefore,
The reduction outputs
Probability Analysis for Scenario 1.
Let be a polynomial upper bound on the number of distinct identity registrations. Let be a fixed polynomial upper bound on the number of distinct inputs for which the simulation requires a nonzero coefficient . These inputs include the target identity’s delegation queries and any other simulation queries for which is required. Set .
Let denote the probability that produces a successful Scenario 1 forgery with an unchanged target public key, with all required non-target private keys available to , and with no collision under between the target input and a distinct input requiring a nonzero .
Define the events:
Then
For a fixed eligible real-game execution, let be the target bit string output by , and let be the distinct query bit strings requiring nonzero , where . Eligibility ensures that for every i. Applying the Coefficient event bound lemma with and gives
By the coupling lemma, the complete real execution is independent of the hidden coefficient vector. Conditional on any eligible , the target and query bit strings are fixed, so the Coefficient event bound lemma applies. Averaging this pointwise lower bound over eligible real executions gives the same bound for adaptive queries.
Whenever occur, the extraction in Scenario 1 outputs the correct CDH value. Hence,
By the collision resistance of and the polynomial number of queries, the probability that the target input collides with a distinct, relevant query input is negligible. Hence, differs from the Scenario 1 winning probability by at most a negligible amount.
Scenario 2: CDH extraction.
Suppose that outputs a signature
on satisfying the winning conditions of Scenario 2 in Game 1. Let denote the honest proxy signer.
If , or if the public key used in the forgery is not , aborts. Otherwise,
The reduction evaluates
Using the coefficients retained during its parameter generation, computes
The extraction requires
and knowledge of for the corresponding public keys in the forgery. These private keys are available from for the corrupted participants in Scenario 2. If any extraction condition fails, does not output a CDH solution in this execution.
Since MP-Verify accepts the final forgery, its verification equation, bilinearity, and non-degeneracy imply
Substituting gives
Therefore, outputs
All terms on the right-hand side are known to under the stated conditions. The reduction performs this extraction only from the adversary’s final forgery.
Probability Analysis for Scenario 2.
Let be a polynomial upper bound on the number of distinct identity registrations. Let be fixed polynomial upper bounds on the numbers of distinct query bit strings that impose nonzero-coefficient conditions for and , respectively. Set
For a fixed real execution and the guessed target identity, let contain the distinct inputs of valid delegation queries in which the target is the original signer, and valid proxy-key exposure queries in which the target is the proxy signer. Its size is bounded by . Requiring nonzero on this set ensures that a key later exposed is generated explicitly from its first use.
Let contain all distinct inputs at which the target proxy releases a partial signature, including queries answered using explicit keys. Its size is bounded by . This conservative set covers every implicit-key signing query. Both sets are determined by and the target identity, independently of the hidden coefficients.
Let be the probability that produces a successful Scenario 2 forgery with an unchanged target public key, with the other private keys required for extraction are available, and with no collision under either or between distinct relevant inputs. The relevant inputs include the target inputs and all query inputs are counted in and .
Define the events:
Here, requires and requires for every distinct query input counted in . Event requires and requires for every distinct query input counted in .
Fix an eligible real execution and a correct target-identity guess. By the coupling lemma, the target bit strings and the sets and are fixed independently of the hidden coefficients. Freshness and collision exclusion ensure that each target bit string differs from the query bit strings in its corresponding set.
Applying the Coefficient event bound lemma to the two independently sampled coefficient families gives a lower bound of for the joint coefficient event. On this event, the coupled simulation completes and extraction succeeds. Averaging over eligible real executions therefore yields
No independence between and is assumed.
The target identity’s registration position is guessed with probability at least . Therefore,
The probability of a collision under either collision-resistant hash family is negligible for a polynomial number of queries. The freshness conditions in Scenario 2 exclude the target signing input from the corresponding prohibited signing queries. Consequently, the collision-related loss between the Scenario 2 winning probability and is negligible.
Since , and ℓ are polynomially bounded, a non-negligible Scenario 2 winning probability yields a non-negligible CDH success probability, up to negligible collision-related loss. This contradicts the CDH assumption. Hence, the scheme is existentially unforgeable under Scenario 2 of Game 1. The coupling and coefficient-event lemmas establish the required simulation and extraction probabilities; these are not additional assumptions.
Scenario 3: CDH extraction.
Suppose that outputs a signature
on satisfying Scenario 3 of Game 1. The original signer remains honest, whereas all n proxy signers are compromised. Assume that .
If , or if the original signer’s public key in the forgery is not , aborts. Otherwise,
where
The reduction evaluates
Using the coefficients retained during its parameter generation, computes
The extraction requires
and knowledge of the private keys corresponding to the proxy public keys used in the forgery. Since all proxy signers are compromised in Scenario 3, these private keys are available to from the key-generation and exposure records, provided their public keys are unchanged. If any required private key is unavailable, or either coefficient condition fails, aborts this extraction.
Since MP-Verify accepts the forgery, the verification equation, bilinearity, and nondegeneracy imply
Substituting and yields
Since , the inverse exists in . Therefore, computes
Every term on the right-hand side is computable under the stated conditions.
Probability Analysis for Scenario 3.
Let bound the number of distinct identity registrations, and let bound the number of distinct inputs for the target original signer that require a nonzero coefficient during simulation. The bound includes every target delegation query whose simulation requires . Set
Let denote the probability of a successful Scenario 3 forgery for which the original signer’s public key is unchanged, all proxy private keys required for extraction are available, and the target bit string differs from every target query bit string requiring a nonzero coefficient.
Define:
: such a successful forgery occurs;
: correctly guesses the original signer’s registration position;
: all query simulations complete without aborting, including satisfaction of every required nonzero-coefficient condition;
: .
Under the distribution-preserving coupling, the chain rule gives
By definition and the hidden uniform guess,
For a fixed eligible real-game execution, let be the number of distinct target query bit strings requiring nonzero . By eligibility, each of these query bit strings differs from the target forgery bit string. Applying the Coefficient event bound lemma with , , and gives
In Scenario 3, all proxy private keys are available to . Thus, proxy-key generation and signing do not require a nonzero coefficient for in order to be simulated. The reduction evaluates directly. Accordingly, there are no query constraints to satisfy, and the target condition is the only coefficient condition. Applying the Coefficient event bound lemma with , , and gives
Fix an eligible real execution and a correct target-identity guess. By the coupling lemma, the target and query bit strings are independent of the hidden coefficients. Applying the Coefficient event bound lemma to the two independent coefficient families gives a joint coefficient-event probability of at least . On this event, simulation and extraction succeed. Averaging over eligible real executions yields
No independence between and is required.
Consequently,
By the collision resistance of and the polynomial number of queries, the probability that the target input collides with a distinct relevant query input is negligible. Hence, differs from the Scenario 3 winning probability by at most a negligible amount.
If wins Scenario 3 with non-negligible probability , then solves the CDH problem with non-negligible probability at least
Since , , and ℓ are polynomially bounded, this contradicts the CDH assumption. Therefore, the scheme is existentially unforgeable under Scenario 3 of Game 1 in the standard model.
By the union bound, the probability of winning Game 1 is at most . Since each term is negligible, the overall winning probability is negligible, completing the proof of Theorem 1.
6.2. Further Security Discussion
Separate generation of partial proxy signing keys.
The scheme includes a separate proxy signing key generation procedure. After verifying the delegation, each proxy signer computes
Subsequent signing uses rather than directly accessing the long-term private key . This separates proxy-key generation from online signature generation.
Long-term private-key protection under proxy-key exposure.
We consider an honestly generated target public key that has not been replaced. The adversary may obtain the target user’s partial proxy signing keys and the associated public information, but not its long-term private scalar through a private-key extraction query. The objective is to recover that scalar.
Suppose that an adversary can recover under these conditions. Given a CDH instance , a reduction uniformly selects and sets
All remaining parameters are generated as in the real scheme. The target key satisfies
Although the reduction does not know , it can compute
Consequently, for each valid delegation, the reduction selects as in the real algorithm and computes
The resulting partial proxy signing key has exactly the distribution prescribed by the scheme. The reduction can return this key and , and can generate partial signatures using the simulated proxy key. It can also disclose if this is included in the exposure experiment.
If the adversary outputs the correct scalar , the reduction computes
and returns
Thus, for a fixed target identity, successful private-scalar recovery yields a CDH solution with the same success probability.
Partial multi-proxy signature verification.
Before aggregation, the clerk verifies every partial signature using
The clerk aggregates the partial signatures only if all verification equations hold. Otherwise, it rejects the invalid partial signature and does not produce the aggregate signature from that collection. This provides an explicit check of each partial signature before aggregation. □
7. Performance Analysis
We compare the security-related features of representative identity-based multi-proxy signature schemes. For the computational-cost and representation-size comparisons, we additionally include a certificateless multi-proxy signature scheme as a reference.
Table 2 compares the security-related features and reported security analyses of the identity-based multi-proxy signature schemes. The certificateless multi-proxy signature scheme is excluded from this table because it uses a different key-generation framework and adversarial model, including public-key replacement and attacks by a malicious key-generation center. Its security guarantees are therefore not directly comparable under the same criteria. Nevertheless, it is included in the subsequent computational-cost and representation-size comparisons as a reference for collaborative proxy signing.
Table 2.
Security-related features and reported analyses of representative IBMPS schemes.
Table 2 distinguishes reported unforgeability proofs, partial proxy signing-key generation, resistance to long-term private-key recovery under PSK exposure, and verification of individual partial signatures. These are separate properties and should not be interpreted as interchangeable measures of security. The table records the proof models and principal assumptions reported for the compared constructions; it does not rank their overall security.
Li et al. [19] and Xu et al. [20] discuss individual security properties without providing formal reduction proofs. Cao et al. [21], Chen et al. [25], and Shin et al. [26] report CDH-based proofs in the ROM, whereas Gu et al. [24] present a construction and security analysis in the SM. A reported proof alone does not establish that a construction is secure. For example, Xiong et al. [22] showed that Cao et al.’s scheme permits an ordinary signature to be used to construct an unauthorized multi-proxy signature. Our unforgeability analysis is in the SM and relies on the CDH assumption and the collision resistance of and . It provides a separate reduction for each of the three forgery scenarios in Game 1. Each reduction’s success probability accounts for its query simulation, extraction conditions, and negligible collision-related loss, as detailed in the preceding section.
The schemes of Li, Cao, Gu, and Shin include a proxy signing-key generation procedure [19,21,24,26]. In Xu et al.’s scheme [20], the original signer generates the partial proxy signing keys without using the proxies’ long-term private keys. Consequently, the recovery mechanism considered here, which extracts a proxy’s long-term private key from a PSK containing that key’s contribution, is not applicable. Chen et al.’s scheme [25] generates partial signatures directly from the long-term private key and delegation information, without a separate proxy signing-key generation procedure. In our scheme, each proxy first verifies the delegation and then derives an individual PSK for subsequent signing.
Separate proxy signing-key generation does not automatically prevent long-term private-key recovery. In the schemes of Li and Cao, the algebraic relationship between a PSK and the corresponding delegation allows recovery of the proxy’s long-term private key by removing the delegation contribution and, where necessary, inverting a known scalar [19,21]. Shin et al. [26] analyze these recovery mechanisms and report protection for Gu et al.’s construction and their own construction under the exposure settings they consider. These results must be interpreted with respect to the information available to the adversary. In particular, Shin et al.’s construction uses independent secret randomness in the PSK, and the direct recovery argument changes if that randomness is also disclosed.
In our scheme, the partial proxy signing key is
If the PSK, delegation, and random scalar are exposed, the adversary can compute
This calculation reveals a group element rather than the private scalar . The preceding private-key recovery analysis shows how recovery of that scalar yields a CDH solution for an honestly generated target public key that has not been replaced. This property concerns protection of the long-term private scalar; it does not prevent signing with a compromised PSK.
The schemes of Li, Cao, Chen, and Shin support verification of individual partial multi-proxy signatures before aggregation [19,21,25,26]. Xu’s sequential construction and Gu’s construction do not provide the same per-contribution verification procedure [20,24]. In our scheme, the clerk verifies every partial signature and constructs the aggregate signature only if all checks succeed. This allows invalid contributions to be rejected before aggregation. By contrast, failure of a final aggregate verification alone does not identify which individual contribution is invalid.
The construction requires valid contributions from all designated proxy signers and does not provide threshold signing. If any designated UAV becomes unavailable, loses connectivity, or refuses to contribute, the joint signature cannot be completed until all required contributions are available. Partial signature verification detects invalid contributions but does not resolve missing contributions. Changing the signer group requires a new warrant and delegation binding the revised identities and ordered public-key list L. The following analysis therefore evaluates the specified cryptographic operations and representation sizes under explicit counting and encoding assumptions.
We next compare the computational cost of our scheme with those of existing schemes [19,21,23,24,25,26]. We use the primitive-operation timings reported in Table 1 of He et al. [27] as a common benchmark. These operations were measured using the MIRACL library on a Samsung Galaxy S5 smartphone with a quad-core processor, 2 GB RAM, and Android 4.4.2. The pairing benchmark uses a supersingular elliptic curve with a 160-bit subgroup order and a 512-bit underlying field parameter.
Let and denote the evaluation costs of the structured hashes and , respectively. For an underlying hash output of Hamming weight t, direct evaluation requires one general hash computation and t group additions. Thus,
Using the benchmark timings ms and ms, setting , and assuming an average Hamming weight of 128, we obtain
This value is a model-based estimate under the stated assumptions, not a measured structured-hash runtime reported in the reference.
The same primitive-operation timings are applied to the operation counts of all compared schemes to provide a common cost model. This normalization does not imply that the schemes use identical cryptographic parameters or provide equivalent security levels. The choices and average Hamming weight 128 are assumptions used to estimate the costs of and in the proposed scheme; they are not a security-level normalization for the other schemes.
Table 3 lists the operation symbols and benchmark timings. The comparison results for the computational costs of the schemes are presented in Table 4 and Table 5. These estimates cover the operations listed in Table 3. Unless included in and , general hashing, group additions, scalar additions, and protocol-level checks are omitted. Accordingly, the reported values are operation-based estimates rather than complete execution-time measurements.
Table 3.
Operation symbols, benchmark timings, and structured-hash cost estimates.
Table 4.
Comparison of computational costs of various schemes.
Table 5.
Comparison of total computational costs.
The adopted timings provide a common historical cost model for weighting primitive-operation counts. They do not establish equivalent contemporary security levels across the compared schemes. The resulting numerical comparisons therefore describe costs within this model rather than a definitive performance advantage at a common security level. No timing measurements from an implementation of the proposed scheme on UAV or representative embedded hardware are reported in this study.
Table 4 compares the computational costs of the schemes, where n denotes the number of proxy signers. Using the adopted benchmark timings, we estimate the costs of Dele-Generate, ProK-Generate, MP-Sign, and MP-Verify. The total cost is the sum of these four phases, as shown in Table 5. ProK-Generate includes delegation verification by all proxies, while MP-Sign includes partial signature generation, verification where specified, and aggregation.
For the scheme of Li et al. [19], the Dele-Generate, ProK-Generate, MP-Sign, and MP-Verify costs are ms, ms, ms, and ms, respectively. The total cost is ms.
For the scheme of Cao et al. [21], the corresponding costs are ms, ms, ms, and ms, giving a total of ms.
For the scheme of Jin et al. [23], the costs are ms, ms, ms, and ms. The total cost is ms.
For the scheme of Gu et al. [24], the costs are ms, ms, ms, and ms, resulting in a total of ms. Its MP-Sign cost excludes individual partial signature verification before aggregation, which is not included in the construction.
For the scheme of Chen et al. [25], the costs are ms, ms, ms, and ms. The total cost is ms. Since this scheme has no separate partial proxy signing key generation procedure, the ProK-Generate entry accounts only for delegation verification.
For the scheme of Shin et al. [26], the costs are ms, ms, ms, and ms, giving a total of ms.
For the proposed IBMPS scheme, the costs of Dele-Generate, ProK-Generate, MP-Sign, and MP-Verify are estimated as ms, ms, ms, and ms, respectively. The total estimated cost is ms.
Under the stated counting rules and hash-cost assumptions, our scheme has a lower estimated total cost than the schemes of Li, Cao, Jin, Chen, and Shin. Gu’s scheme has a lower total cost, but omits partial signature verification before aggregation. Our scheme combines this verification capability with a fixed number of pairings and scalar multiplications in final signature verification.
As shown in Figure 4, the estimated Dele-Generate cost is independent of the number of proxy signers for all compared schemes except that of Gu et al. [24]. Li et al.’s scheme [19] has the lowest estimated cost of ms, while our scheme requires ms. The additional ms comes from evaluating the structured hash , corresponding to a 17.84% increase over Li et al.’s scheme. The cost of Gu et al.’s scheme is ms and exceeds those of all other compared schemes when .
Figure 4.
Comparison of the estimated computational costs of Delegate-Generate among the schemes of Li et al. [19], Cao et al. [21], Jin et al. [23], Gu et al. [24], Chen et al. [25], Shin et al. [26], and the proposed scheme.
As shown in Figure 5, the estimated cost of the phase reported as ProK-Generate grows linearly with the number of proxy signers. This phase includes delegation verification and, where applicable, proxy signing-key generation. Chen et al.’s scheme [25] has no separate proxy signing-key generation procedure, so its entry accounts only for delegation verification. Under the adopted counting rules, our scheme has the lowest estimated cost of ms, followed by Chen et al.’s scheme at ms. Jin and Wen’s scheme [23] has the highest estimated cost of ms, followed by Li et al.’s scheme [19] at ms.
Figure 5.
Comparison of the estimated computational costs of ProK-Generate among the schemes of Li et al. [19], Cao et al. [21], Jin et al. [23], Gu et al. [24], Chen et al. [25], Shin et al. [26], and the proposed scheme.
As shown in Figure 6, the estimated MP-Sign costs grow linearly with the number of proxy signers. Jin and Wen’s scheme [23] has the highest estimated cost, followed by Cao et al.’s scheme [21]. Gu et al.’s scheme [24] has the lowest cost, but does not include partial signature verification before aggregation. Among the compared schemes that support this verification, our scheme has the lowest estimated MP-Sign cost under the adopted counting rules. Its cost is ms, compared with ms for Li et al.’s scheme [19]. The comparison with Gu et al.’s scheme therefore involves a trade-off between computational cost and partial signature verification.
Figure 6.
Comparison of the estimated computational costs of MP-Sign among the schemes of Li et al. [19], Cao et al. [21], Jin et al. [23], Gu et al. [24], Chen et al. [25], Shin et al. [26], and the proposed scheme.
As shown in Figure 7, the estimated MP-Verify costs of the other compared schemes increase linearly with the number of proxy signers. Under the adopted operation-count model, our scheme requires , giving an estimated cost of ms. At , this is ms higher than the cost of Li et al.’s scheme [19]; for , it is lower than the estimated costs of all six reference schemes. The fixed estimate concerns the operations included in the model. Processing signer identities, public-key lists, and warrant information still depends on the input size.
Figure 7.
Comparison of the estimated computational costs of MP-Verify among the schemes of Li et al. [19], Cao et al. [21], Jin et al. [23], Gu et al. [24], Chen et al. [25], Shin et al. [26], and the proposed scheme.
As shown in Figure 8, the estimated total computational costs of all compared schemes increase linearly with the number of proxy signers n. Jin et al.’s scheme [23] has the highest estimated total cost, followed by Cao et al.’s scheme [21]. Gu et al.’s scheme [24] has the lowest cost, while the proposed scheme has the second-lowest cost under the adopted operation counts and benchmark assumptions. Although at this cost is 18.64% higher than that of Gu et al.’s scheme, our scheme additionally supports partial signature verification before aggregation. The comparison therefore reflects a trade-off between total computational cost and verification functionality. These estimates represent the aggregate computational cost across the four evaluated phases, rather than the end-to-end latency of a UAV rescue application.
Figure 8.
Comparison of the estimated total computational costs among the schemes of Li et al. [19], Cao et al. [21], Jin et al. [23], Gu et al. [24], Chen et al. [25], Shin et al. [26], and the proposed scheme.
For , under the stated operation counts and structured-hash cost assumptions, the estimated Dele-Generate cost of our scheme is ms. This is lower than those of Cao, Jin, Gu, Chen, and Shin by 21.53%, 60.77%, 91.16%, 21.53%, and 21.53%, respectively. Although it is 17.84% higher than Li’s cost, the absolute difference is only ms and does not offset the savings in subsequent phases.
In ProK-Generate, our estimated cost is ms, which is lower than the corresponding costs of all six reference schemes. Compared with Li, Cao, Jin, Gu, Chen, and Shin, the reductions are 18.23%, 11.07%, 35.13%, 8.30%, 3.85%, and 17.27%, respectively. Within the adopted cost model, the preparation phase has a lower estimated cost than the corresponding entries of the six reference schemes, subject to their differences in functionality.
In MP-Sign, our estimated cost is ms, representing reductions of 6.28%, 32.85%, 43.44%, 19.49%, and 22.71% compared with Li, Cao, Jin, Chen, and Shin, respectively. Gu’s signing cost is lower, but its signing procedure does not include partial signature verification before aggregation. Our scheme checks each partial signature and rejects invalid inputs, enabling the coordinating UAV to detect invalid partial signatures before aggregation. The comparison with Gu must therefore account for both computational cost and verification functionality.
In MP-Verify, our estimated cost is ms, which is lower than the corresponding costs of all six reference schemes. Compared with Li, Cao, Jin, Gu, Chen, and Shin, the reductions are 69.29%, 69.49%, 74.06%, 50.26%, 65.75%, and 68.80%, respectively. This estimate suggests potential savings in final verification under the adopted cost model. The actual computational burden at the ground control center remains to be measured.
Across the four phases, our total estimated cost is ms, which is lower than those of Li, Cao, Jin, Chen, and Shin by 19.69%, 29.46%, 44.00%, 19.34%, and 26.16%, respectively. Although the total is 18.64% higher than Gu’s, our scheme supports partial signature verification before aggregation and reduces the final verification cost by 50.26%. Under the adopted operation counts and historical timings, the scheme combines partial signature verification with lower estimated total costs than five reference schemes at . These comparisons remain model-dependent and do not establish practical performance superiority on UAV hardware.
These results compare the encoded sizes of individual cryptographic objects rather than the complete end-to-end communication cost. The latter also includes distribution of the ordered public-key list L, exchange of proxy-key public values and partial signatures, and additional protocol messages or retransmissions.
Let , , and denote the encoded lengths of a group element or scalar, rather than the cardinalities of the corresponding sets. Under the adopted representation, we assume bytes and bytes. The warrant is denoted by w, with an assumed length of bytes. Table 6 compares the sizes of a user’s complete private key, a delegation delivered to one proxy, and a final multi-proxy signature. These sizes exclude public parameters, separately transmitted public keys, and protocol headers.
Table 6.
Comparison of private-key, delegation, and multi-proxy signature sizes.
Under the adopted encoding assumptions, Figure 9 shows that the proposed scheme has the smallest long-term private-key size and matches the smallest per-proxy delegation size among the compared schemes. Its final multi-proxy signature has the same size as that of Shin et al.’s scheme [26], but is larger than those of the schemes of Li, Cao, and Chen [19,21,25]. The comparisons are summarized as follows:
Figure 9.
Comparison of private-key, delegation, and multi-proxy signature sizes among the schemes of Li et al. [19], Cao et al. [21], Jin et al. [23], Gu et al. [24], Chen et al. [25], Shin et al. [26], and the proposed scheme.
- Private-key size: Our long-term private key occupies 20 bytes, corresponding to 15.63% of the 128-byte keys in [19,21,25,26], 13.51% of the 148-byte key in [23], and 7.81% of the 256-byte key in [24].
- Delegation size: Our per-proxy delegation occupies 276 bytes, matching the delegation sizes of the schemes in [19,21,23,25,26]. It is 68.32% of the 404-byte per-proxy delegation in [24].
- Multi-proxy signature size: Our final signature occupies 532 bytes, matching that of the scheme in [26]. It is 31.68% larger than the 404-byte signatures in [19,21,25]. Relative to the signature sizes of the schemes in [23,24], the corresponding ratios arerespectively. For , these ratios are 34.19% and 29.36%.
8. Conclusions
This paper presented an identity-based multi-proxy signature scheme for UAV-assisted rescue operations. The construction integrates mission-specific delegation, individual proxy signing keys, and partial signature verification to authenticate the authorized UAV group’s joint endorsement of rescue reports. We formulated Game 1 to capture adaptive queries and signer collusion without public-key replacement, and proved unforgeability for its three forgery scenarios under the CDH assumption and collision-resistant hashing, with explicit reduction bounds. We also separately analyzed resistance to long-term private-key recovery under proxy signing-key exposure.
Under the adopted operation counts and historical benchmark timings, the cost model estimates lower preparation-phase and final-verification costs for the proposed scheme than for the six reference schemes. For , it estimates a total cost 19.34–44.00% below that of five reference schemes, while Gu et al.’s scheme has a lower estimated total cost. These figures are model-based comparisons and do not establish an advantage at equivalent contemporary security levels or predict performance on UAV hardware. The proposed scheme also supports individual partial signature verification before aggregation, a functionality not provided by Gu et al.’s scheme. Compact long-term private-key storage and a fixed number of group elements in the final signature further support its potential applicability to collaborative UAV reporting. Future work will evaluate the scheme on UAV hardware and investigate its operation under intermittent connectivity and signer unavailability.
Author Contributions
Conceptualization, Y.Q.; Methodology, Y.Q.; Formal analysis, W.L.; Data curation, Y.W.; Writing—original draft, W.L.; Writing—review and editing, W.L.; Investigation, W.L. and N.W.; Visualization, Y.W. and Z.Y.; Validation, W.L.; Supervision, Y.Q.; Funding acquisition, Y.Q. All authors have read and agreed to the published version of the manuscript.
Funding
This work was supported by the Guizhou Provincial Basic Research Program (Natural Science) under Grant QIANKEHEJICHUMS[2025]283, the Science and Technology Platform Project of Guizhou Province, China under grant ZSYS[2025]011, and Guizhou Provincial Basic Research Program (Natural Science) Research Grants (Qiankehe Foundation MS [2026] 471).
Institutional Review Board Statement
Not applicable.
Informed Consent Statement
Not applicable.
Data Availability Statement
The original contributions presented in this study are included in the article. Further inquiries can be directed to the corresponding author.
Acknowledgments
The authors would like to sincerely thank the anonymous reviewers for their valuable comments and constructive suggestions, which have greatly improved the quality and presentation of this paper.
Conflicts of Interest
The authors declare no conflicts of interest.
References
- Cui, J.; Liu, X.; Zhong, H.; Zhang, J.; Wei, L.; Bolodurina, I.; He, D. A practical and provably secure authentication and key agreement scheme for UAV-assisted VANETs for emergency rescue. IEEE Trans. Netw. Sci. Eng. 2024, 11, 1454–1468. [Google Scholar] [CrossRef] [Scilit]
- Wang, H.; Wang, C.; Zhou, K.; Liu, D.; Zhang, X.; Cheng, H. TEBChain: A trusted and efficient blockchain-based data sharing scheme in UAV-assisted IoV for disaster rescue. IEEE Trans. Netw. Serv. Manag. 2024, 21, 4119–4130. [Google Scholar] [CrossRef] [Scilit]
- Zhao, N.; Lu, W.; Sheng, M.; Chen, Y.; Tang, J.; Yu, F.R.; Wong, K.-K. UAV-assisted emergency networks in disasters. IEEE Wirel. Commun. 2019, 26, 45–51. [Google Scholar] [CrossRef] [Scilit]
- Wu, M.; Ai, X.; Badshah, A.; Tu, S.; Ning, Z.; Alfuhaid, H.; Waqas, M.; Halim, Z. SELAP: A security-enhanced lightweight authentication protocol for UAV-assisted VANETs in emergency scenarios. Comput. Netw. 2026, 287, 112523. [Google Scholar] [CrossRef] [Scilit]
- Mambo, M.; Usuda, K.; Okamoto, E. Proxy signatures: Delegation of the power to sign messages. IEICE Trans. Fundam. Electron. Commun. Comput. Sci. 1996, E79-A, 1338–1354. [Google Scholar]
- Boldyreva, A.; Palacio, A.; Warinschi, B. Secure proxy signature schemes for delegation of signing rights. J. Cryptol. 2012, 25, 57–115. [Google Scholar] [CrossRef] [Scilit]
- Malkin, T.; Obana, S.; Yung, M. The hierarchy of key evolving signatures and a characterization of proxy signatures. In Advances in Cryptology—EUROCRYPT 2004; Cachin, C., Camenisch, J.L., Eds.; Springer: Berlin/Heidelberg, Germany, 2004; pp. 306–322. [Google Scholar]
- Schuldt, J.C.N.; Matsuura, K.; Paterson, K.G. Proxy signatures secure against proxy key exposure. In Public Key Cryptography—PKC 2008; Cramer, R., Ed.; Springer: Berlin/Heidelberg, Germany, 2008; pp. 141–161. [Google Scholar]
- Zhang, F.; Kim, K. Efficient ID-based blind signature and proxy signature from bilinear pairings. In Information Security and Privacy; Safavi-Naini, R., Seberry, J., Eds.; Springer: Berlin/Heidelberg, Germany, 2003; pp. 312–323. [Google Scholar]
- Lin, W.D.; Jan, J.K. A security personal learning tools using a proxy blind signature scheme. In Proceedings of the International Conference on Chinese Language Computing, Chicago, IL, USA, 8–9 July 2000; pp. 273–277. [Google Scholar]
- Liu, Z.; Hu, Y.; Zhang, X.; Ma, H. Provably secure multi-proxy signature scheme with revocation in the standard model. Comput. Commun. 2011, 34, 494–501. [Google Scholar] [CrossRef] [Scilit]
- Sun, Y.; Xu, C.; Yu, Y.; Yang, B. Improvement of a proxy multi-signature scheme without random oracles. Comput. Commun. 2011, 34, 257–263. [Google Scholar] [CrossRef] [Scilit]
- Hwang, S.J.; Chen, C.C. New threshold-proxy threshold-signature schemes. Comput. Electr. Eng. 2005, 31, 69–80. [Google Scholar] [CrossRef] [Scilit]
- Huang, H.F.; Chang, C.C. A novel efficient (t,n) threshold proxy signature scheme. Inf. Sci. 2006, 176, 1338–1349. [Google Scholar] [CrossRef] [Scilit]
- Hsu, C.L.; Wu, T.S. Efficient nonrepudiable threshold proxy signature scheme with known signers against the collusion attack. Appl. Math. Comput. 2005, 168, 305–319. [Google Scholar] [CrossRef] [Scilit]
- Hwang, S.J.; Shi, C.H. A simple multi-proxy signature scheme. In Proceedings of the Tenth National Conference on Information Security, Hualien, Taiwan, 5–6 May 2000; pp. 134–138. [Google Scholar]
- Lee, B.; Kim, H.; Kim, K. Strong proxy signature and its applications. In Proceedings of the 2001 Symposium on Cryptography and Information Security (SCIS 2001), Oiso, Japan, 23–26 January 2001; pp. 603–608. [Google Scholar]
- Qin, H.; Tang, W.K.S.; Tso, R. Efficient quantum multi-proxy signature. Quantum Inf. Process. 2019, 18, 53. [Google Scholar] [CrossRef] [Scilit]
- Li, X.; Chen, K. ID-based multi-proxy signature, proxy multi-signature and multi-proxy multi-signature schemes from bilinear pairings. Appl. Math. Comput. 2005, 169, 437–450. [Google Scholar] [CrossRef] [Scilit]
- Xu, G.-S.; Yang, Y.-X.; Gu, L.-Z.; Niu, X.-X. ID-based multi-proxy sequential signature system from bilinear pairing. In Proceedings of the 2007 IEEE/WIC/ACM International Conferences on Web Intelligence and Intelligent Agent Technology—Workshops; IEEE Computer Society: Los Alamitos, CA, USA, 2007; pp. 315–318. [Google Scholar]
- Cao, F.; Cao, Z. A secure identity-based multi-proxy signature scheme. Comput. Electr. Eng. 2009, 35, 86–95. [Google Scholar] [CrossRef] [Scilit]
- Xiong, H.; Hu, J.; Chen, Z.; Li, F. On the security of an identity based multi-proxy signature scheme. Comput. Electr. Eng. 2011, 37, 129–135. [Google Scholar] [CrossRef] [Scilit]
- Jin, Z.; Wen, Q. Certificateless multi-proxy signature. Comput. Commun. 2011, 34, 344–352. [Google Scholar] [CrossRef] [Scilit]
- Gu, K.; Jia, W.; Zhang, J. Identity-based multi-proxy signature scheme in the standard model. Fundam. Inform. 2017, 150, 179–210. [Google Scholar] [CrossRef] [Scilit]
- Chen, Q.; Huang, Z.; Ding, Y.; Zhou, Y.; Huang, H. A new provably secure identity-based multi-proxy signature scheme. In Cyberspace Safety and Security; Vaidya, J., Zhang, X., Li, J., Eds.; Springer: Cham, Switzerland, 2019; pp. 230–242. [Google Scholar]
- Shin, Y.A.; Jeong, I.R.; Byun, J.W. Identity-based multiproxy signature with proxy signing key for Internet of Drones. IEEE Internet Things J. 2024, 11, 4191–4205. [Google Scholar] [CrossRef] [Scilit]
- He, D.; Wang, H.; Wang, L.; Shen, J.; Yang, X. Efficient certificateless anonymous multi-receiver encryption scheme for mobile devices. Soft Comput. 2017, 21, 6801–6810. [Google Scholar] [CrossRef] [Scilit]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2026 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license.








