arXiv CSopen access

Authorized and Verifiable Searchable Encryption Based on Public Key Equality Test for Cloud Storage

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

1

Authorized and Verifiable Searchable Encryption Based on Public Key Equality Test for Cloud Storage

arXiv:2606.07319v1 [cs.CR] 5 Jun 2026

Xiuping Li, Kaiwen Wang, and Xiaolin Chang

Abstract—Cloud storage revolutionizes data management but raises conflicts between functionality and privacy. Public Key Encryption with Equality Test (PKEET), an advanced cryptographic technique, can enable multi-user searchable encryption (SE) through cross-key ciphertext comparison without shared keys. However, existing PKEET-based SE schemes lack ciphertext-filelevel authorization, public verifiability, or SE-level support. This paper first proposes a novel PKEET scheme, AVPKEET (Authorized and Verifiable PKEET). It enables non-transferable and non-replayable authorization of ciphertext files, while supporting public verifiability, all without the need for trusted third parties. Then we propose an AVPKEET-based SE scheme, denoted as AVSE (Authorized and Verifiable SE), featuring one-time nontransferable tokens bound to users and nonces, batch operations, and fine-grained access control (ALL, PARTIAL, SINGLE). We prove OW-CCA2 security, token unforgeability, and verification soundness under standard assumptions. Experiment results demonstrate that AVSE achieves the most compact token size (168 bytes) while uniquely providing both ciphertext-file-level authorization and public verification, with acceptable overhead for cloud storage deployment. Index Terms—Authorization control, Cloud storage, Public key encryption with equality test, Result verification, Searchable encryption.

I. I NTRODUCTION EARCHABLE encryption (SE) facilitates ciphertext search in cloud storage while maintaining data privacy [1]. It allows data owners (DO) to encrypt a set of keywords and upload them along with encrypted data to the cloud, then enables searching over encrypted data through corresponding trapdoors that match specific keywords. Existing SE schemes can be primarily categorized into two types: symmetric searchable encryption (SSE) and asymmetric searchable encryption (ASE). There exist SSE schemes [2], [3], [4], for multiuser scenarios [5]. But they required all users to share a common secret key, creating key distribution challenges and also making individual access revocation impossible without re-encryption. Recent SSE schemes have explored verifiable search with leakage suppression [6] [7], though the sharedkey limitation remains. This paper focuses on ASE schemes to eliminate the need of shared keys. However, some existing ASE schemes like [8] restricted searches to data encrypted

S

Xiuping Li is with both School of Cybersecurity in Northwestern Polytechnical University, and Data Communication Technology Research Institute, P.R. China. Kaiwen Wang and Xiaolin Chang are with School of Cyberspace Science and Technology in Beijing Jiaotong University, P.R. China.(e-mail: [email protected])

PKEET Primitive Execute search tasks

Cloud server Token & Encrypted keywords

Data owner 1 Data owner 2 Data owner 3 Data owner

Encrypt & Upload

Encrypted keywords Encrypted Documents

Data user 1 Data user 2

Proof & Encrypted documents

Data user 3 Data user

Fig. 1. Scheme Framework for Implementing SE Based on PKEET

under the same public key, hindering cross-organization data sharing. Studies have been carried out for the exploration of Public Key Encryption with Equality Test (PKEET) [9], an advanced cryptographic technique, to address the above limitations for ASE-based multi-user SE. Here, equality test is a specialized cryptographic operation that allows the determination of whether two different ciphertexts are created from the same underlying plaintext (original message). PKEET enables cloud servers to determine whether two ciphertext files independently encrypted under different public keys contain identical plaintexts without decryption. This functionality of cross-key comparison naturally supports multi-user SE where each user maintains independent key pairs while still enabling collaborative search operations. Such a capability is particularly critical for efficient cloud data deduplication [10], as it helps minimize cloud storage overhead. There are at least the following three requirements to an authorized and verifiable PKEET scheme, which can be used for practical SE in cloud storage: R1 Ciphertext-file-level authorization control [11]: By ciphertext-file-level authorization control, we mean that each DO can grant search access on a per-ciphertext-file basis, or for a group of ciphertext files, to specific data users. Here, each authorization is cryptographically bound to both the authorized DU and the targeted ciphertext files. This design inherently prevents authorization transfer, thereby thwarting any unauthorized access. Early PKEET schemes like [12] lack authorization mechanisms, that is, any entity with a ciphertext can perform equality test freely. This enables chosen-

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

ciphertext attacks, thereby permitting adversaries to infer plaintext content via the construction and testing of candidate keyword ciphertexts against target ones. We use medical data sharing to illustrate this type attack. In medical data sharing, malicious users could encrypt disease names like ”diabetes” or ”cancer”, then systematically test these against patient records to gradually reconstruct sensitive health profiles. The authors in [11], [13], [14] introduced trapdoor-based authorization to resist this type attack, where DOs issue trapdoors delegating testing rights to specific users. However, these trapdoors are both reusable and transferable. Once issued, they remain valid indefinitely and can be shared with unauthorized parties, thus failing to provide per-ciphertext-file control or prevent authorization abuse. Our scheme overcomes these limitations by employing one-time tokens that are cryptographically bound to the authorized user’s public key (pku ), the target keyword (kw), and a unique nonce (n) embedded in each ciphertext file. This binding ensures non-transferability (tokens cannot be used by other users), non-replayability (each token can only be used once via server-side tracking), and per-ciphertext-file granularity (authorization is specific to individual files or file groups). R2 Public verifiability [9]: By public verifiability, we mean that any user can verify the correctness of equality-test results using only public parameters and the proof (generated by cloud servers, detailed in Section IV), without requiring secret keys or interaction with a third trusted party. Most existing PKEETbased SE schemes like [12], [15], [16], [17], [18] operate under the assumption of fully trusted cloud servers, which are expected to execute equality tests honestly and return correct results. This trust assumption is unrealistic in practice, as CSs may return incorrect test results due to various incentive mechanisms. For example, they might deliberately report two identical ciphertexts as unequal to hide data copy loss, or return forged results without actually performing tests to save computational resources. The lack of public verification mechanisms threatens data integrity and prevents systems from meeting audit requirements. R3 SE-level design: By SE-level design, we refer to the architectural transformation from a basic PKEET scheme to a practical SE scheme. While PKEET provides the fundamental ability of cross-key ciphertext comparison, converting it into a fully-functional SE system requires addressing at least the four technical challenges. i) Keyword-document mapping: PKEET merely determines whether two ciphertexts are identical, whereas a practical SE scheme must establish complex relationships between keywords and multiple documents. This necessitates the design of index structures capable of linking encrypted keywords to their corresponding document sets. ii) Batch operations: PKEET operates on individual pairs of ciphertext, but real-world SE systems must efficiently handle queries that return multiple documents. This necessitates batch encryption for document sets and batch proof generation for multi-document results. iii) Result retrieval: PKEET outputs binary equality results, while SE must securely retrieve the actual encrypted documents matching a query. This calls for auxiliary key generation and distribution mechanisms. iv) Access granularity control: While PKEET may support basic

2

authorization, it falls short of the fine-grained, documentlevel authorization required in an SE system, specifying which documents within a result set a DU is permitted to access. None of the existing PKEET schemes can satisfy all these three requirements. They lack ciphertext-file-level authorization mechanisms [9], [15], [16], or they lack public verifiability guarantees [12], [15], [16], [17], [18], or they lack SE-level design for practical applications [9], [12], [15], [16], [17], [18]. A. Our Contribution This paper explores a SE solution supporting the above requirements R1-R3. The following lists our main contributions: • We propose a novel PKEET scheme, named as AVPKEET (Authorized and Verifiable Public Key Encryption with Equality Test). To the best of our knowledge, it’s the first PKEET scheme that simultaneously supports ciphertext-file-level authorization and public verifiability. By introducing a one-time token mechanism where each token is bound to a specific user’s public key, keyword and unique nonce value, we ensure that authorization is non-transferable and non-replayable. Meanwhile, our verification algorithm allows any user to verify the correctness of test results through public parameters, eliminating the need for trusted third parties. • We propose a novel AVPKEET-based Authorized and verifiable SE scheme (AVSE) to bridge the gap from cryptographic AVPKEET scheme to practical cloud storage system. Besides AVPKEET’s core security capabilities including ciphertext-file-level authorization control and public verifiability (addressing both R1 and R2), AVSE has the following four capabilities (addressing R3) for practical SE in clouds: (i) AVSE enables index management to establish one-to-many keyword-document mappings, allowing retrieval of all documents associated with a keyword rather than just binary equality results. (ii) AVSE provides batch operations for efficiently handling multi-document scenarios, enabling to generate search result proofs and verify them in batches. (iii) AVSE implements secure document retrieval that enables authorized users to decrypt returned documents without exposing the data owner’s master key. (iv) AVSE offers finegrained access control with three authorization levels (ALL, PARTIAL, SINGLE), allowing DOs to precisely control which documents within a result set each user can access. These four components collectively transform the AVPKEET primitive into a deployment-ready scheme suitable for real-world cloud storage applications. We provide formal security analysis for AVSE. Under the random oracle model, we prove that our scheme satisfies the security property of One-Wayness against adaptive chosen ciphertext attacks (OW-CCA2). For the ciphertext-file-level authorization control mechanism, we prove the unforgeability of tokens and forward security, guaranteeing that compromised tokens cannot be used to access subsequently uploaded data. For the verification mechanism, we prove through contradiction that malicious CSs cannot generate false proofs that pass verification.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

We implement and comprehensively evaluate both AVPKEET and AVSE. Experiment results demonstrate that AVPKEET is the first primitive to simultaneously provide ciphertext-file-level authorization control and public verifiability with practical overhead (2.318ms for authorization, 37.426ms for verification). At the scheme level, AVSE achieves the most compact token size (168bytes) among all comparative schemes, with acceptable overhead for cloud deployment. B. Organization The remainder of this paper is organized as follows. Section II reviews related work, and Section III introduces the system model, threat model, and security goals. AVPKEET and AVSE are presented in Section IV and V, respectively. Section VI provides formal security analysis. Section VII demonstrates the performance of our scheme through theoretical analysis and experimental evaluation. Section VIII concludes the paper. II. R ELATED W ORK This section reviews an in-depth examination of the current research on PKEET. We demonstrate that while PKEET provides a theoretical foundation for multi-user scenarios, existing schemes exhibit mutually exclusive deficiencies in authorization control and result verification. Then, we analyze researches on transforming PKEET schemes into SE schemes. A. Public Key Encryption with Equality Test The emergence of PKEET was to address the limitations of cross-key comparison. Yang et al. [12] introduced the fundamental PKEET concept, enabling equality testing between ciphertexts encrypted under different public keys. However, in their scheme, any entity with access to ciphertexts could perform equality tests without authorization, thereby enabling unauthorized data analysis and potential privacy breaches. To address the authorization issue, Ma et al. [13] proposed PKEET with ciphertext-file-level authorization, introducing trapdoor-based access control. However, authorization tokens are reusable and transferable. Once users receive a token, they can use it indefinitely and share it with unauthorized parties. Lin et al. [11] improved computational efficiency through batching techniques, reducing pairing operations for multiple equality tests. While this solved performance issues, their scheme inherited the same authorization weaknesses. Beyond authorization issues, the need for result verification in PKEET also became apparent. Li et al. [9] proposed Public Verification PKEET (PVPKEET), which enables public verification of test results for data integrity checking in multicloud environments. Their scheme allows CSs to generate publicly verifiable proofs of equality test results without relying on trusted third parties. While PVPKEET achieves public verifiability, it lacks ciphertext-file-level authorization control and does not support functionalities required for practical data retrieval applications. Chen et al. [16] introduced testerverifiable equality testing, allowing users to verify whether CSs honestly executed the tests. However, their verification

3

mechanism was only effective for users who initiated the test, rather than being publicly verifiable. Recent theoretical advances have focused on achieving stronger security models. Wu et al. [15] achieved tight security under adaptive corruption, while Wang et al. [17] provided standard model security proofs. In exploring alternative algebraic foundations, researchers have studied RSA-based [18] and lattice-based [19] PKEET schemes to obtain specific advantages such as post-quantum security. Additionally, specialized PKEET variants have been developed for IoT environments [20] and cloud databases [14]. The above discussions all adopt the PKEET scheme based on PKI(Public Key Infrastructure). Besides these, researchers have also explored equality testing under different key management paradigms to address specific deployment challenges. Certificateless encryption with equality test (CLE-ET) [21] eliminates certificate management overhead through partialkey generation models and focuses on lightweight pairing-free constructions for resource-constrained environments. Although these works extended PKEET’s applicability, none addressed the fundamental authorization and verification flaws that prevent secure deployment in untrusted cloud environments. B. From PKEET to Searchable Encryption Converting PKEET to practical SE schemes reveals additional challenges. Wang et al. [22] attempted to hide search patterns using PKEET-based techniques, addressing privacy concerns in pattern analysis. However, their scheme still uses reusable tokens without time constraints, allowing adversaries with compromised tokens to perform unlimited future searches, failing to achieve forward security. Chen et al. [5] combined PKEET with symmetric techniques for dynamic SE, achieving sub-linear search complexity. While efficient, they do not provide verifiable search results, requiring users to fully trust the CS. Beyond PKEET-based approaches, attributebased SE schemes have explored alternative access control paradigms. Earlier work [23] combined outsourced ABE with keyword search to reduce computation costs, while recent schemes [24], [25] integrated PKEET with attribute-based policies achieving policy-based search control. However, these schemes focus on the expressiveness of access policies rather than authorization security. In vehicular network applications [26], [27], [28], researchers have developed lightweight PKEET-based for resource-constrained environments. While these works optimize performance, they typically sacrifice security properties. Notably, none of them implement onetime token authorization to prevent replay attacks, nor do they provide publicly verifiable proofs that can be checked by any third party without keys. The above discussion demonstrated that existing PKEETbased SE schemes in Section II.B suffer from: (i) lack of one-time, non-transferable tokens bound to specific users and nonces, failing to prevent token abuse and achieve forward security; (ii) absence of publicly verifiable and authorizable integrated SE schemes; (iii) missing SE-level support for oneto-many keyword-document mappings with fine-grained result

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

4

TABLE I C OMPARISON OF F UNCTIONAL F EATURES WITH R ELATED S CHEMES

Part A: Comparison of PKEET Schemes Scheme PV CA AU TN FS [12] 2010 × × × × × [13] 2011 × ×† ✓ × × [11] 2014 × ✓ ✓ ✓ × [14] 2018 × ✓ ✓ × × [19] 2022 × ✓ ✓ × × [20] 2022 × × ✓ × × [16] 2023 ׆ ✓ ✓ × × [9] 2024 ✓ × × × × [15] 2024 × × ✓ × ✓ [18] 2024 × ✓ ✓ ✓ × [17] 2025 × ✓ ✓ × ✓ Ours ✓ ✓ ✓ ✓ ✓

Part B: Comparison of SE Schemes Based on PKEET Scheme PV CA AU TN FS IM BO DR FAC [24] 2022 × ✓ ✓ ✓ × ✓ × ✓ ✓ [28] 2022 ✓ × ✓ × × ✓ × ✓ ✓ [25] 2023 × × ✓ ✓ ✓ ✓ × ✓ ✓ [26] 2024 × × ✓ ✓ × ✓ ✓* ✓ × [22] 2025 × ✓ ✓ ✓ × ✓ ✓‡ ✓ × [5] 2025 × ✓ ✓ ✓ ✓ ✓ × ✓ × [27] 2025 × ✓ ✓ ✓ × ✓ × ✓ ✓ Ours ✓ ✓ ✓ ✓ ✓ ✓ ✓* ✓ ✓

Note: PV: Public Verifiability; CA: ciphertext-file-level Authorization; AU: Authorization Unforgeability; TN: Token Non-transferability; FS: Forward Security; IM: Index Management; BO: Batch Operations (two types exist: ‡ multi-keyword conjunctive query in scheme [22]; * batch verification for multiple documents matching a single keyword in our scheme and [26]); DR: Secure Document Retrieval; FAC: Fine-grained Access Control. † [13] provides user-level authorization rather than strict ciphertext-file-level authorization, where proxies can compare all ciphertexts of two users but cannot authorize for individual ciphertexts or ciphertext groups. † [16] allows testers to verify the consistency of messages in ciphertexts, but this mainly targets the correctness verification of ciphertext construction rather than public verification of test result correctness.

access control. Table I presents a comparison of our scheme and related schemes in terms of functional features. Our AVSE scheme is the first to achieve these properties while maintaining provable security.

that the solver may obtain up to q values of the form ha·ri / {r1 , . . . , rq }. for chosen ri ∈ Z∗q . It is required that r∗ ∈ We say the One-More co-CDH assumption holds in G if no PPT algorithm can solve the above problem with non-negligible probability.

III. P RELIMINARIES This section presents the mathematical foundations and system framework necessary for presenting our AVPKEET and AVSE schemes.Table II presents notation used in this paper. A. Bilinear Pairings Let G and GT be two multiplicative cyclic groups of prime order q. Z∗q is a finite field. A bilinear pairing is a map e : G × G → GT with the following properties: ∗ • Bilinearity: For all u, v ∈ G and a, b ∈ Zq , we have a b ab e(u , v ) = e(u, v) . • Non-degeneracy: There exists g, h ∈ G such that e(g, h) ̸= 1. • Computability: There exists an efficient algorithm to compute e(u, v) for any u, v ∈ G. B. Complexity Assumptions BDH Problem (Bilinear Diffie-Hellman Problem) [29]: Given (g, g a , g b , g c ) ∈ G where a, b, c ∈ Z∗q , the BDH problem is to compute e(g, g)abc . • DBDH Problem (Decisional Bilinear Diffie-Hellman Problem) [30]: Given (g, g a , g b , g c ) ∈ G where a, b, c ∈ Z∗q are randomly chosen and Z ∈ GT , the DBDH problem is to determine whether Z = e(g, g)abc or Z is a random element in GT . • One-More co-CDH (One-More Computational DiffieHellman Problem) [31]: Given a cyclic group G of prime order q, generator g, and public values (g, h, g a ) for an unknown a ∈ Z∗q , the One-More co-CDH problem ∗ requires computing ha·r for some value r∗ ∈ Z∗q , given

•

C. System Model Fig. 2 shows the system model of the AVSE scheme. Our AVSE scheme includes four types of entities: Cloud Server (CS): The CS provisions storage services and conducts authorized equality tests on encrypted data. It executes search operations according to user requests and generates verifiable proofs for test results. Data Owner (DO): The DO owns sensitive data and wants to outsource encrypted data to the cloud while maintaining search ability. The DO encrypts keywords and associated documents, uploads them to the CS, and manages access authorization for data users. Data User (DU): The DU requests authorization from the DO to search specific keywords. Upon receiving authorization tokens, the DU can submit search queries to the CS and verify the correctness of returned results. Trusted Authority (TA): TA initializes the system by generating public parameters. After system setup, TA is not involved in subsequent operations. The system consists of three phases: system initialization (each entity participates), cloud data construction (CS and DOs are involved), and cloud data search & retrival (involving CS, DU and relevant Dos). D. Threat Model This paper considers a malicious CS and potential external adversaries. We consider four threats as follows: • T1: Malicious CS. The CS attempts to return incorrect search results without performing honest equality tests.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

5

TABLE II N OTATION U SED IN THIS PAPER Description System Parameters λ Security parameter G, GT Multiplicative cyclic groups of prime order q q Prime order of groups e : G × G → GT Bilinear pairing g, h ∈ G Generators of group G ∗ Zq Multiplicative group of integers modulo q par Public system parameters Keys and Entities (pko , sko ) Data owner’s public/secret key pair (pku , sku ) Data user’s public/secret key pair (pkc , skc ) Cloud server’s public/secret key pair Attro , Attru Attribute sets of DO and DU Data and Encryption kw Keyword data, doci Plaintext of data and document i CTkw Ciphertext of keyword kw CTdata , CTdoc Ciphertexts of data data and document doc DocIDi Document identifier for document i N Total number of documents in the system m Number of documents matching a keyword Authorization and Access Control token Authorization token rk, {rki } Auxiliary key(s) for decryption scope Access scope S Set of authorized document IDs n Nonce for authorization binding σ Hash output for authorization τ Random value in token generation Lused Server-side token-usage table Data Owner Discovery DOList Complete list of all DOs with attributes DUList List of registered DUs with attributes DORelevant Subset of relevant DOs returned to DU Random Values p, k ∈ Z∗q Random values in encryption r = H1 (kw, t) Computed randomness for encryption v, vi ∈ Z∗q Random values for data encryption Verification and Proof π Proof of test result πbatch Batch proof for multiple documents result Equality test result: {0, 1} timestamp Timestamp for freshness verification Security Model A Probabilistic polynomial-time (PPT) adversary C Challenger in security games negl(λ) Negligible function in λ Game Adv{AV (λ) Adversary’s advantage in security game SE,A} Ltoken List of issued tokens b, b′ ∈ {0, 1} Challenge and response bits ∗ ∗ kw0 , kw1 Challenge keywords

Data owner

Symbol

The adversary wins if it can produce false results that pass the verification process, either by claiming non-matching ciphertexts as equal or matching ciphertexts as unequal. • T2: Token Forgery Attack. External adversaries attempt to forge authorization tokens to gain unauthorized search capabilities. The adversary wins if it can generate a valid token that passes the authorization verification without obtaining it from the DO. • T3: Authorization Abuse. Authorized users attempt to extend their search privileges beyond the granted scope. The adversary wins if it can reuse expired tokens, transfer tokens to unauthorized parties, or modify token scope to access documents outside their authorized set.

5.Request authoriation

1.Encrypt keywords and documents

Index buiding

2.Upload

6.Generate token and auxiliary keys 7.Send through a secure channel

Cloud server

3.Request DOList & 4.Return DOList

Data user

8.Generate

Search query

DOList

CTkw

CTdoc

9.Send

12.Proof

Verify

CTdoc’&Proof Yes 13. Decrypt CTdoc’

10.Execute search tasks and generate proof

No 13.Task termination

Fig. 2. System Model of AVSE

T4: CS–DU Collusion. We additionally consider collusion attacks in which the malicious CS shares all of its internal state and intermediate computation results with a subset of potentially malicious DUs. The coalition’s goal is to bypass authorization controls and obtain access to documents or decryption capabilities beyond the scopes explicitly granted by honest DOs. Like most efficient searchable encryption schemes [5] [24] [25] [26] [28] that prioritize practical performance, AVSE does not protect against search pattern leakage [32] and access pattern leakage [33]. Our threat model assumes that adversaries observing these patterns do not possess sufficient auxiliary information to infer the underlying plaintext keywords. This assumption is consistent with many practical searchable encryption deployments where the keyword space is sufficiently large and unpredictable. Achieving pattern-hiding searchable encryption typically requires heavyweight cryptographic techniques such as Oblivious RAM [34]. The primary focus of AVSE is to achieve ciphertext-file-level authorization control and public verifiability with acceptable efficiency, making the pattern leakage a deliberate trade-off for practical deployment. •

E. Security Goals AVSE’s design goals correspond to the functional features in Table I and address the security threats in Section III.D. We define the following security properties: • S1: Keyword Ciphertext One-Wayness (OW-CCA2). OW-CCA2 property ensures that keyword ciphertexts do not reveal the underlying keyword. Even when an adversary has adaptive access to encryption, authorization, equality test, and decryption oracles, it cannot recover the keyword encrypted in a challenge ciphertext with nonnegligible probability, provided that the keyword is drawn from a distribution with super-logarithmic min-entropy. • S2: Authorization Unforgeability (AU). AU property ensures that only data owners can issue valid authorization tokens. When an adversary attempts to forge a token without possessing the data owner’s secret key, even after observing polynomially many legitimately generated tokens and their corresponding search operations, the

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

adversary cannot produce any token that will be accepted as valid by the cloud server. • S3: Token Non-transferability (TN). TN property ensures that authorization tokens cannot be used by unauthorized parties. When an adversary obtains a valid token issued to a legitimate user and attempts to use this token while posing as a different user (or attempts to transfer the token to another user), the verification mechanism will reject the token, preventing the adversary from conducting unauthorized searches. • S4: Public Verifiability (PV). PV property ensures that search result integrity can be checked without secret information. It encompasses two aspects: – Correctness: Honest execution of the protocol produces search results that pass public verification, ensuring the system functions properly in benign scenarios. – Soundness: When a malicious cloud server attempts to deceive users by returning incorrect search results (e.g., claiming two different keywords are equal, or claiming identical keywords are different), the adversary cannot generate proofs that pass public verification. This guarantee holds even when the adversary has obtained knowledge of plaintext keywords through side-channel attacks or cryptanalysis—the adversary still cannot forge valid proofs for false statements about keyword equality. S5: Fine-grained Access Control (FAC). FAC property ensures that users can only access documents they are explicitly authorized to retrieve. When a user receives an authorization token with specific access restrictions (e.g., permission to access only a subset of matching documents), and the user attempts to obtain documents outside the authorized scope, the system prevents such unauthorized access and verification of results outside the authorized set will fail. • S6: Forward Security (FS). FS property ensures that past authorizations do not extend to future data. When an adversary possesses a valid authorization token issued at time t0 and attempts to use this token to search data uploaded at a later time t1 > t0 (after the token’s validity period has expired or after the data owner has rebuilt the encrypted index), the cloud server will reject the search request, preventing the adversary from accessing newly added information with outdated authorization. • S7: Collusion Resistance (CR). CR property ensures that colluding parties cannot combine their privileges to exceed authorized access. When a malicious cloud server colludes with a set of authorized users, pooling their combined knowledge (including the server’s secret key and users’ secret keys and tokens), and attempts to help an unauthorized user access documents outside the scopes granted to the colluding users, the adversary coalition cannot generate valid tokens or decrypt documents beyond the union of their individual authorizations.

6

establishes the correctness aspect of Public Verifiability (S4). Theorems 1-7 in the supplementary material provide rigorous proofs demonstrating that AVSE achieves all security properties (S1-S7) under standard computational assumptions. IV. T HE P ROPOSED AVPKEET S CHEME AVPKEET is built upon PVPKEET’s verification foundation while addressing PVPKEET’s authorization gap. In PVPKEET [9], a DU can perform equality tests on any accessible ciphertexts without restriction. AVPKEET consists of eight polynomial-time algorithms: Setup, KeyGen, Encrypt, Authorize, AuthorizedT est, P roof , V erif y and Decrypt. It makes three enhancements to PVPKEET: (i) Token-based authorization: Authorize algorithm is designed to generate one-time, non-transferable tokens. Each token is cryptographically bound to a specific user, keyword, and nonce, ensuring that only authorized users can request equality tests for specific ciphertexts. (ii) Authorization verification within the test process: We modify PVPKEET’s T est algorithm into AuthorizedT est, which first validates the token’s authenticity and binding to the specific ciphertext before executing the equality test. This prevents unauthorized testing even if an adversary obtains ciphertexts. (iii) Enhanced verification with authorization checking: Our V erif y algorithm confirms both the correctness of the test result and the fact that the test is conducted with proper authorization, thereby adding a layer of security.

•

All security properties are formally defined through cryptographic games in Section III.F. Theorem 1 in Section IV.B

A. Algorithm Description Ciphertext Types in AVPKEET: Our scheme distinguishes between two types of keyword ciphertexts with different roles: (i) Stored keyword ciphertext CTkw , which is generated by DO using the Encrypt algorithm and uploaded to CS along with its associated data ciphertext CTdata , representing the encrypted ′ data stored in the cloud; (ii) Query keyword ciphertext CTkw , which is generated by DU when performing a search by encrypting the query keyword using the keyword encryption part of the Encrypt algorithm. The query ciphertext is used solely for equality test comparison and does not have an associated data ciphertext. The AuthorizedT est algorithm compares these two types of ciphertexts and, if they match, returns the data ciphertext CTdata associated with the stored CTkw . λ • Setup(1 ) → par : On input security parameter λ, TA generates the bilinear map (G, GT , e) of prime order q, where g, h ∈ G are the generators of G. The hash functions are randomly chosen: H0 : {0, 1}∗ → G (hash-to-curve function), H1 : Z∗q × Z∗q → Z∗q , H2 : GT → {0, 1}λ , H3 : {0, 1}∗ → Z∗q . Following standard practice, when applying H3 to non-binary inputs (group elements, integers), we use canonical encodings to convert them into binary strings before hashing. We set par = {q, G, GT , e, g, h, H0 , H1 , H2 , H3 }. • KeyGen(par) → (pk, sk) : Each entity generates its key pair using the system parameters. The DO chooses so ∈ Z∗q and computes pko = g so , setting sko = so . The DU chooses su ∈ Z∗q and computes pku = g su , setting

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

7

sku = su . The CS chooses α ∈ Z∗q , computes pkc = hα and sets skc = α. • Encrypt(par, pko , pkc , kw, data) → (CTkw , CTdata ) : The DO encrypts keyword kw and associated data data. First, random values p, k ∈ Z∗q are chosen, nonce set Nkw with a fixed size and r = H1 (kw, p) is computed. The keyword ciphertext CTkw is generated as (c1 , c2 , c3 , c4 , c5 ), where

the CS inserts n into Lused and proceeds to the equality test. Step 2: Equality Test Execution. The CS ′ computes ′ ′1/(skc +c3 ) 1/(skc +c3 ) E = c4 = hr and E ′ = c4 = hr , then checks whether ?

e(E/E ′ , g) = e(h, c2 /c′2 ). ′

c1 = g so ·r , c2 = g r · H0 (kw), c3 = k, c4 = pkcr · hkr = (hα )r · hkr = h(α+k)r , c5 = Nkw . c5 serves as a nonce for authorization binding. For the data encryption, a random v ∈ Z∗q is chosen, and CTdata = d is computed where d = data ⊕ H2 (e(g, g)so ·v ). Here ⊕ denotes the bitwise XOR operation between bit strings of equal length. The DO locally maintains a table indexed by keywords, where each entry stores the tuple (kw, Nkw , v). • Authorize(sko , pku , kw, n). → (token, rk) : The authorization mechanism ensures only the DO can generate valid tokens and auxiliary key rk. Given a keyword kw, DO retrieves the corresponding v and nonce set Nkw , and randomly selects an unused nonce n ∈ Nkw . Then, DO chooses τ ∈ Z∗q and computes σ = H3 (kw||pku ||n||τ ). The token is generated as (tok1 , tok2 , tok3 ) where

When kw = kw′ , we have c2 /c′2 = (g r · H0 (kw))/(g r · ′ H0 (kw′ )) = g r−r since H0 (kw) = H0 (kw′ ). Step 3: Result Return. If the test passes, result = 1 and the CS returns the corresponding CTdata ; otherwise it returns result = 0. ′ • P roof (CTkw , CT kw , skc , result) → π : The CS generates a verifiable proof of the test result. CS chooses random t ∈ Z∗q , and computes proof π = (π1 , π2 , π3 , π4 , π5 , π6 ), where t/(skc +c3 )

π1 = c4

′

′

= hrt , π2 = c′ 4 t/(skc +c3 ) = hr t ,

π3 = ht , π4 = g t , π5 = H3 (result||tok1 ||timestamp), π6 = timestamp.

tok1 = hso ·σ , tok2 = τ, tok3 = n,

V erif y(π, CTkw , CT ′kw , token, pkc , pko , pku ) → T /F : The DU verifies the correctness of test results. DU performs four verification steps. First, verify result correctness:

rk = pkuv .

e(π1 /π 2 , g) = e(π3 , c2 /c′2 ).

The generated token and auxiliary key are sent to DU through a secure channel. DU will then encrypt the query keyword using the keyword encryption part of the Encrypt algorithm (generating components c1 , c2 , c3 , c4 ′ but not c5 , CTdata ) to obtain the query ciphertext CTkw , ′ and forward both the token and CTkw to CS for authorized equality testing. ′ • AuthorizedT est(CTkw , CT kw , token, skc ) → (result, CTdata ) : The CS receives the token and ′ query ciphertext CTkw from DU, and performs ′ authorized equality test by comparing CTkw with the stored keyword ciphertext CTkw . The algorithm uses a server-side token-usage table Lused to prevent replay attacks. If the equality test succeeds (i.e., both ciphertexts encrypt the same keyword), CS returns the data ciphertext CTdata associated with the stored CTkw . ′ Note that CTkw is a query ciphertext without associated ′ data, so there is no CTdata to return. The algorithm proceeds in three steps: Step 1: Token Validity Verification. The CS first verifies whether tok3 = n ∈ Nkw for CTkw to ensure the token corresponds to this specific keyword ciphertext. Next, the CS checks whether the nonce n already appears in the server-side token-usage table Lused . If n ∈ Lused , the request is rejected and no equality test is performed, as this indicates a replay attempt. Otherwise, if n ∈ / Lused ,

If the equation holds, result = 1; otherwise, result = 0. Second, verify authorization validity: reconstruct σ = H3 (kw||pku ||tok3 ||tok2 ), compute pko σ and check

•

?

?

e(pko σ , π3 ) = e(π4 , tok1 ). Third, verify integrity: ?

e(π1 , pkc · hc3 ) = e(c4 , π3 ), ′

?

e(π2 , pk c · hc3 ) = e(c′4 , π3 ). Fourth, verify freshness: ?

π5 = H3 (result||tok1 ||π6 ).

•

Output T if all checks pass; F otherwise. Decrypt(CTdata , sku , pko , rk) → data :The DU decrypts the data ciphertext using private key and auxiliary key. The decryption computes 1

data = d ⊕ H2 (e(rk, pko sku )). Then the original data is correctly recovered.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

8

B. Design Insights AVPKEET achieves simultaneous authorization control and public verifiability through three key technical mechanisms: Non-transferable Token Binding. The authorization token cryptographically binds to the user’s public key through σ = H3 (kw||pku ||n||τ ) and tok1 = hso ·σ . Any attempt to use the token with a different public key pku′ results in σ ′ = H3 (kw||pku′ ||n||τ ) ̸= σ, causing verification failure in Equation (2) of the V erif y algorithm. This binding is achieved without revealing sko , preventing token transfer or forgery. Ciphertext Authorization via Nonce Binding. Each ciphertext embeds a unique nonce (c5 = Nkw ) that must match the token’s nonce (tok3 = n). The server-side table Lused tracks used nonces, rejecting replay attempts. Combined with timestamp validation, this ensures each token is valid only for specific ciphertexts within a defined time window, achieving forward security. Publicly Verifiable Proofs. The verification algorithm employs five pairing-based equations that can be checked using only public parameters (pkc , pko , pku ) and the proof π. Crucially, Equations (3)-(4) bind the proof to the CS’s secret key through e(π1 , pkc · hc3 ) = e(c4 , π3 ), ensuring the CS cannot forge false results without knowledge of skc . This design eliminates the need for trusted third parties while maintaining verification integrity even when the CS is malicious. These mechanisms work together synergistically. Nonce binding prevents token reuse. Public-key binding prevents transfer. Pairing-based proofs enable verification. They achieve security properties unattainable by individual techniques.

3) Authorization Verification Correctness. For the second verification check: e(pko σ , π3 ) = e(g so ·σ , ht ) = e(g, h)so ·σ·t e(π4 , tok1 ) = e(g t , hso ·σ ) = e(g, h)t·so ·σ Both sides are equal, confirming the validity of the authorization token. 4) Integrity Verification Correctness. For the third verification checks: First integrity check: e(π1 , pkc · hc3 ) = e(hrt , hα+k ) = e(hrt , hα+k ) = e(h(α+k)·r , ht ) = e(c4 , π3 ) Second integrity check: ′

′

′

e(π2 , pkc · hc3 ) = e(hr t , hα+k ) ′

′

= e(h(α+k )·r , ht ) = e(c′4 , π3 ) These checks ensure that the CS used the correct secret key and performed the test honestly. 5) Freshness Verification Correctness. The freshness check π5 = H3 (result||tok1 ||timestamp) ensures that the proof was generated recently and corresponds to the current test result. 6) Decryption Correctness. For the decryption operation: 1

Decrypt(CTdata , sku , rk, pko ) = d ⊕ H2 (e(rk, pko sku )) s ·v

so

= data ⊕ H2 (e(g, g) o ) ⊕ H2 (e(g su ·v , g su )) = data The original data is correctly recovered.

C. Correctness Analysis of Public Verifiability Theorem 1 Correctness: For honestly generated parameters, ciphertexts, tokens and proofs, the AVPKEET scheme satisfies correctness in all its operations. Proof: 1) Equality Test Correctness. For CTkw encrypting key′ encrypting word kw with randomness r and CTkw keyword kw′ with randomness r′ : 1/(skc +c3 )

= (h(α+k)·r )1/(α+k) = hr

′1/(skc +c′3 )

= (h(α+k )·r )1/(α+k ) = hr

E = c4 E ′ = c4

′

′

′

′

When kw = kw′ , we have ′

c2 /c′2 = (g r · H0 (kw))/(g r · H0 (kw′ )) = g r−r

′

since H0 (kw) = H0 (kw′ ). Therefore: ′

′

e(E/E ′ , g) = e(hr−r , g) = e(h, g r−r ) = e(h, c2 /c′2 ) 2) Public Verification Correctness. For the first verification check: ′

′

e(π1 /π2 , g) = e(hrt /hr t , g) = e(h(r−r )t , g) ′

= e(ht , g r−r ) = e(π3 , c2 /c′ 2 ) This correctly verifies whether kw = kw′ when c2 /c′2 = ′ g r−r or kw ̸= kw′ .

V. T HE P ROPOSED AVSE S CHEME While AVPKEET enables authorized and verifiable equality testing on individual ciphertexts, it should be enhanced in the following aspects to be more suitable for practical SE in cloud storage: (i) Index Management: AVPKEET operates on individual keyword ciphertexts without supporting the association between keywords and document collections. AVSE addresses this through the BuildIndex algorithm, which creates encrypted inverted indexes to establish efficient one-to-many keyword-document mappings. (ii) Batch Operations: AVPKEET’s single-ciphertext design becomes inefficient when searching returns multiple documents. AVSE develops BatchP roof Gen and BatchV erif y algorithms to generate and verify proofs for multiple documents with the overhead of a single verification. (iii) Secure Document Retrieval: AVPKEET only returns binary test results, while SE must securely deliver encrypted documents to authorized users. AVSE introduces an auxiliary key mechanism within the GrantAccess algorithm that enables document decryption through the Decrypt algorithm without compromising the DO’s master key. (iv) Fine-grained Access Control: AVPKEET authorizes keyword-level search but cannot restrict access to specific documents under the same keyword. AVSE addresses this through

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

the GrantAccess algorithm, which incorporates access scope parameters (ALL, P ART IAL, SIN GLE) into the token structure, enabling document-level access control enforced by the Search algorithm. In the rest of this section, we first present the developed eight algorithms supporting the above four capabilities. Then we present the workflow of AVSE scheme. A. Algorithm Description 1) Setup(1λ ) → par: TA generates the system parameters. It creates the bilinear groups (G, GT , e) of prime order q with generators g, h ∈ G. The following hash functions are randomly selected: H0 : {0, 1}∗ → G, H1 : Z∗q × Z∗q → Z∗q , λ H2 : GT → {0, 1} , H3 : {0, 1}∗ → Z∗q , H4 : G → {0, 1}λ , ∗ H5 : G × {0, 1} → {0, 1}λ . 2) Register(par, entity type, Attr) → (pk, sk): Each entity runs AVPKEET.KeyGen to generate its key pair (pk, sk). After key generation, entities register with the CS: the DO submits (pko , infoo , Attro ) where Attro ⊆ A is an attribute set from the attribute universe, and the DU submits (pku , Attru ). The CS maintains registration lists DOList and DUList by appending each entry upon registration. 3) BuildIndex(par, pko , pkc , kw, (doc1 , . . . , docm )) → (CTkw , {CTdoc }): The DO builds an encrypted index for keyword kw and its corresponding m documents. The scheme employs an inverted index structure where each keyword kw corresponds to exactly one keyword ciphertext CTkw , regardless of the number of matching documents m. During index construction, the CS stores Indexkw [tagkw ] = CTkw to enable O(1) lookup for the keyword, where tagkw is a deterministic lookup tag derived from kw using a keyed PRF. And for each document it stores an encrypted document index Indexdoc [DocIDi ] = CTdoci . The algorithm first calls the keyword encryption part of AVPKEET.Encrypt to generate the keyword ciphertext and then generates the document list encryption and batch document encryption. First, it generates the keyword ciphertext using AVPKEET.Encrypt. Random values p, k ∈ Z∗q , nonce set Nkw are chosen, and r = H1 (kw, p) is computed. The keyword ciphertext CTkw = (c1 , c2 , c3 , c4 , c5 , c6 ) is generated where c1 = g so ·r , c2 = g r · H0 (kw), c3 = k, c4 = h(α+k)·r , c5 = Nkw and c6 = m represents the document count. Second, the algorithm performs batch document encryption and generates document IDs. For each document doci where i ranges from 1 to m, it chooses a random value vi ∈ Z∗q and computes the document ID DocIDi = H5 (g vi , kw∥i). The encrypted document CTdoci = (d1,i , d2,i ) is generated where d1,i = doci ⊕ H2 (e(g, g)so ·vi ) and d2,i = DocIDi . The document identifier DocIDi embedded in d2,i is used only as a pseudorandom index key so that the CS can later retrieve the corresponding ciphertext via Indexdoc [DocIDi ] during search, without revealing any semantic information about the underlying document. Meanwhile, DO maintains a table indexed by keywords, where each entry stores the tuple (kw, Nkw , {vi }). Data Owner Discovery Mechanism: To facilitate DU-DO discovery in multi-owner scenarios, the CS performs attributebased filtering using the registration lists. When a DU with

9

attribute set Attru requests relevant data owners, the CS returns: DORelevant = {(pko,i , infoi ) | (pko,i , infoi , Attro,i ) ∈ DOList ∧Attru ∩ Attro,i ̸= ∅} That is, a DO is included if and only if it shares at least one common attribute with the requesting DU. ′ 4) BatchP roof Gen(CTkw , CTkw , skc , result, {DocIDi }) → (πbatch ): This algorithm generates verifiable proof for batch search results. It first generates the base proof by calling AVPKEET.P roof , obtaining ′ πbase =AVPKEET.P roof (CTkw , CTkw , skc , result). Then, for each returned document i, it generates document-specific proofs πdoci = H5 (DocIDi |πbase |i) to bind each document to the base proof. Finally, it assembles the batch proof as πbatch = (πbase , πdoc1 , ..., πdocm , m) where m is the number of returned documents. ′ 5) BatchV erif y(πbatch , CTkw , CTkw , token, pkc , pko , pku ) → T /F : This algorithm performs batch verification of search result correctness. It first verifies the base proof using AVPKEET.V erif y. If the base proof verification fails, it immediately returns F . Next, it verifies document integrity by checking each document-specific proof. For each πdoci in the batch proof, it verifies that πdoci = H5 (DocIDi |πbase |i). Finally, it verifies access scope compliance. If tok4 = P ART IAL, it checks that all returned document IDs belong to the authorized set tok5 . If tok4 = SIN GLE, it verifies that only one document was returned. The algorithm outputs T if all checks pass, and F otherwise. 6) Decrypt(CTdoc , {rki }, pko , sku ) → doc: DU uses auxiliary key to compute decrypt key 1 deckey = H2 (e(rki , pkosku )) for doci . doci = di,1 ⊕ deckey . 7) GrantAccess(sko , pku , kw, n, scope, S) → (token, {rki }): This algorithm extends AVPKEET.Authorize to support fine-grained access control where scope ∈ {ALL, P ART IAL, SIN GLE} and S is the set of allowed document IDs when scope = P ART IAL. The algorithm first extends the token generation mechanism of AVPKEET.Authorize to include scope parameters. It chooses τ ∈ Z∗q and computes σ = H3 (kw|pku |n|τ |scope|S). In particular, the access scope parameters (scope, S) are included in the hash input when computing σ = H3 (kw∥pku ∥n∥τ ∥scope∥S), so that any change of scope or document set necessarily changes σ and thus invalidates the authorization token. The base token components tok1 = hso ·σ , tok2 = τ and tok3 = n are generated. Then, the algorithm adds access scope information by setting tok4 = scope, tok5 = S and tok6 = tagkw if scope = P ART IAL, or ⊥ otherwise. The final token is token = (tok1 , tok2 , tok3 , tok4 , tok5 , tok6 ). {rki } are the set of all auxiliary keys corresponding to the documents granted access permissions, where rki = pkuvi . In addition to the cryptographic binding described above, each token carries a timestamp and is associated with a validity window. During Search (and the underlying AuthorizedT est), the CS verifies that the token has not

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

expired; tokens outside the validity window are rejected, even if they have never been used before. Moreover, whenever the DO rebuilds the index for a keyword kw, a fresh nonce nnew (and corresponding timestamp/epoch) is generated. Tokens issued before the rebuild are bound to the old pair (kw, nold ) and cannot be used to search ciphertexts created with the new nonce nnew . This design ensures that previously issued tokens cannot be used for new data, thereby enforcing the intended forward-security property. Note that the DO must track which nonces in Nkw have been consumed, as reissuing a nonce already in Lused would cause the CS to reject a legitimate request. This state is co-located with the per-keyword table (kw, Nkw , {vi }) already maintained by the DO; in the event of state loss, the DO can restore consistency by rebuilding the index with a fresh nonce set via BuildIndex. ′ 8) Search(CTkw , {CTdoc }, token, skc ) → ′ (result, {CTdoc }): The CS performs authorized search. First, it verifies token validity following the same procedure as AVPKEET by checking whether tok3 = n ∈ Nkw for the stored keyword ciphertext and marks the token as used in order to prevent replay attacks. Second, the CS uses the inverted index together with AVPKEET’s testing mechanism. ′ Given the query keyword ciphertext CTkw = (c′1 , c′2 , . . .), the CS performs an O(1) lookup using tok6 in Indexkw to retrieve the unique stored keyword ciphertext CTkw associated with the same keyword (if it exists). It then ′ runs a single equality test between CTkw and CTkw using AVPKEET.AuthorizedT est. If this test fails, the CS returns an empty result set. Third, it filters the results according to the access scope specified in the token. If tok4 = ALL, all matching documents are returned. If tok4 = P ART IAL, only documents with DocID ∈ tok5 are returned. If tok4 = SIN GLE, only the first matching document is returned. For each authorized document identifier DocIDi in the result set, the CS retrieves the corresponding ciphertext ′ via CTdoci ← Indexdoc [DocIDi ] and includes it in {CTdoc }. ′ The final output is the set of matching documents {CTdoc }. B. Technical Enhancements from AVPKEET to AVSE AVSE extends the AVPKEET primitive into a practical searchable encryption system through four technical enhancements: Index Management. The BuildIndex algorithm establishes efficient one-to-many mappings by storing Indexkw [H4 (c2 )] = CTkw for keyword lookup and Indexdoc [DocIDi ] = CTdoci for document retrieval. This enables the Search algorithm to perform a single equality test per keyword query rather than testing against all stored ciphertexts, achieving O(1) search complexity. Batch Operations. The BatchP roof Gen algorithm generates document-specific proofs πdoci = H5 (DocIDi |πbase |i) that bind each returned document to the base equality test proof. The BatchV erif y algorithm verifies all documents through a single base proof verification plus lightweight hash checks, reducing verification overhead from O(m) pairing operations to O(m) hash operations plus one base verification. Secure Document Retrieval. The GrantAccess algorithm generates auxiliary keys {rki = pkuvi } that enable autho-

10

rized users to decrypt documents without exposing the data owner’s master key sko . During decryption, the user computes 1/sk e(rki , pko u ) = e(g su ·vi , g so /su ) = e(g, g)so ·vi using only their own secret key, recovering the document via doci = di,1 ⊕ H2 (e(g, g)so ·vi ). Fine-grained Access Control. Fine-grained access control is achieved by embedding scope parameters (scope, S) into the token generation: σ = H3 (kw||pku ||n||τ ||scope||S). This cryptographic binding ensures that modifying the access scope invalidates the token, as it would require computing tok1 = ′ hsko ·σ for a different σ ′ . VI. S ECURITY A NALYSIS This section summarizes the security of AVSE. Complete formal proofs are provided in the supplementary material. A. Security Theorems The following theorems are proven in the supplementary material: Theorem 1 (Keyword Ciphertext One-Wayness): If the DBDH assumption holds, then AVSE achieves OW-CCA2 security. OW −CCA2 Adv{AV SE,A} (λ) ≤ negl(λ) Theorem 2 (Authorization Unforgeability): If the OneMore co-CDH assumption holds, then adversaries cannot forge valid tokens. AU Adv{AV SE,A} (λ) ≤ negl(λ)

Theorem 3 (Token Non-transferability): If AVSE achieves Authorization Unforgeability (Theorem 2), then tokens cannot be transferred to unauthorized users. TN Adv{AV SE,A} (λ) ≤ negl(λ)

Proof Sketch. Suppose adversary A obtains a valid token issued to user pku and attempts to use it as a different user pku′ ̸= pku . Case 1: If A uses the original token unmodified, verification reconstructs σ ′ = H3 (kw||pku′ ||tok3 ||tok2 ||tok4 ||tok5 ), which differs from the original σ since pku′ ̸= pku . The authorization check ′ ? e(pkoσ , π3 ) = e(π4 , tok1 ) fails because tok1 = hso ·σ ̸= ′ hso ·σ . Case 2: If A modifies the token, it must compute ∗ tok1∗ = hso ·σ for a fresh σ ∗ = H3 (kw||pku′ || · · · ) without knowing so . We construct an AU adversary B that simulates the environment for A and outputs (token∗ , pku′ , kw, n) as its forgery whenever A succeeds. The full proof is provided in the supplementary material (Theorem 3). Theorem 4 (Public Verifiability): If the BDH assumption holds, then malicious cloud servers cannot forge false proofs, even with keyword knowledge. PV Adv{AV SE,A} (λ) ≤ negl(λ)

Theorem 5 (Fine-grained Access Control): If AVSE achieves Authorization Unforgeability (Theorem 2), then users can only access documents within their authorized scope. F AC Adv{AV SE,A} (λ) ≤ negl(λ)

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

11

TABLE III U SED N OTATION FOR P ERFORMANCE A NALYSIS Notation Exp P air M ult Hash XOR RSAExp P rimeGen Enc Dec OT S.sign OT S.verif y

Description Exponentiation operation in group G Bilinear pairing operation e : G × G → GT Multiplication operation in group G Hash function operation Bitwise exclusive-or operation RSA exponentiation operation Large prime generation for RSA Symmetric encryption operation Symmetric decryption operation One-time signature signing One-time signature verification

Proof Sketch. Suppose adversary A holds a token for scope (scope, Sauth ) and attempts to access DocIDi∗ ∈ / Sauth . Case 1: If A uses the original token unmodified, BatchV erif y performs a deterministic scope compliance check: when tok4 = P ART IAL, it verifies DocIDi∗ ∈ tok5 = Sauth , which fails by assumption. Case 2: If A modifies the scope parameters to (scope∗ , S ∗ ) ̸= (scope, Sauth ), the reconstructed σ ∗ = H3 (kw||pku || · · · ||scope∗ ||S ∗ ) differs from the original σ, and passing the authorization check requires computing ∗ tok1∗ = hso ·σ for a fresh σ ∗ without so . We construct an AU adversary B that outputs (token∗ , pku , kw, n) as a forgery. The full proof is provided in the supplementary material (Theorem 5). Theorem 6 (Forward Security): If the One-More co-CDH assumption holds, then previously issued tokens cannot be used to access newly uploaded data. FS Adv{AV SE,A} (λ) ≤ negl(λ)

Proof Sketch. Suppose DO issues token0 with nonce n0 at time t0 (validity window [t0 , t1 ]), and later rebuilds the index with fresh nonce n2 at time t2 > t1 . Adversary A attempts to use token0 to search new data. Case 1 (Nonce mismatch): ? ? AuthorizedT est checks tok3 = c′5 , i.e., n0 = n2 . Since n2 is freshly random, this fails with overwhelming probability 1 − 1/|Zq |. Case 2 (Timestamp expiry): The validity check rejects token0 when tcurrent > t1 . Case 3 (Token modification): If A forges token∗ with tok3∗ = n2 , this requires ∗ computing tok1∗ = hso ·σ for σ ∗ = H3 (kw||pku ||n2 || · · · ) ̸= σ0 , which reduces to AU. We construct B that outputs (token∗ , pku , kw, n2 ) as a forgery. The full proof is provided in the supplementary material (Theorem 6). Theorem 7 (Collusion Resistance): If the One-More coCDH assumption and the DBDH assumption hold, then colluding cloud servers and data users cannot bypass authorization controls or decrypt unauthorized documents, even when the adversary possesses skc and corrupted users’ keys {sku }. CR Adv{AV SE,A} (λ) ≤ negl(λ)

VII. P ERFORMANCE A NALYSIS This section presents performance evaluation of AVPKEET and AVSE from two aspects: theoretical analysis and experimental validation. Table III summarizes notation to use.

Notation |G| |GT | |Zq | |N | |e|, |d| |OT S.sig| |Enc| N |DB[w]| |S| |U |

Description Size of an element in group G Size of an element in group GT Size of an element in Zq Size of RSA modulus Size of RSA public/private exponents Size of one-time signature Size of encrypted document Number of keyword-document pairs Number of documents matching keyword w Size of attribute set (for scheme [26]) Size of user attribute universe (for scheme [26])

A. Theoretical Analysis 1) AVPKEET Primitive: We compare AVPKEET with six representative PKEET schemes, analyzing their computational and communication costs. Table IV and Table V present the detailed comparison results for computational and communication overhead, respectively. We observe that AVPKEET scheme uniquely provides both authorization control and public verification. Scheme [12] achieves minimal design but provides neither authorization nor verification. While scheme [9] also offers verification capability with four Pair operations, it completely lacks authorization mechanisms, allowing any entity to perform equality tests. Schemes [15], [16], and [17] introduce authorization features with varying costs, but none provides verification mechanisms. The RSA-based scheme [18] suffers from prohibitive computational overhead with 4P rimeGen operations. During the authorization phase, we require only 1Exp + 1Hash operations while providing one-time, non-transferable tokens. For verification, although our scheme requires 6P air operations compared to 4P air in scheme [9], this additional overhead enables authorization control alongside verification. The ciphertext size remains comparable to other elliptic curve schemes and significantly smaller than RSA-based [18] and GT-based [16] schemes. Additionally, our scheme maintains minimal public key storage. 2) AVSE Scheme: We evaluate the AVSE scheme against existing PKEET-based schemes to demonstrate its practical advantages for cloud storage applications. For fair comparison, we focus on single-keyword scenarios, as multi-keyword search introduces additional complexity beyond the scope of this analysis. Note that scheme [25] employs attribute-based encryption (ABE), where performance metrics depend on the user attribute set size and the total attribute universe, which we denote in our analysis for completeness. Table VI shows that AVSE achieves acceptable performance while providing both authorization and verification. During Setup and Index Building, AVSE maintains moderate overhead (1Exp + 1Hash and 5Exp + 1Hash + 1Enc), balancing between the lightweight scheme [26] and the feature-rich ABE scheme [25]. The critical advantage emerges in Token Generation, where AVSE requires only 3Exp + 2Hash to generate one-time, non-transferable tokens with fine-grained access control. In contrast, scheme [22]’s reusable tokens are

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

12

TABLE IV C OMPARISON OF C OMPUTATIONAL OVERHEAD OF PKEET S CHEMES scheme [12]2010 [16]2023 [15]2024 [9]2024 [18]2024 [17]2025 ours AVPKEET

Encrypt 3Exp + 1Hash + 1XOR 3Exp + 1P air + 1M ult 4Exp + 1Hash 4Exp + 2M ult + 1Hash 2RSAExp + 3Hash + 2XOR 5Exp + 1OT S.Sign + 1Hash 4Exp + 1M ult + 1Hash

Authorize — 0 0 — 1RSAExp + 1Hash 2Exp 1Exp + 1Hash

AuthorizedTest 2P air 2P air + 1Exp 4Exp 2Exp + 1P air 2RSAExp + 2Hash + 2XOR 2Exp 2Exp + 1P air

Proof — — — 4Exp + 1Hash — — 4Exp + 1Hash

Verify — — — 4P air + 1Hash — — 6P air + 1Exp + 2Hash

Decrypt 1Exp + 1Hash + 1XOR 2P air + 1Exp 2Exp 1P air + 1Exp 2RSAExp + 3Hash + 2XOR 2Exp + 1OT S.V rf + 1Hash 1P air + 1Exp

TABLE V C OMPARISON OF C OMMUNICATION OVERHEAD OF PKEET S CHEMES Scheme [12]2010 [16]2023 [15]2024 [9]2024 [18]2024 [17]2025 ours AVPKEET

Ciphertext 2|G| + 2|Zq | 3|G| + 1|GT | 4|G| 4|G| + 1|Zq | 2|N | 3|G| + |OT S.sig| 4|G| + 2|Zq |

Token — 1|Zq | 2|Zq | — |N | + |d| 2|G| 1|G| + 2|Zq |

Proof — — — 4|G| + 2|Zq | — — 4|G| + 3|Zq |

Public Key 1|G| 2|G| + 1|GT | 2|G| 1|G| 2|N | + 2|e| 3|G| 1|G|

TABLE VI C OMPARISON OF C OMPUTATIONAL OVERHEAD OF SE S CHEMES BASED ON PKEET Scheme [24]2022 [25]2023 [26]2024 [22]2025 ours AVSE

Setup 2P air + 3Exp 5Exp + 2P air 1Exp + 7Hash 2Exp + 2Hash 1Exp + 1Hash

Index Building O(N ) · (2P air + 4Exp + 2Hash) O(N ) · (8Exp + 1Enc) O(N ) · (2Exp + 2Hash + 1Enc) O(N ) · (4Exp + 2Hash + 1Enc) O(N ) · (5Exp + 1Hash)

Token Generation 3Exp + 1Hash 6Exp 3Exp + 3Hash 2Exp + 1Hash 3Exp + 2Hash

Search O(|DB[w]|) · (2P air + 1Exp) O(|DB[w]|) · 1P air O(|DB[w]|) · (3Exp + 2Hash) O(|DB[w]|) · (2P air + 1Exp) O(|DB[w]|) · (3Exp + 2P air)

Decryption 1P air + 1Exp + 2M ult 2P air + O(|S|) · Exp 2Exp + 2Hash + 1XOR 1Dec + 1Hash 1P air + 1Exp

Note: In AVSE, the Search complexity consists of three parts: (i) O(1) index lookup to locate CTkw using tagkw , (ii) one equality test (2Exp + 1P air) to verify the keyword match, and (iii) O(|DB[w]|) lightweight hash operations to verify document integrity. The expensive pairing operations (6 pairings total in verification) are executed once per keyword query, not per document. TABLE VII C OMPARISON OF C OMMUNICATION OVERHEAD OF SE S CHEMES BASED ON PKEET Scheme [24]2022 [25]2023 [26]2024 [22]2025 ours AVSE

Index Storage O(N ) · (2|GT | + 4|G| + |Enc|) O(N ) · (3|GT | + 5|G| + |Enc|) O(N ) · (2|G| + |Zq | + |Enc|) O(N ) · (2|G| + |GT | + |Enc|) O(N ) · (4|G| + 2|Zq | + |Enc|)

Token Size 3|G| O(|S|) · |G| 3|G| + |Zq | 2|G| + |Zq | 1|G| + 2|Zq |

vulnerable to replay attacks, while scheme [25] incurs 6Exp overhead proportional to attribute sets. Table VII reveals that AVSE maintains competitive communication overhead despite additional security features. The index storage O(N )(4|G| + 2|Zq | + |Enc|) is comparable to existing schemes, while the token size (1|G| + 2|Zq |) remains compact. B. Experimental Setup To validate our theoretical analysis, we implemented AVSE and comparison schemes on a real platform. The experiments were conducted on a server running Ubuntu 20.04.5 LTS equipped with a 2.2GHz AMD Ryzen Threadripper 3970X 32-Core Processor (64 logical cores) and 251GB RAM. The implementation uses C++ with the PBC library (PairingBased Cryptography) version 0.5.14, which provides efficient implementations of bilinear pairing operations. We employ the Type-A pairing with an embedding degree of 2, where the base field size is 512 bits and the group order is 160 bits. For cryptographic operations, we obtained: Exp = 2.31ms for exponentiation in G, P air = 5.85ms for bilinear pairing,

Search Result O(|DB[w]|) · |Enc| O(|DB[w]|) · |Enc| O(|DB[w]|) · |Enc| O(|DB[w]|) · |Enc| O(|DB[w]|) · |Enc|

Public Key 2|GT | + 3|G| 2|GT | + O(|U |) · |G| 2|G| 2|G| 1|G|

M ult = 0.012ms for group multiplication, Hash = 0.008ms using SHA-256, and XOR = 0.001ms for bitwise operations. Enc = 0.015ms and Dec = 0.014ms for AES-256 symmetric encryption/decryption. RSA-based operations show significantly higher costs with RSAExp = 15.7ms for 2048bit modulus and P rimeGen = 486ms for generating 1024bit primes. For one-time signatures, we implemented Lamport signatures yielding OT S.sign = 1.42ms and OT S.verif y = 0.71ms. Regarding storage overhead, we measured: |G| = 128bytes for elliptic curve points, |GT | = 128bytes for target group elements, |Zq | = 20bytes for field elements, |N | = 256bytes for RSA modulus, |e|, |d| = 256bytes for RSA exponents and |OT S.sig| = 640bytes for Lamport signature size. These measurements form the basis for our subsequent performance evaluation. C. Performance Evaluation 1) AVPKEET Primitive: In Fig. 3(a)-(g), a comprehensive comparison of computational and communication costs for

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

10

5.3

8.2

8.2

4.6

2

] Ou rs

]

[12

]

[18

[17

]

N/A N/A N/A N/A N/A N/A

] [9]

] Ou rs

]

[12

]

[18

]

[16

[15

[17

] [9]

0

[16

4.6

2.3

[17

] [9] [15 ] [16 ] [18 ] [12 ] Ou rs

2.25 2.09 2.00 1.75 1.50 1.50 1.39 1.18 1.25 1.00 0.79 0.89 0.75 0.41 0.50 0.25 0.00

[17

Ou

4

] [9] [15 ] [16 ] [18 ] [12 ] Ou rs

14.0

15

0

rs

]

[12

]

]

[16

[15

[17

20

5

N/A N/A N/A N/A

[18

N/A

25

Size (KB)

Time (ms)

23.4

6

(g) Communication Overhead

31.4

30

11.7 10.5

0

(f) Decryption Time

35

37.4

5

N/A

10.5 9.2

14.0

[15

Time (ms)

[17

] [9]

] Ou rs

]

[12

]

[18

]

[16

[15

(e) Verification Time

]

40 35 30 25 20 15 10 5 0

] [9]

Time (ms)

[17

] [9]

0

2.3 N/A N/A N/A

15 10

9.2

8

20

] Ou rs

6.9

5

4.6

]

9.3

(d) Proof Generation Time

10

31.4

25

[12

12.8

]

9.3 9.2

[18

10

]

15 13.0

[15

20

(c) Authorized Test Time

30

[16

Time (ms)

25

35

15.7

16 14 12 10 8 6 4 2 0

Time (ms)

(b) Authorization Time

31.4

30

Time (ms)

AVPKEET Primitive Performance Evaluation

(a) Encryption Time

35

13

Fig. 3. AVPKEET Primitive Performance Evaluation: (a) Encryption Time, (b) Authorization Time, (c) Authorized Test Time, (d) Proof Generation Time, (e) Verification Time, (f) Decryption Time, (g) Communication Overhead

AVSE System Performance Evaluation

(a) Index Building Time

103

6.95

6

6.95

6.94

4.63

Time (ms)

8

4 102

102

2 101

102

Number of Keyword-Document Pairs (N)

101

0

103

[22] AVSE(ours) [24]

(d) Decryption Time 8.184

[26]

100

101

14.010

103

4.637

100

102

103

Number of Matching Documents (|DB[w]|)

(f) Token Size

[22] AVSE(ours) [24] [25] [26]

400

384

404

350 300

Size (bytes)

8.160

101

[25]

(e) Index Storage Overhead

Storage (KB)

102

Time (ms)

[22] AVSE(ours) [24] [25] [26]

10

103

102

10 1

276

250 200 150

220 168

100 50

0.022 10 2

(c) Search Time

13.86

12

Time (ms)

Time (ms)

104

(b) Token Generation Time

14

[22] AVSE(ours) [24] [25] [26]

[22] AVSE(ours) [24]

[25]

[26]

101

102

Number of Keyword-Document Pairs (N)

103

0

[22] AVSE(ours) [24]

[25]

[26]

Fig. 4. AVSE Scheme Performance Evaluation: (a) Index Building Time, (b) Token Generation Time, (c) Search Time, (d) Decryption Time, (e) Index Storage Overhead, (f) Token Size

AVPKEET schemes is presented. Given that schemes [15], [16], and [12] lack authorization mechanisms, and schemes [15], [16], [17], [18], [12] do not support verification, the test results exclusively showcase the costs for operations they support. Compared to other equality testing schemes, our scheme exhibits moderate increases in encryption and test costs while providing both authorization and verification

capabilities. While the costs of our scheme are higher 33.5% than [12] for encryption, but [12] lacks both authorization and verification. our scheme offers essential security functionalities with the added benefit of transferring the verification burden to the DU. The authorization overhead of our scheme (2.318ms) is significantly lower than schemes [17] and [18], representing

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

49.8% and 85.2% reductions respectively. Despite our scheme incurring verification cost (37.426ms) compared to schemes without verification capability, the inclusion of a verifiable function enhances the security of our scheme. In addition, our encryption computation overhead is comparable to that of [9] and [15], with only 0.13% differences respectively. Fig. 3(g) also indicates that our communication costs are moderate, especially when compared with schemes [17], [9], and [18], the communication cost of our proposal is respectively 7.55%, 17.16%, and 30.66% lower than those three schemes. 2) AVSE Scheme: In Fig. 4(a)-(f), the computational and communication cost comparisons of schemes are presented. For index building (Fig. 4(a)), AVSE demonstrates competitive performance with O(N ) scaling. When N = 1000, AVSE requires 11560.32ms, which is 24.6% higher than [22] but 44.9%, 37.6%, and 148.4% lower than schemes [24], [25], and [26] respectively. This moderate overhead enables fine-grained access control and public verification capabilities absent in compared schemes. The token generation cost (Fig. 4(b)) shows AVSE at 6.946ms, representing a 50.1% increase over [22] but 49.9% lower than scheme [25]. More importantly, AVSE’s tokens are one-time and non-transferable, preventing replay attacks that plague reusable token schemes. The token size (Fig. 4(f)) of AVSE is 168bytes, achieving 39.1%, 56.3%, 23.8%, and 58.4% reductions compared to [22], [24], [25], and [26] respectively, demonstrating superior communication efficiency. In the search phase (Fig. 4(c)), our scheme exhibits slightly higher cost than schemes such as [22] and [24], while remaining significantly lower than the costs associated with complex attribute-based scheme [25]. When |DB[w]| = 100, AVSE requires 1863ms, which is 33.0% higher than [22]. However, this overhead includes proof generation for result verification, a critical feature for untrusted cloud environments that other schemes except [25] cannot provide. The storage overhead analysis (Fig. 4(e)) reveals that AVSE maintains reasonable scalability. With N = 1000, AVSE requires 1515.62KB, only 12.2% higher than [22] and 21.5% higher than the most storage-efficient scheme [26]. This moderate increase is justified by the additional metadata supporting authorization and verification mechanisms. Given the significant impact of security features on the implementation of cloud storage systems, our experimental analysis confirms that AVSE successfully balances performance and security. VIII. C ONCLUSION This paper proposed AVSE for cloud storage, a novel SE scheme that simultaneously offers authorization control and public verification, which lacked in existing PKEETbased SE schemes. Under our scheme, the CS can perform authorized equality tests on encrypted data and generate publicly verifiable proofs without decryption. Meanwhile, DOs can grant fine-grained access through one-time, nontransferable tokens to prevent authorization abuse. The scheme enables secure search operations directly on encrypted data and returns verifiable results. We have demonstrated that

14

the proposed scheme satisfies OW-CCA2 security under a standard high min-entropy assumption, token unforgeability, and verification soundness. Finally, AVSE has been compared with previous studies and the analysis shows our scheme is efficient—maintaining the most compact token size while uniquely providing both authorization and verification capabilities. Nevertheless, AVSE has several limitations that present opportunities for future research. The scheme currently supports only single-keyword queries and static document collections. Additionally, like most efficient public-key searchable encryption schemes, AVSE reveals search patterns and access patterns to the cloud server, which represents a common efficiency-security trade-off. Future work will extend AVSE with multi-keyword Boolean search and dynamic operations while maintaining authorization and verification properties. We will also explore pattern leakage mitigation techniques such as Oblivious RAM constructions and dummy query padding.

R EFERENCES [1] T. Le, R. Behnia, J. Guajardo, and T. Hoang, “Muses: Efficient multiuser searchable encrypted database,” Conference of USENIX Security Symposium, 2024. [2] K. Zhang, X. Wang, J. Ning, M. Wen, and R. Lu, “Multi-client boolean file retrieval with adaptable authorization switching for secure cloud search services,” IEEE Transactions on Dependable and Secure Computing, vol. 20, no. 6, pp. 4621–4636, 2022. [3] P. Xu, W. Susilo, W. Wang, T. Chen, Q. Wu, K. Liang, and H. Jin, “Rose: Robust searchable encryption with forward and backward security,” IEEE transactions on information forensics and security, vol. 17, pp. 1115–1130, 2022. [4] Y. Xu, H. Cheng, X. Liu, C. Jiang, X. Zhang, and M. Wang, “Pcse: Privacy-preserving collaborative searchable encryption for group data sharing in cloud computing,” IEEE Transactions on Mobile Computing, vol. 24, no. 5, pp. 4558–4572, 2025. [5] L. Yang, Y. Yang, D. Niyato, Z. Li, W. Xia, and L. Sun, “Dynamic searchable symmetric encryption with efficient and complete access control for multi-user cloud computing,” IEEE Transactions on Mobile Computing, 2025. [6] L. Ji, J. Li, Y. Zhang, and Y. Lu, “Verifiable searchable symmetric encryption over additive homomorphism,” IEEE Transactions on Information Forensics and Security, vol. 20, pp. 1320–1332, 2025. [7] J. Li, L. Ji, Y. Zhang, Y. Lu, and J. Ning, “Response-hiding and volume-hiding verifiable searchable encryption with conjunctive keyword search,” IEEE Transactions on Computers, vol. 74, no. 2, pp. 455–467, 2024. [8] B. Chen, T. Xiang, D. He, H. Li, and K.-K. R. Choo, “Bpvse: Publicly verifiable searchable encryption for cloud-assisted electronic health records,” IEEE Transactions on Information Forensics and Security, vol. 18, pp. 3171–3184, 2023. [9] W. Li, W. Susilo, C. Xia, L. Huang, F. Guo, and T. Wang, “Secure data integrity check based on verified public key encryption with equality test for multi-cloud storage,” IEEE transactions on dependable and secure computing, vol. 21, no. 6, pp. 5359–5373, 2024. [10] J. Yu, W. Shen, and x. Zhang, “Cloud storage auditing and data sharing with data deduplication and private information protection for cloudbased emr,” Computer Security, vol. 144, p. 103932, 2024. [11] S. Ma, Q. Huang, M. Zhang, and B. Yang, “Efficient public key encryption with equality test supporting flexible authorization,” IEEE Transactions on Information Forensics and Security, vol. 10, no. 3, pp. 458–470, 2014. [12] G. Yang, C. H. Tan, Q. Huang, and D. S. Wong, “Probabilistic public key encryption with equality test,” in Cryptographers’ track at the RSA conference. Springer, 2010, pp. 119–131. [13] Q. Tang, “Towards public key encryption scheme supporting equality test with fine-grained authorization,” in Australasian conference on information security and privacy. Springer, 2011, pp. 389–406.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021

[14] S. Ma, “Authorized equality test of encrypted data for secure cloud databases,” in 2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE). IEEE, 2018, pp. 223–230. [15] Y. Ling, “Tightly secure public key encryption with equality test in setting with adaptive corruptions,” IEEE Access, vol. 12, pp. 115 268– 115 276, 2024. [16] Z. Zhao, W. Susilo, B. Wang, and K. Zeng, “Public-key encryption with tester verifiable equality test for cloud computing,” IEEE Transactions on Cloud Computing, vol. 11, no. 4, pp. 3396–3406, 2023. [17] Y.-F. Tseng, Y.-J. Lu, T.-L. Tsai, and Z.-Y. Liu, “Tightly secure publickey encryption with equality test supporting flexible authorization in the standard model,” Cryptology ePrint Archive, 2025. [18] C. Park, S. Choi, Y. Son, J. Paek, S. Cho, and H. T. Lee, “New rsabased public key encryption with authorized equality test,” in 2024 International Conference on Information Networking (ICOIN). IEEE, 2024, pp. 299–304. [19] P. S. Roy, D. H. Duong, W. Susilo, A. Sipasseuth, K. Fukushima, and S. Kiyomoto, “Lattice-based public-key encryption with equality test supporting flexible authorization in standard model,” Theoretical Computer Science, vol. 929, pp. 124–139, 2022. [20] S. Ma, Y. Zhong, and Q. Huang, “Efficient public key encryption with outsourced equality test for cloud-based iot environments,” IEEE Transactions on Information Forensics and Security, vol. 17, pp. 3758– 3772, 2022. [21] J. Tian, Y. Lu, and J. Li, “Lightweight searchable and equality-testable certificateless authenticated encryption for encrypted cloud data,” IEEE Transactions on Mobile Computing, vol. 23, no. 8, pp. 8431–8446, 2024. [22] K. Zhang, B. Hu, J. Ning, J. Gong, and H. Qian, “Pattern hiding and authorized searchable encryption for data sharing in cloud storage,” IEEE Transactions on Knowledge and Data Engineering, vol. 37, no. 5, pp. 2802–2815, 2025. [23] J. Li, X. Lin, Y. Zhang, and J. Han, “Ksf-oabe: Outsourced attributebased encryption with keyword search function for cloud storage,” IEEE Transactions on Services Computing, vol. 10, no. 5, pp. 715–725, 2016. [24] Y. Hu, S. Niu, and H. Shao, “Attribute-based searchable encryption with delegated equality test in cloud-assisted internet of things,” in 2022 3rd International Conference on Electronics, Communications and Information Technology (CECIT). IEEE, 2022, pp. 328–333. [25] H. Xiong, H. Wang, W. Meng, and K.-H. Yeh, “Attribute-based data sharing scheme with flexible search functionality for cloud-assisted autonomous transportation system,” IEEE Transactions on Industrial Informatics, vol. 19, no. 11, pp. 10 977–10 986, 2023. [26] W. Li, “Multi-receiver data authorization with data search for data sharing in cloud-assisted iov,” IEEE Transactions on Intelligent Transportation Systems, vol. 25, no. 5, pp. 4233–4250, 2024. [27] W. Li, C. Xia, S. Yang, K. Wang, G. Huang, L. Huang, F. Guo, W. Susilo, and T. Wang, “Fine-grained access control with privacypreserving data retrieval for cloud-assisted iov,” IEEE Transactions on Vehicular Technology, 2025. [28] Y. Zhou, Z. Cao, X. Dong, and J. Zhou, “Bldss: A blockchainbased lightweight searchable data sharing scheme in vehicular social networks,” IEEE Internet of Things Journal, vol. 10, no. 9, pp. 7974– 7992, 2022. [29] D. Boneh and M. Franklin, “Identity-based encryption from the weil pairing,” SIAM journal on computing, vol. 32, no. 3, pp. 586–615, 2003. [30] D. Boneh and X. Boyen, “Secure identity based encryption without random oracles,” in Annual International Cryptology Conference. Springer, 2004, pp. 443–459. [31] Bellare, Namprempre, Pointcheval, and Semanko, “The one-more-rsainversion problems and the security of chaum’s blind signature scheme,” Journal of Cryptology, vol. 16, no. 3, pp. 185–215, 2003. [32] C. Liu, L. Zhu, M. Wang, and Y.-a. Tan, “Search pattern leakage in searchable encryption: Attacks and new construction,” Information Sciences, vol. 265, pp. 176–188, 2014. [33] S. Oya and F. Kerschbaum, “Hiding the access pattern is not enough: Exploiting search pattern leakage in searchable encryption,” in 30th USENIX security symposium (USENIX Security 21), 2021, pp. 127–142. [34] E. Stefanov, M. Van Dijk, E. Shi, C. Fletcher, L. Ren, X. Yu, and S. Devadas, “Path oram: an extremely simple oblivious ram protocol,” in Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security, 2013, pp. 299–310.

15