Related Works

Since Diffie and Hellman [DH76] proposed the first public key system based on discrete logarithm problems (DLP) in 1976, public key systems have been extensively studied. In public key cryptosystems [Gir91, RSA78, Sha84], each one has a private key and its corresponding public one. To achieve the security requirements of confidentiality and data integrity [Sta05], one can use a recipient’s public key to encrypt messages such that only the

designated recipient can decrypt the ciphertext with his own private key. However, it might be even hard for an arbitrator to handle if a sender disclaims having transmitted the encrypted message. A digital signature scheme is applicable for that the signature is generated with a signer’s unique private key and thereafter everyone can verify its validity with the signer’s public key. It can be seen that only the actual owner of private key can produce a valid signature so as to prevent a dishonest signer from disclaiming, which is referred to as non-repudiation.

In 1994, Horster et al. [HMP94] proposed an authenticated encryption (AE) scheme further providing digital signature schemes with the property of confidentiality and only a designated recipient can verify the signature instead of everyone. Since only a designated recipient has the ability to decrypt the ciphertext and verify the corresponding signature, there might be a potential drawback that a signer repudiates his signature. In such circumstance, it is even difficult for an arbitrator to judge who is lying.

To deal with the case of a later dispute over repudiation, Araki et al. [AUI99] presented a convertible limited verifier signature scheme. However, the signature conversion of their scheme requires the assistance of signer and will incur extra computation efforts, which is considered to be inefficient and unworkable if a signer is reluctant to cooperate with. Besides, Zhang and Kim [ZK03] also pointed out that Araki et al.’s scheme could not withstand a universal forgery attack on an arbitrary chosen message.

In 2002, Wu and Hsu [WH02] proposed a convertible authenticated encryption (CAE) scheme, in which the signature conversion is rather simple and can be solely done by a designated recipient without extra computation efforts or communication overheads. Huang and Chang [HC03] further introduced an enhanced variant in the next year. However, both the Wu-Hsu and the Huang-Chang schemes cannot fulfill the security requirement of confidentiality, i.e., a ciphertext is computationally distinguishable with respect to two candidate messages. To eliminate such security weakness, Lv et al. [LWK05] addressed a secure and practical solution. In 2005, Wu et al. [WHL25] proposed generalized CAE schemes and adapted them based on elliptic curves [Kob87, Mil85] for facilitating gradually popular applications like smart cards [Hen94, RRK⁺04, SP02], mobile phones and PDAs. In 2008, Chien [Chi08] proposed a selectively CAE scheme allowing either a signer or a designated recipient to perform signature conversion. In 2009, Lee et al. [LHT09] addressed a CAE scheme based on the ElGamal cryptosystem. Considering the RSA cryptosystem, Wu

and Lin [WL09] also presented a CAE scheme based on RSA assumption. To fulfill the group-oriented application requirement, in 2008, Wu et al. [WHT⁺08] and Chang [Cha08]

proposed convertible multi-authenticated encryption (CMAE) schemes for group communication, respectively. In 2009, Tsai [Tsa09] presented a more efficient CMAE scheme with lower computation costs. Lin and Yeh [LY08] further proposed a threshold CAE scheme allowing any t or more signers to cooperatively generate a valid authenticated ciphertext on behalf of an original signing group. So far, lots of CAE variants [DC06, DCZ05, EA08, HLL⁺05, LC04, LW08, LWH⁺07, LWH⁺08, WC05, WL08a, WL08b, WLC06, WLH⁺07, ZD04] have been proposed.

In a separate development, Mambo et al. [MUO96a, MUO96b] extended the concept of digital signature and introduced the notion of proxy signatures. A proxy signature scheme allows an original signer to delegate his signing power to an authorized person called proxy signer such that the proxy signer can generate a valid proxy signature on behalf of an original one. As to the proxy delegation, it can be categorized into four different kinds as follows:

(i). Full delegation [MUO96a, MUO96b]: The proxy signer’s signing key is the same as an original signer’s private key so that all (proxy) signatures are generated with an identical private key. Consequently, it is difficult to convince any verifier that a proxy signature is indeed generated by the proxy signer. That is to say, it cannot offer secure mechanisms to protect any one of them from being framed by the other.

(ii). Partial delegation [MUO96a, MUO96b]: Based on the intractability of some security assumptions, e.g., factorization and discrete logarithm problems, a proxy signature key is computed from an original signer’s private key while the latter cannot be derived from the former. Nevertheless, there might be a drawback that it requires an additional revocation protocol, as no information (e.g., the period of validity) is bonded to the delegation. Besides, it is difficult to identify the actual signer for a given signature, since a malicious original signer can easily impersonate a proxy one to forge a valid proxy signature.

(iii). Delegation by warrant [Neu93, Var91]: An original signer prepares a warrant containing some necessary proxy information, such as the period of validity and the identifiers of original and proxy signers, and then sends it to the proxy signer as his delegation authorization. The warrant could be viewed as an original signer’s signature to convince any verifier of his agreement. However, it requires extra efforts to certify and transmit

the warrant, which is costly in terms of computation efforts and communication overheads.

(iv). Partial delegation with warrant [KPW97]: This type preserves the merits of partial delegation and delegation by warrant. Equivalent to the second approach, it is computationally infeasible for a proxy signer to derive an original signer’s private key from his proxy signature key. Moreover, to certify a warrant and validate a signature can be simultaneously carried out in a single step.

Obviously, the fourth approach, partial delegation with warrant, is more flexible and secure as compared with the first three. Because of its efficiency and security as compared with the other three, the author also adopts partial delegation with warrant to implement the proposed schemes. Up to the present, lots of variations of proxy signatures have been proposed [HC01, HLL00, HS00, HWW01, KPW97, LHW98, LWH02, SLH99, TYH04, WHL08, XC04a, XC04b, YX00]. These schemes can be classified into the five categories according to the signing policy and the number of original and proxy signers as follows:

(i). Proxy multisignature [YX00]: A group of two or more original signers delegates the signing power to a proxy signer. Then the proxy signer can generate a multisignature on behalf of the original group.

(ii). Multi-proxy signature [CC06, HS00, LWH02, WHL08, XC04b]: An original signer delegates his signing power to two or more proxy signers and all of them must cooperatively sign on behalf of the original signer.

(iii). Threshold proxy signature [HLL00, KPW97, LHW07, LHW98, SLH99, WCL⁺07]: In a (t, n) threshold proxy signature, an original signer delegates his signing power to n proxy signers such that any t or more of them can cooperatively generate a valid signature on behalf of the original signer.

(iv). Multi-proxy multisignature [HC01, XC04a]: A group composed of two or more original signers can delegate the signing power to a designated proxy group. All members in the proxy group must cooperatively generate a valid multisignature on behalf of the original group.

(v). Threshold multi-proxy multisignature [HWW01, LHL⁺01, TYH04]: In a (t, n) threshold multi-proxy multisignature, a group comprising two or more original signers can

delegate the signing power to n proxy signers. Any t or more proxy signers can cooperatively generate a valid multisignature on behalf of the original group.