Public Key Encryption with Equality Test

• PKEET is a cryptographic scheme that augments standard public key encryption with an equality test, allowing ciphertexts to be compared for matching plaintexts without full decryption.
• The approach uses split encryption and designated testing via trapdoors or tokens, ensuring that even cross-key ciphertexts can be securely and selectively compared.
• PKEET schemes achieve robust security under OW-CCA2/IND-CCA2 models with implementations based on lattice, tag-based, and pairing-free constructions, demonstrating practical efficiency for real-world applications.

Searching arXiv for recent and foundational PKEET papers to ground the article. arXiv search query: "Public Key Encryption with Equality Test" Public key encryption with equality test (PKEET), proposed by Yang et al. (CT-RSA 2010), is a variant of public key encryption that enables an equality test to determine whether two ciphertexts correspond to the same plaintext. This test applies not only for ciphertexts generated under the same encryption key but also for those generated under different encryption keys. In contemporary formulations, PKEET is typically an authorization-based primitive rather than a public-testable one: a designated tester obtains trapdoors or tokens derived from decryption keys and uses them to compare ciphertexts without performing full decryption. The area has developed along three main axes: stronger confidentiality notions such as OW-CCA and IND-CCA or their CCA2 variants, richer authorization models including flexible authorization and ciphertext-file-level authorization, and standard-model constructions from lattice, tag-based encryption, and related primitives (Tezuka et al., 22 Sep 2025).

1. Definition and core syntax

The standard abstract syntax appearing in recent work models PKEET as a tuple of polynomial-time algorithms

$$(\mathsf{Setup},\mathsf{KGen},\mathsf{Enc},\mathsf{Dec},\mathsf{TdGen},\mathsf{Test}).$$

The intended interfaces are

$$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$

$$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$

$\mathsf{TdGen}(dk)\to td,$

and

$$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$

The defining functionality is that $\mathsf{Test}$ should output $1$ when the two ciphertexts encrypt the same plaintext and $0$ otherwise, with negligible error on unequal plaintexts (Tezuka et al., 22 Sep 2025).

A central structural feature is cross-key comparability. In PKEET, the two ciphertexts may come from different key pairs $(ek^{(0)},dk^{(0)})$ and $(ek^{(1)},dk^{(1)})$. A designated tester, armed with suitable trapdoors, can determine whether $$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$0 under $$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$1 and $$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$2 under $$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$3 hide the same plaintext. This distinguishes PKEET from simpler same-key equality-test variants.

Modern work emphasizes that equality testing is usually restricted. In the original Yang et al. PKEET, equality testing was public; then anyone can encrypt guesses and compare with a target ciphertext, leaking whether the target plaintext equals a chosen candidate. Hence modern PKEET notions usually restrict testing to designated testers through trapdoors or tokens. In direct lattice schemes, testing requires two trapdoors,

$$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$4

followed by

$$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$5

so authorization is syntactically required from both involved users (Duong et al., 2020).

2. Security model and leakage profile

The dominant security split is between adversaries with target-user testing authority and adversaries without it. A type-I adversary already has the trapdoor for the target receiver, so indistinguishability is impossible. The relevant notion is therefore one-wayness under chosen-ciphertext attack, denoted OW-CCA or OW-CCA2 depending on the formulation. A type-II adversary does not have the trapdoor, so the target notion is IND-CCA or IND-CCA2 (Tezuka et al., 22 Sep 2025).

This asymmetry is not merely formal. The lattice PKEET literature explicitly notes that if the message space is too small or low-entropy, then a type-I adversary with a trapdoor can mount exhaustive equality tests by encrypting guesses and comparing them against the challenge. Accordingly, these schemes assume that the message space size is exponential in the security parameter and that the message distribution has sufficiently high min-entropy. A common misconception is that authorization alone eliminates dictionary attacks; the formal games instead acknowledge that authorization changes the achievable privacy notion from indistinguishability to one-wayness for authorized testers (Duong et al., 2020).

Another recurrent misconception is that PKEET leaks only a single equality bit. In several standard-model constructions, the tester recovers a deterministic message-derived surrogate such as $$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$6 rather than learning only a yes/no outcome. In direct lattice schemes, ciphertexts contain a second branch encrypting $$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$7, and the equality test works by recovering and comparing those values. In the signcryption-with-equality-test literature, the test similarly extracts a hidden encoding of $$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$8 from an auxiliary ciphertext component and outputs $$\mathsf{Setup}(1^\lambda)\to pp,\qquad \mathsf{KGen}(pp)\to (ek,dk),$$9 iff the recovered hashes match. The leakage is therefore at least equality or non-equality plus the deterministic fingerprint $$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$0 or $$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$1. Correctness depends on collision resistance of the hash, and confidentiality against authorized testers depends on one-wayness of the hash and sufficiently large message spaces (Duong et al., 2020, Le et al., 2020).

The resulting privacy profile is designated-testable rather than public-testable and equality-revealing rather than equality-only. This suggests that PKEET is best suited to settings in which message entropy is controlled and testing authority is deliberately scoped.

3. Construction paradigms and hardness assumptions

A recurring architecture in standard-model PKEET is split encryption: one component protects the actual plaintext, and a second component protects a deterministic image of that plaintext for equality testing. In the generic construction from tag-based encryption, encryption computes

$$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$2

then

$$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$3

signs $$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$4, and outputs

$$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$5

Decryption verifies the one-time signature, decrypts both TBE components, and checks

$$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$6

Trapdoor generation is simply

$$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$7

and equality testing decrypts the two $$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$8 components and returns

$$\mathsf{Enc}(ek,pt)\to ct,\qquad \mathsf{Dec}(dk,ct)\to pt\ \text{or}\ \bot,$$9

The required ingredients are two tag-based encryption schemes, a one-time signature, and a hash family with one-wayness and collision resistance; the required TBE notion is Kiltz’s IND-selTag-wCCA. The paper presents this as a generic construction in the standard model, without the random oracle model, and instantiates it with Kiltz’s pairing-free TBE based on the decision linear assumption and with an LPN-based TBE, thereby obtaining a pairing-free PKEET scheme without the random oracle model and an LPN-based PKEET scheme without the random oracle model (Tezuka et al., 22 Sep 2025).

Direct lattice constructions instantiate the same split-encryption principle with lattice trapdoors. In the ideal-lattice scheme, the message branch contains

$\mathsf{TdGen}(dk)\to td,$0

while the equality branch contains

$\mathsf{TdGen}(dk)\to td,$1

Testing uses only the second trapdoor component to recover $\mathsf{TdGen}(dk)\to td,$2 from the equality branch. The paper proves OW-CCA2 and IND-CCA2 in the standard model under Ring-LWE and Ring-SIS, together with collision resistance and one-wayness properties of the relevant hashes. It also revises an earlier integer-lattice construction to attain CCA2 security and states that both schemes are more efficient than a generic lattice instantiation based on HIBE (Duong et al., 2020).

Flexible-authorization lattice PKEET extends this template by varying what sort of testing capability is released. The direct integer-lattice and ideal-lattice PKEET-FA constructions are based on the hardness assumptions of integer lattices and ideal lattices, are secure in the standard model, and support multiple authorization granularities. The ideal-lattice version is explicitly implemented, while the integer-lattice version is presented as the first concrete PKEET scheme with flexible authorization from integer lattices (Duong et al., 2020).

4. Authorization, flexible authorization, and public verifiability

PKEET with flexible authorization (PKEET-FA) strengthens privacy protection by allowing comparison authority to be scoped at different granularities. The formal model defines three authorization types. Type-1 authorization is user-wide: $\mathsf{TdGen}(dk)\to td,$3 Type-2 authorization is ciphertext-specific: $\mathsf{TdGen}(dk)\to td,$4 and testing uses the resulting pair of ciphertext-specific trapdoors. Type-3 authorization is mixed: one side releases a ciphertext-specific trapdoor and the other releases a user-wide trapdoor, enabling comparison of a single ciphertext of $\mathsf{TdGen}(dk)\to td,$5 with all ciphertexts of $\mathsf{TdGen}(dk)\to td,$6. In the lattice realizations, Type-1 usually releases the full equality-branch trapdoor, whereas Type-2 releases the precomputed short matrix or preimage for a particular ciphertext, shifting computational cost from the tester to the authorizer (Duong et al., 2020).

A later development is Authorized and Verifiable PKEET (AVPKEET), which adds token-based authorization, public verifiability, and then searchable-encryption-level support. AVPKEET consists of eight polynomial-time algorithms: $\mathsf{TdGen}(dk)\to td,$7 Operationally, the data owner issues a token tied to a specific user public key $\mathsf{TdGen}(dk)\to td,$8, a specific keyword $\mathsf{TdGen}(dk)\to td,$9, and a specific nonce $$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$0 embedded in the target ciphertext file. The token is bound through

$$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$1

and

$$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$2

The cloud server checks that the token’s nonce matches the ciphertext’s nonce set and that it has not been used before. If the token is not valid for that ciphertext, the test is rejected before equality testing. The paper characterizes this as non-transferable and non-replayable authorization of ciphertext files (Li et al., 5 Jun 2026).

AVPKEET also makes equality-test results publicly verifiable. The cloud outputs a proof $$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$3, and any user can verify, using only public parameters and proof elements, that the equality-test result is correct, the authorization is valid, the proof is bound to the cloud’s computation, and the proof is fresh. The core equality-test equation is

$$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$4

and a principal public-verification equation is

$$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$5

Authorization validity is checked through

$$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$6

with $$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$7 reconstructed from the public key, nonce, and token fields. The paper states OW-CCA2 security, token unforgeability, and verification soundness under standard assumptions, and extends AVPKEET to AVSE, a searchable-encryption system with one-time non-transferable tokens bound to users and nonces, batch operations, and fine-grained access control in the modes ALL, PARTIAL, and SINGLE (Li et al., 5 Jun 2026).

5. Applications, efficiency, and implementation evidence

PKEET is motivated by outsourced encrypted data processing. The literature repeatedly cites encrypted databases, cloud storage and cloud computing, medical scenarios, keyword search on encrypted data, encrypted data partitioning for efficient encrypted data management, personal health record systems, and spam filtering in encrypted email systems. In these settings, ordinary encryption hinders matching, duplicate detection, record linkage, and partitioning, whereas equality test provides a controlled comparison capability without requiring plaintext recovery (Duong et al., 2020, Duong et al., 2020).

The multi-user searchable-encryption setting is especially prominent. In AVSE, each data owner keeps an independent public/secret key pair; a data user wants to search for a keyword across encrypted data owned by different data owners; and the cloud server can compare a query ciphertext with stored keyword ciphertexts across keys. The paper argues that plain PKEET is not enough for deployment in clouds because earlier PKEET-based searchable-encryption work lacks ciphertext-file-level authorization, public verifiability of equality-test results, or searchable-encryption-level support such as one-to-many keyword-document mapping, batch proofs, retrieval, and fine-grained result access (Li et al., 5 Jun 2026).

Efficiency evidence is heterogeneous across the literature. The 2020 CCA2-secure lattice PKEET paper gives public-key and ciphertext forms and concludes that both direct lattice schemes are more efficient than the generic lattice instantiation of Lee et al., with the ideal-lattice scheme the most efficient among its options, but it does not provide detailed implementation benchmarks (Duong et al., 2020). By contrast, the ideal-lattice PKEET-FA paper reports an implementation at security level $$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$8, averaged over 1000 runs, with Setup $$\mathsf{Test}((ek^{(\theta)},ct^{(\theta)},td^{(\theta)})_{\theta\in\{0,1\}})\to b\in\{0,1\}.$$9 ms, Encrypt $\mathsf{Test}$0 ms, Decrypt $\mathsf{Test}$1 ms, $\mathsf{Test}$2 $\mathsf{Test}$3 ms, $\mathsf{Test}$4 $\mathsf{Test}$5 ms, $\mathsf{Test}$6 $\mathsf{Test}$7 ms, $\mathsf{Test}$8 $\mathsf{Test}$9 ms, $1$0 $1$1 ms, and $1$2 $1$3 ms. The same paper interprets these timings as showing that more specific authorization can shift cost from testing to authorization (Duong et al., 2020).

AVPKEET and AVSE provide the most explicit cloud-oriented measurements among the cited works. The implementation uses C++ and the PBC library, Type-A pairings with base field size 512 bits and group order 160 bits. The measured primitive costs are $1$4, $1$5, $1$6, $1$7, and $1$8. For AVPKEET, the paper lists Encrypt: $1$9, Authorize: $0$0, AuthorizedTest: $0$1, Proof: $0$2, Verify: $0$3, and Decrypt: $0$4. It highlights authorization time $0$5 and verification time $0$6. For AVSE, the reported token size is

$0$7

with token generation cost $0$8, search for $0$9 equal to $(ek^{(0)},dk^{(0)})$0, and index building for $(ek^{(0)},dk^{(0)})$1 equal to $(ek^{(0)},dk^{(0)})$2. The paper emphasizes that AVSE achieves the most compact token size, $(ek^{(0)},dk^{(0)})$3 bytes, while uniquely providing both ciphertext-file-level authorization and public verification (Li et al., 5 Jun 2026).

6. Related primitives, critiques, and research directions

PKEET is closely related to signcryption with equality test (SCET). The SCET primitive is defined as

$(ek^{(0)},dk^{(0)})$4

with separate sender and receiver key roles, signcryption requiring the sender secret key, unsigncryption requiring the receiver secret key and sender public key, and testing tied to a receiver-derived authorization tag. The first lattice-based SCET in the standard model realizes equality testing by giving the tester a receiver-derived tag

$(ek^{(0)},dk^{(0)})$5

which enables recovery of $(ek^{(0)},dk^{(0)})$6 from an auxiliary ciphertext component. This is not PKEET in the strict sense, but it is highly relevant because the equality-test component is essentially a lattice-based, receiver-authorized equality-test mechanism layered onto an LWE/SIS signcryption core. Relative to classical PKEET, SCET adds authenticity, sender binding, and insider-attack modeling, while retaining ciphertext comparability under authorization (Le et al., 2020).

The PKEET literature also contains several internal critiques. The 2020 CCA2-secure lattice PKEET paper states that Duong et al.’s direct standard-model lattice-based PKEET over integer lattices does not actually achieve CCA2 security, which motivates its modified integer-lattice scheme and its direct ideal-lattice construction (Duong et al., 2020). The SCET paper further argues that some existing lattice-based signcryptions either is insecure or does not work correctly, identifies a correctness flaw in Sato–Shikata 2018, and shows Lu et al.’s lattice signcryption is not even IND-CPA secure. These critiques illustrate a recurring design constraint: equality-test functionality, validity checks, and ciphertext algebra must be coordinated so that authorization does not introduce deterministic or algebraically checkable conditions that destroy indistinguishability or correctness (Le et al., 2020).

Several broader research directions are explicit in the supplied literature. One is the movement from random-oracle-based generic constructions to standard-model generic constructions using weaker primitives: the tag-based-encryption approach is motivated by the observation that TBE is weaker than IBE and that full IBE/HIBE structure is not necessary for this CHK-style PKEET architecture (Tezuka et al., 22 Sep 2025). Another is the movement from basic authorization to flexible authorization and then to ciphertext-file-level authorization with public verifiability (Duong et al., 2020, Li et al., 5 Jun 2026). A final direction, stated directly as an open question in the CCA2-secure lattice PKEET paper, is whether one can further improve efficiency of PKEET constructions while maintaining CCA2 security (Duong et al., 2020).

Taken together, these developments characterize PKEET as a family of authorized cross-key comparison primitives rather than a single fixed syntax. The unifying technical idea is stable across constructions: ciphertexts are augmented with a protected deterministic image of the plaintext, testing authority is represented by a restricted trapdoor or token, and security is calibrated by distinguishing authorized from unauthorized testers. The main points of divergence are how that protected image is formed, how finely testing authority can be scoped, whether test results are publicly verifiable, and which assumptions—TBE, LWE/SIS, Ring-LWE/Ring-SIS, DLIN, LPN, or bilinear-map assumptions—support the resulting scheme.