Abstract
Group public key encryption with equality test (G-PKEET) scheme supports group granularity authorization on the equality test. An authorized proxy is able to check whether two ciphertexts belonging to the same group are encrypted from identical plaintext without decrypting them. However, in indistinguishability-based security notion, current existing PKEET and G-PKEET schemes do not allow adversary to invoke equality test as a service. In contrast, under practical circumstance, an adversary is probably able to exploit the equality test service offered by proxy to decipher a ciphertext, leading to unexpected and unwanted privacy leakage. In this paper, we propose a security definition that includes the abovementioned adversary ability. Through extending the functionality of current G-PKEET scheme, we design a concrete scheme that satisfies our new security definition. Furthermore, our G-PKEET scheme is the first G-PKEET scheme whose security properties can be proved under the standard model.
1. Introduction
Public key encryption with equality test (PKEET) is originally proposed by Yang et al. [1]. In PKEET scheme, users are able to check the equality of a pair of ciphertext without decrypting them, i.e., whether plaintexts decrypted from the ciphertext pair are equal. The tested ciphertext pairs are unnecessary to be encrypted by same public key. However, in PKEET scheme proposed by Yang et al., any user is allowed to perform equality test on arbitrary ciphertexts. In order for private key holders to manage access to equality test on corresponding ciphertexts, Tang proposes PKEET scheme in [2, 3], which introduces the concepts of “proxy” and “token.” Tokens are generated by private key holders, and proxy can correctly perform equality test on ciphertext pairs only after obtaining corresponding tokens. This concept has been applied in a series of subsequent related works [4–7].
In common PKEET scheme, proxy has to request authorization from a user for executing equality test on ciphertexts encrypted by the user’s public key. This authorization mode is referred to in [8] as “user granularity authorization.”
To cope with different application scenarios, the concept “group granularity authorization” has been put forward [8, 9]. Under this authorization mode, a normal user can generate group ciphertexts with the permission of group administrator. Meanwhile, token issued by group administrator can be and only be used to conduct equality test on all group ciphertexts within the same group, thus helping to reduce the computational, storage, and communication overheads caused by token issuance. However, current PKEET definitions are not suitable for group granularity authorization in terms of efficiency [8]. Group public key encryption with equality test (G-PKEET) scheme is firstly proposed by Ling et al. [7], which is the first PKEET scheme supporting group granularity authorization. Besides the concepts of “proxy” and “token,” a trustable “group administrator” role is additionally introduced in G-PKEET, in charge of issuing tokens. Each normal user, holding his own key pair, may apply to a “group administrator” for joining his group. With the permission of administrator, user is able to generate group ciphertexts. Similar to the definition of PKE, a group ciphertext can only be successfully decrypted by corresponding private key holder. In order to conduct equality test on group ciphertexts within same group, a proxy only needs to submit an authorization request to the group administrator.
We remind readers that the primary feature of another existing definition Group Encryption (GE) [10] is allowing encryptor to conceal a recipient (decryptor) within a group of legitimate receivers. In G-PKEET, the entity of a group is a ciphertext. Detailedly speaking, users generate key pairs on their own and are able to join multiple group with same key pair. The group public key used when generating ciphertext decides which group the ciphertext belongs to, while proxy can only perform equality test on ciphertexts within the same group. In short, GE achieves anonymization of decryptor identity, while G-PKEET aims to save the overhead of communication and storage in aspect of token issuance. The two definitions are similar in naming but far various from each other in functionality.
In terms of security, several recently proposed PKEET schemes [4–6] have proved their security properties under standard model. Their security properties are more robust than those relying on random oracle model [11]. Scheme under random oracle model does not always guarantee its security when random oracle is instantiated with real hash function [12]. No G-PKEET scheme has proved to be secure under standard model up till now.
Existing works generally classify potential adversaries into two major categories relying on whether adversary is authorized to perform equality test on target user’s ciphertext, i.e., obtaining corresponding token.
However, with respect to definition on adversary abilities, almost none of the existing schemes consider the situation where unauthorized adversary can restrictively invoke a proxy able to perform equality test on target user’s ciphertext; i.e., he cannot directly perform equality test on target ciphertext. This gives rise to potential risk that unauthorized adversary exploits this service to arouse unwanted information leakage.
On the other hand, PKEET and G-PKEET schemes proposed in related works commonly embed plaintext and corresponding hash values into different components of ciphertext, aiming to make the ciphertext structurally capable of equality test. Thus we propose the definition of “improper ciphertext,” standing for ciphertexts whose embedded plaintext, hash values, and other components are noncorrespondent. These ciphertexts may be submitted by malicious encryptor in order to interfere the correctness of equality test. Once such interference attack is launched in existing G-PKEET scheme, authorized proxy and private key holder have to interact to judge the properness of ciphertext, leading to communication overhead.
We use the following example to demonstrate our motivation more concretely: Consider a group based medic social network scenario (G-MHSN) in Figure 1.
The medical cloud server (MS) is responsible for storing encrypted patient information. A medical worker uses patient’s public key to generate ciphertexts of patient information. A Service Provider (SP) owning computation power provides patient information equality test service for medical workers.
“Groups” represent different medical databases or different partitions of single medical database, depending on demanding of medical workers. The “group” mechanism allows SPs to request authorization only once to check the equality of ciphertexts belonging to the same group, regardless of whose public key these ciphertexts are encrypted by.
The group administrator (GA) is responsible for managing the group, including granting users to generate group ciphertexts and granting SPs to perform equality test on any pair of ciphertexts within the group.
Assume patient information of patient A and patient B needs to be tested in form of ciphertext. The workflow of this scenario is as follows: Firstly, the patient information of A and B is encrypted using their respective public keys and group public keys. Both ciphertexts need to belong to the same group. Secondly, the service provider SP requests permission from the group administrator GA to enable itself to perform equality test within this group. Finally, medical worker can invoke SP to perform equality test on patient information of user A and user B.
Furthermore, we use the above scenario to describe the security concerns that existing G-PKEET solution can not address.(i)Service provider (SP): the SP should ensure that patient information equality test service it provides to medic workers does not reveal information other than equality test result.(ii)Patients: Patients should have the ability to check properness of patient information ciphertext to prevent equality test service from misjudging their ciphertexts.
In coping with the security concerns mentioned above, we make extensions on existing G-PKEET definition. The contribution of our proposed scheme is listed as follows:(1)Our G-PKEET scheme is the first G-PKEET scheme proved to be secure under standard model. Compared with existing G-PKEET scheme, our scheme is no longer dependent on random oracle to prove its security property. Simultaneously, our scheme is acceptable in aspect of communication and storage overhead.(2)In response to the status that current G-PKEET scheme is incapable of permitting private key holder to verify whether embedded message value and hash value are corresponded, we modify the definition of decryption algorithm. The new definition allows private key holder to check whether components are corresponded and output in case of incorrespondence. This modification allows private key holder to detect and remove improper ciphertext more efficiently, ensuring correctness of equality test service. Implicitly, we demonstrate that the modification itself would not compromise security properties of our scheme; i.e., adversary cannot exploit this function to arouse information leakage.(3)Our scheme strengthens the capability of unauthorized adversary, allowing adversaries of this type to invoke equality test oracle. Correspondingly, we prove our scheme to be secure under newly defined security property. This modification would guarantee that the unwanted leakage of plaintext information will not occur even when equality test service would be provided publicly.
2. Related Works
2.1. G-PKEET
The G-PKEET scheme is first proposed by Ling et al. [7], which introduces a trustable “group administrator” role in charge of a group secret key. Each user, holding their own public/private key pair, can apply to a “group administrator” for joining his group, i.e., obtaining a group public key. With the use of group public key, corresponding user private key, and the other user’s public key, a group ciphertext is generated, able to be decrypted by private key of the other user. In order to test the equality of two group ciphertexts belonging to the same group, a proxy only needs to apply to “group administrator” for a group trapdoor.
Furthermore, this scheme is also claimed to be resistant to OMRA attack (offline message recovery attack) proposed by Tang in [13]. In OMRA attack, an attacker authorized by token distributor, who knows the distribution of message space in advance, can recover plaintext from target ciphertext through repeatedly performing equality test between target ciphertext and ciphertext encrypted from guessing message.
Ling et al. show that their scheme is resistant to OMRA attack through avoiding group ciphertexts from being generated publicly. This technique is similar to which used by Wu et al. in [14]. Detailedly speaking, only users who are granted with group public keys by the group administrator can generate a group ciphertext. Thus an OMRA attacker can not organize an attack unless he colludes with the group administrator or any user in the group.
2.2. PKEET under the Standard Model
Zhang et al. put forward a PKEET scheme in standard model [4], which is based on a specific IND-CCA2 public key encryption scheme [15]. Lee et al. also realize a PKEET scheme in standard model [6]. Their solution is generic, using HIBE and one-time signature as building blocks. Compared with Zhang’s scheme, Lee’s scheme gets rid of relying on specific number theoretic assumptions, at the cost of computational efficiency and dependency on strong cryptography primitive. Recently, Zeng et al. propose a generic PKEET scheme [5] in standard model based on hash proof system [16].
2.3. Other Related Works
In terms of refining the security performance of PKEET, Lin et al. put forward PKEET supporting flexible designated authorization (PKEET-FDA) [17]; PKEET-FDA requires proxy to use its secret key together with token to perform equality test, thus preventing attacker from testing ciphertexts with stolen token. Flexibility is embodied in allowing user to authorize multiple testers by once instead of generating specific token for each tester. Zhao and Zeng include access to equality test service within the scope of adversary capabilities and propose a PKEET scheme with corresponding security definition [18]. In aspect of authorization granularity, Lin et al. present PKEET supporting partial authentication (PKEET-PA) [19], where user can adaptively authorize the test right of any number of ciphertexts to a tester by providing constant-size token to tester. With regard to improvement on computation efficiency, several works have explored designing PKEET scheme without relying on bilinear pairing [20, 21].
3. Preliminaries
Notation 1. For a finite set , we denote by the process of uniformly sampling a random element from . We say that a function is negligible if for all polynomials and sufficiently large .
3.1. Cryptography Primitives
3.1.1. Bilinear Map
Let and be cyclic groups of prime order . A bilinear map satisfies the following properties:(i)Bilinear: for any , and , (ii)Nondegenerate: for any , , , where is the generator of (iii)Computable: is efficiently computable
Additionally, in type-1 bilinear pairing , in type-3 bilinear pairing , and there are no efficiently computable homomorphisms between [22].
3.2. Cryptography Assumptions
3.2.1. Decisional Bilinear Diffie–Hellman (DBDH) Assumption
A game corresponding to DBDH assumption is constructed as follows, the roles included in which are challenger C and adversary A. We define Gen as a function which takes a security parameter as input and outputs a tuple where are multiplicative cyclic groups of order , is a bilinear map from to , and is a generator of .
Firstly obtains a tuple by executing . C then randomly selects elements from and from . If , C randomly selects an element in as ; otherwise it sets .
passes the challenge tuple to A. A then outputs a guess . We define an advantage of in the above game as .
The DBDH assumption in claims that, for any PPT adversary, its advantage in the above game is negligible in the security parameter .
3.2.2. External Decisional Diffie–Hellman (XDH) Assumption
This assumption is firstly defined in [23]. Consider the following game between challenger C and the adversary A: Let Gen be an algorithm that takes a security parameter as an input and outputs a tuple where are multiplicative cyclic groups of order , is a type-3 asymmetric bilinear map from to , and is a generator of .
Firstly obtains a tuple by executing . C then chooses random elements a,b from and from . If , C chooses a random element in to be T; otherwise .
passes the challenge tuple to A. A then outputs a guess . We define an advantage of in the above game as .
The XDH assumption in claims that, for any PPT adversary, its advantage in the above game is negligible in the security parameter .
4. Definition
4.1. Definition of G-PKEET
To help understand the relationship between algorithms and entities of G-PKEET, we illustrate execution entities of various algorithms and the interaction specification by Figure 2.
We remind readers that all algorithms of our G-PKEET scheme do not require multiround interaction. Thus we divide involved parties simply into executor and invoker. Invoker provides part of parameters needed for executing function to executor. Then executor, holding remaining secret parameters, executes the function and returns the result to invoker.
We describe the definition of G-PKEET functions as follows:(i)Setup (): this nondeterministic function takes a security parameter as input and returns public system parameter .(ii)KeyGen (PP):this nondeterministic function produces a public/private key pair for a normal user.(iii)KeyGen (PP):this nondeterministic function produces a group secret key for a group administrator.(iv)Join : this nondeterministic function permits a user holding user key to join a specific group holding group secret key . If executed properly, this function will generate and output a group public key for user .(v)Enc : this nondeterministic function takes in a group public key, its corresponding private key, another group public key, its corresponding public key, and a plaintext to generate a ciphertext, where indices , respectively, refer to encryptor and decryptor index.(vi)Dec : this deterministic function takes in a ciphertext , group public key of encryptor and group public key , and private key of decryptor to recover plaintext from ciphertext. The function may output representing rejection under certain circumstances.(vii)Verify : this deterministic function takes in the same parameters as function Dec. Verify outputs if and only if Dec taking in the same parameters outputs ; otherwise Verify outputs standing for the passing of verification.
One key purpose of Verify algorithm is allowing proxy to confirm to private key holder whether ciphertext is proper. Thus it needs to differ from decryption algorithm for not outputting plaintext as a result. On the other hand, Verify helps private key holder to detect improper ciphertext on his own and takes further reaction, such as removing them from the cloud server:(i)Aut : this function generates a group trapdoor tuple used for equality test.(ii)Test : this deterministic function takes in two ciphertexts belonging to the same group, corresponding group trapdoor , group public key, and public key of two decryptors as input. It returns either representing result of equality test or representing rejection under certain circumstances.
Optionally, proxy in advance queries private key holders with . In such cases, proxy may output , indicating that the equality test is ceased due to failure on passing ciphertext verification.
4.1.1. Scheme Correctness
Let be distinct user indexes; be group secret key generated by ; be corresponding user key pairs; be group public keys generated, respectively, by ; be group trapdoor generated by .
Given the aforementioned symbols, G-PKEET scheme achieves correctness if all following statements hold:(1).(2)In the following procedure, outputs 1 when ; otherwise, it outputs 1 with negligible probability:
4.2. Security Model
First, we make some foundational assumptions related to adversary’s behavior pattern for simplicity similarly as in [3]:(1)All users honestly generate their public/private keys(2)There is no overlap between the user set and the proxy set
Due to the functionality of G-PKEET, an adversary who obtains a group token can trivially break the indistinguishability-based security notion of corresponding ciphertexts. Thus we introduce definition on two types of adversary, in the view of an arbitrary user and a group administrator :(1)Type-1 adversary: given a target ciphertext, the purpose of type-1 adversary is to guess the plaintext decrypted from it. The adversary has no access to corresponding private key, but he is able to invoke function Dec with this private key as one parameter (in a black-box fashion). Restrictedly, adversary is not allowed to invoke this function to decrypt the target ciphertext. In addition, type-1 adversary obtains the token required to check equality of the target ciphertext. t. In practical scenario shown by Figure 2, type-1 adversary can be regarded as an adversary stronger than authorized proxy due to its ability to invoke the function black box mentioned above.(2)Type-2 adversary: given a target ciphertext, the purpose of type-2 adversary is to distinguish which plaintext a target ciphertext is decrypted from. The adversary is assured that target ciphertext is encrypted from either of two plaintexts designated by him. In contrast to type-1 adversary, the adversary has no access to the corresponding token required for equality test on target ciphertext. However, he is able to invoke a specific function with this token as a parameter (in a black-box fashion). Similar to the restriction imposed on type-1 adversary, type-2 adversary is not allowed to invoke function to check equality of the target ciphertext.
In practical scenario shown by Figure 2, a type-2 adversary can be regarded as adversary stronger than service user due to its ability to invoke the function black box mentioned above and designate target ciphertext. In existing G-PKEET scheme, type-2 adversary can however be only regarded as an adversary stronger than normal user.
As for adversary of different types, corresponding security property is designed as follows (in the view of ):(i)Type-1 adversary: OW-CCA. A type-1 adversary can not recover the plaintext from a ciphertext, even if it is allowed to query the decryption oracle, verification oracle with specific restrictions. This is the best achievable security guarantee considering the equality test functionality.(ii)Type-2 adversary: IND-CCA. A type-2 adversary is not allowed to obtain equality test token from . But he is allowed to access the decryption oracle, verification oracle, and test oracle with specific restrictions and enables choosing the challenge plaintext pair.
We remind readers that, for type-2 adversaries, IND-CCA2 security to be proved in our paper covers OW-CCA2 security. Specifically, the game definition of OW-CCA2 differs from that of IND-CCA2 only in how the challenge ciphertext is generated. Moreover, the proof of OW-CCA2 security can be reduced to IND-CCA2 security.
4.3. Security Properties
Definition 1. A G-PKEET cryptosystem achieves OW-CCA2 security against a type-1 adversary, if, for , any PPT adversary has only a negligible advantage in the attack game shown in Figure 3, where the advantage is defined to be .
We notify our readers that the definition of our scheme is weakened compared to that in the original G-PKEET definition of [7] in aspect of restriction imposed on decryption oracle in Query phase 2. Detailedly, in Ling et al.’s scheme, decryption oracle refuses to execute Dec algorithm only when challenge ciphertext and corresponding encryptor index and corresponding decryptor index are requested together. In our scheme, oracle refuses to execute Dec algorithm when challenge ciphertext and corresponding decryptor index are requested together, no matter what encryptor index is.
Definition 2. A G-PKEET cryptosystem achieves IND-CCA2 security against a type-2 adversary, if, for , any polynomial-time adversary has only a negligible advantage in the attack game shown in Figure 4, where the advantage is defined to be
We notify our readers that the definition of our scheme is weakened compared to that in the original G-PKEET definition of [7] in aspect of restriction imposed on decryption oracle in Query phase 2 for the reason mentioned above. Corresponding to which has not been included in related works, a new precondition is added: Target user and proxy should interact honestly in procedure when proxy intends to conduct equality test on target user’s ciphertext.
5. Construction
We remind our readers that building a generic G-PKEET scheme through combining an IND-CCA2 secure public key encryption with a OW-CCA2 secure equality test scheme may be able to satisfy G-PKEET definition in aspect of functionality. However, it is difficult to prove its security properties, because trivially combining two schemes together will allow adversary to break security game through decryption oracle.
To be detailed, adversary modifies the ciphertext component of target ciphertext which supports equality test (specifically, the component embedded with plaintext hash value) and then submits new ciphertext to decryption oracle. According to game definition, the oracle would work normally by returning decrypted plaintext, leading to a successful attack. Our method adopts specific construction strategy, allowing components respectively embedded with plaintext and plaintext hash value to be bonded together. Consequently, in our scheme the ciphertext modified as mentioned above would be rejected by decryption oracle. It is worth noting that current general PKEET scheme (not G-PKEET) is built upon cryptographic primitives with specific properties, such as IBE and hash proof system. None of these related works adopts abstract PKEET definition to build a general PKEET scheme with special properties.
We present our construction for G-PKEET scheme as follows:(i)Setup : this algorithm outputs public parameter as follows.(1) are groups of prime order , satisfying bilinear map . is a random generator of .(2) are groups of prime order corresponding to size of message space , satisfying asymmetric bilinear map . are random generators of .(3)Hash functions , , respectively, map ; .(ii)KeyGen : this algorithm randomly selects . The structure of generated key pair is as follows: , , where .(iii)KeyGen : this algorithm outputs where .(iv)Join : this algorithm outputs group public key for in the following structure: .(v)Encrypt : the ciphertext is generated with structure as follows: where , . The encoding function and decoding function (to be mentioned later) map between 3-element tuple and . Assume that the message space M is . The definitions of and are as follows:(1): this function takes in plaintext element and 2 group elements . It outputs a group element .(2): this function takes in a group element that belongs to . It outputs 3 group elements or to indicate decoding failure.
Both of these functions are public, satisfying equation for any . Note that these two functions impose an implicit restriction on : the parameter should satisfy the inequality , corresponding to the size of and . We will omit subscripts “encode” and “decode” in subsequent formulas for conciseness:(i)Decrypt : firstly, decryptor checks whether the following equation stands: where . Decryptor outputs and aborts decryption procedure if aforementioned equation does not stand; otherwise he continues to execute the following steps: where component is taken from . Additionally, decryptor should judge whether the following equations stand: where is taken from group public key . where are taken from . Decryptor returns if the above equations stand; otherwise it outputs . We define ciphertexts which do not satisfy the equations above as “improper ciphertext.”(ii)Verify : this algorithm works the same as Dec except for returning instead of . In terms of concrete construction, private key holder has to check the correspondence of embedded plaintext and hash value by extracting plaintext value from ciphertext in advance. Thus the Verify algorithm unavoidably has similar procedure to Dec algorithm. How to allow Verify algorithm to check the properness of ciphertext without needing of extracting plaintext value is an issue that requires further discussion.(iii)Aut : this algorithm returns tuple .(iv)Test : firstly, tester needs to verify the correspondence of and through judging whether the following equation stands, where the component of is used:
Similar process will be performed on the other ciphertext . Tester proceeds only when both equations stand; otherwise, it aborts by outputting .
The algorithm outputs 1 if
Otherwise, it outputs 0.
Optionally, proxy in advance queries private key holders with in order for detecting whether ciphertexts to be tested are proper. In such cases, proxy outputs when procedure outputs , indicating that the equality test is ceased due to improper ciphertext.
Theorem 1. The proposed G-PKEET cryptosystem achieves correctness mentioned on Section 4.4.1.
Proof. As for the two stated statements, we correspondingly have the following:(i)The first step of decryption judges whether corresponds to , where . The second step of decryption, which calculates corresponds to . In the final step, we have It is obvious that all aforementioned steps stand if ciphertext is correctly encrypted.(ii)Set , respectively, as and . can be reduced toObviously, equals the above formula if ; otherwise the equation stands only when a hash collision happens, the rate of which is negligible.
6. Security Analysis
6.1. OW-CCA2 Security
Theorem 2. The proposed G-PKEET cryptosystem achieves OW-CCA2 property against a type-1 PPT adversary in the standard model based on the DBDH assumption on .
Proof. The main idea of proof is to construct a series of games which are reduced from the original OW-CCA2 game. The adversary unconditionally gains negligible advantage in the last game and is unable to distinguish each pair of games adjacent in reduction.
To complete the proof formally, we need to construct a series of games [24]: Game 0. Challenger behaves the same as OW-CCA2 game in Figure 3. Game 1. In Game 1, challenger modifies component challenge ciphertext consequently altered ciphertext is given as the following structure using corresponding components of of Superscript .We will prove that there exists no PPT adversary able to distinguish Game 0 from Game 1 with nonnegligible advantage as long as DBDH assumption holds on .
6.1.1. Indistinguishability between Game 0 and Game 1
Briefly speaking, we construct an attacker against DBDH assumption. He simultaneously invokes as subprocedure, who attempts to distinguish between Game 0 and Game 1; i.e., will play the role as challenger against .
Setup. After receiving a DBDH tuple , replaces corresponding elements of public key with DBDH challenge tuple elements as follows:where . Other unmentioned elements contained in are generated according to our scheme.
Correspondingly, the private key tuple can be represented as , where is not known to .
Query Phase 1. (1) Decryption Oracle: when is queried with user index , firstly he checks whether the following statement stands:where superscript t = .
If , aborts the whole procedure and outputs a random bit to DBDH challenger. Since adversary has no idea of and , the probability for this type of event is , where is the times that adversary visits decryption oracle.
Otherwise, begins to extract plaintext from nonchallenge ciphertext, by firstly generating :
Let . Then, we have
Finally, it checks the consistency of plain text, hash message, and other components embedded in the ciphertext and outputs result of decryption: where (1) refers to the following statement:(2)Encryption Oracle: challenger works the same as mentioned in original G-PKEET scheme, since he knows the value of when being required to generate a ciphertext with encryptor index .(3)Verification Oracle: challenger works in the same way as mentioned in Decryption Oracle except for following the description of on output.
Challenge. Challenger selects and generates challenge ciphertext tuple in the following structure:where superscript .
Query Phase 2. In this phase, decryption oracle is added with new restrictions: (1) challenge ciphertext cannot be requested together with decryptor index “t”; (2) when and hash value , challenger aborts the whole game and outputs a random bit to DBDH challenger.
Verification oracle works the same as mentioned in phase 1 except when being queried with challenge ciphertext and as decryptor index. More detailedly, output is defined as follows:
Under actual circumstances, Verify might output 1 when , consequently breaking the indistinguishability between Game 2 and actual circumstance. However, this situation happens when and only when a hash collision happens, the rate of which is negligible.
Guess Phase. The adversary A outputs 0 or 1 representing the game he recognizes. B outputs the guess when outputs 0, otherwise 1.
Similar to [4], the probability that B aborts during the simulation is at most , corresponding to the illustration in Query phases 1,2, where refers to the probability of a hash collision.
When B does not abort then A’s view is identical to its view in Game 0. Otherwise, his view is identical to that of Game 1. Uniform randomly generated in Game 1 is statistically indistinguishable to when when . The reason is as follows:
Since adversary can be invoked to attack DBDH problem, his advantage can be expressed as
In Game 1, in challenge ciphertext is irrelevant to plaintext message; therefore adversary ’s advantage can be reduced to the success rate of breaking hash function’s preimage properties. Eventually, the advantage of adversary in OW-CCA2 game can be reduced as follows:where refers to advantage of adversary in preimage attack on hash function . Thus Theorem 2 is proved.
6.2. IND-CCA2 Security
Theorem 3. The proposed G-PKEET cryptosystem achieves IND-CCA2 property against a type-2 PPT adversary in the standard model, as long as DBDH assumption on and XDH assumption on hold.
Proof. Game 0. Challenger behaves the same as in IND-CCA2 game of Figure 4. Game 1. In Game 1, challenger modifies component of challenge ciphertext ; consequently altered ciphertext is given as the following structure using corresponding components of :We will prove that there exists no PPT adversary able to distinguish between Game 0 and Game 1 as long as DBDH assumption holds on .
6.2.1. Indistinguishability between Game 0 and Game 1
Using similar technique referred to in Section 6.1.1,, we construct an attacker against DBDH assumption. He simultaneously invokes as subprocedure, who attempts to distinguish between Game 0 and Game 1; i.e., will play the role as challenger against .
Setup. After receiving a DBDH tuple , replaces corresponding elements of public key and private key in the same way referred to in Section 6.1.1.
Query phase 1.(1)Decryption Oracle: when Decryption oracle is queried with parameter decryptor index , deals with the ciphertext using the same way mentioned in Section 6.1.1.(2)Encryption Oracle: challenger works the same as mentioned in original G-PKEET scheme.(3)Verification Oracle: challenger works the same as mentioned in Section 6.1.1.(4)Test Oracle: before performing the computation in procedure and outputting result, the test oracle takes corresponding measures according to decryptor index: When decryptor index equals , the test oracle invokes verification oracle to process queried ciphertext together with decryptor index . The test oracle refuses to continue the test by outputting if verification oracle returns . This step corresponds to the precondition that user and the proxy will interact with each other honestly.
Otherwise, decryptor will assume submitted ciphertext is proper, corresponding to precondition that other users may not honestly interact with the proxy, i.e., maliciously claiming that an improper ciphertext is proper.
Challenge. After receiving plaintext from adversary, challenger selects and generates challenge ciphertext tuple in the same way as mentioned in Section 6.1.1.
Query Phase 2. Decryption oracle and verification oracle are applied with the same modification referred to in Section 6.1.1.
Guess Phase. The adversary A outputs 0 or 1 representing the game he recognizes. B outputs the guess when outputs 0, otherwise 1.
Similar to that referred to in Section 6.1.1, the probability that B aborts during the simulation is at most .
When and B does not abort then A’s view is identical to its view in Game 0. Otherwise, his view is identical to that of Game 1.
Since adversary can be invoked to attack DBDH problem, his advantage is expressed as
Game 2. In Game 2, challenger modifies components of challenge ciphertext on the basis of Game 1. Consequently altered ciphertext is generated using corresponding components of as follows:where , superscript .
We will prove that there exists no PPT adversary able to distinguish between Game 1 and Game 2 as long as XDH assumption holds on .
6.2.2. Indistinguishability between Game 1 and Game 2
We construct an attacker against XDH assumption. He simultaneously invokes as subprocedure, who attempts to distinguish between Game 1 and Game 2; i.e., will play the role as challenger against .
Setup. Challenger receives a XDH tuple and sets ; thus he does not know concrete value of included in . Other public parameters and key pairs are generated in the same way according to our scheme definition.
Query phase 1.(1)Decryption oracle: When being queried with decryptor index , since challenger does not know the value of , he has to check THE consistency of and by judging whether where and are extracted from , which is available to since he has access to corresponding components of .(2)Encryption Oracle: challenger works the same as mentioned in original G-PKEET scheme.(3)Verification Oracle: challenger works similarly as mentioned in decryption oracle except for following the definition of during output.(4)Test Oracle: when decryptor index equals , the test oracle processes submitted ciphertext using corresponding method mentioned in Section 6.2.1.
Otherwise, test oracle will handle query by situation. Let ciphertexts be queried ciphertexts, one of whose decryptor index is and the other is not.
Situation 1. The adversary stores , corresponding to component .
In this situation, the test oracle judges whether the following equation stands:If the equation stands, test oracle outputs 1; otherwise, it outputs 0.
Situation 2. The adversary takes as .
In this situation, the test oracle judges whether the following equation stands:If the equation stands, test oracle outputs 1; otherwise, it outputs 0.
Situation 3. The adversary himself has no idea of value and directly sets component .
In this situation, the test oracle will directly output 0 as a result if the equality test procedure is not aborted by outputting in other steps.
Since adversary does not know , according to the definition of CDH assumption, he is also incapable of knowing . Thus probability for adversary to find out exact that satisfies the following equation is negligible.From the above, we believe that PPT adversary cannot distinguish Game 1 from Game 2 through exploiting inconsistency output which may happen in Situation 3.
Challenge. makes additional modifications to challenge ciphertext of Game 1, embedding the third element of XDH challenge tuple into it:Superscript .
Query Phase 2. Verification oracle is applied with the same change as it is on page 16. The test oracle is supplemented with following rule: Challenger aborts and outputs random bit when a ciphertext whose decryptor index is not (we refer to it by ) satisfies the following formula: where component is taken from , is extracted from component of queried ciphertext, and corresponds to challenge ciphertext component .Since adversary has no idea of value , the probability of abortion owing to the reason above is negligible.
Guess Phase. If recognizes the current game as Game 1, outputs guess ; otherwise it outputs the opposite guess.
Apparently, when , A’s view is identical to his view in Game 1. Otherwise, his view is identical to that of Game 2. Since adversary can be invoked to attack XDH problem, his advantage is expressed asThis is negligible when corresponding assumption stands.
In Game 2, the adversary ’s advantage is negligible since the challenge tuple has no relation with . Eventually, we can reduce the adversary’s advantage in attacking IND-CCA2 Game asThus, Theorem 3 is proved.
7. Comparison
7.1. Theoretical Analysis
In Table 1, we list out the security model and functionality of related PKEET schemes and G-PKEET schemes, showing that our scheme is the first G-PKEET scheme under standard model. All listed schemes obtain IND-CCA2 security against unauthorized users and OW-CCA2 security against authorized users except [1], since it does not introduce token mechanism and is only able to obtain OW-CCA2 security.
In Table 2, we compare the computational efficiency of our schemes with related PKEET schemes and G-PKEET schemes. The second to fourth column show the computational cost of Enc algorithm, Dec algorithm, and Test algorithm. In the aspect of computational efficiency, our scheme is acceptable comparing with other schemes listed.
The reason why computational cost of our scheme is higher than existing G-PKEET scheme [7] is that we add more ciphertext components to ensure our scheme satisfies new security and functional definition. And correspondingly, we have to supply decrypt, test algorithm with corresponding verification steps on these components. These verification steps guarantee scheme security at cost of increasing computational complexity.
Through the fifth column of the table, we remind readers that security properties of our scheme rely on a prerequisite that proxy should interact with user on whether the ciphertext to be tested is proper. This prerequisite implicitly requires a two-round communication for equality test service, i.e., the algorithm Test; otherwise the security properties cannot be completely guaranteed.
As for two generic PKEET schemes, we employed [25, 26] to instantiate Lee et al.’s scheme and use DDH assumption to construct hash proof system, on which Zeng et al.’s scheme is based.
7.2. Experimental Evaluation
We implement experimental performance analysis by using Java Pairing Based Cryptography (jPBC 2.0.0) as underlying cryptographic library [27]. The JDK version is Oracle jdk1.8.0_121. More detailedly, we, respectively, choose type-A curve and type-F curve provided by jPBC to perform symmetric bilinear pairing and asymmetric bilinear pairing. The field size bit length of all curves is at least 256. Our machine is equipped with Intel Core i7-10510U CPU 2.30 GHz processor and 16 GB RAM, running Ubuntu 16.04.
We compare time consumption between our scheme and Ling et al. [7] in aspect of three algorithms: Enc algorithm, Dec algorithm, and Test algorithm. For each algorithm, we run it for ten times and calculate its average time cost. The result is shown as in Table 3.
The gap between two schemes on computation time consumption reflects, on one hand, the gap in theory time complexity. On the other hand, type-A curve pairing operation provided in jPBC takes 10% of the time required by type-F curve pairing operation. Furthermore, the implicit restriction on public parameters in our scheme makes the field size bit length of larger than 256 3, three times as that of , and the computation time is equally increased. We conclude that constructing a more efficient G-PKEET scheme with equivalent security property is an issue that requires further discussion.
8. Conclusion
In this paper, we firstly broaden the current existing security notion of G-PKEET by granting specific adversaries restricted access to the equality test service. The new security notion ensures that unexpected privacy leakage can be avoided even when proxy may provide equality service to malicious users. To construct a solution that matches our definition, we secondly extend the functionality of G-PKEET scheme by allowing private key holder to detect whether a ciphertext is proper while proxy can optionally request private key holder to verify a ciphertext, before he conducts equality test on it. Eventually, our new G-PKEET scheme is acceptable in aspect of computational efficiency and proved to be OW-CCA2 secure against adversary authorized by group administrator and IND-CCA2 secure against unauthorized adversary. Furthermore, our scheme is the first G-PKEET proved to be secure under standard model.
Data Availability
The data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This research was supported by the NSFC-ISF Joint Scientific Research Program (61961146004) and Innovation Program of Shanghai Municipal Education Commission (2021-01-07-00-08-E00101).