1 Introduction

With the emergence of big data and its applications [1–5], cloud computing is becoming increasingly important and popular for the Smart Device Client (SDC). Since sensitive user information can be easily hacked, such information is encrypted on the SDC side and then outsourced to the cloud. It has become increasingly important to compute encrypted data stored on the remote cloud and untrusted servers due to data outsourcing and increasing user awareness of data privacy [6–8]. In the realm of searchable encryption, the process involves extracting and preserving an encrypted database at the Cloud Service Provider (CSP) and maintaining a local database on the client’s device. A significant challenge arises from the expansion of the local database with the overall growth of the dataset, necessitating increased client storage capacity. Previous research faced complexities in achieving both backward security and maintaining consistent client storage, attributed to clients’ incapacity to transfer data to the CSP, posing potential data leakage risks. Despite existing schemes facilitating retrieval functions on devices, persistent storage overhead remains. Ongoing research focuses on aligning storage overhead with cloud retrieval efficiency while ensuring security, aiming to optimize device performance. The model, denoted as the semi-trusted server, involves the sharing of a database among multiple parties. In this context, certain segments of the data are designated as trusted, while other portions are categorized as untrusted. Servers that are honest but curious should learn as little as possible about SDCs’ data and queries during processing. In the case of this application, an untrusted cloud server is used to store the collections of documents that a client manages using Searchable Symmetric Encryption (SSE). It would also be advantageous if the SDC could query the server and obtain all the records that match their search. This is one of the objectives of the Searchable Symmetric Encryption (SSE) protocol, which is to offer client the ability to carry out those operations while providing the host server precise guarantees about the privacy of the client’s data and queries. This work [9–12] is considered one of the most basic data operations and the research community introduced keywords to search in the ciphertext. Using the static database [13–19], the user uploads their documents to a semi-trusted server for searching and then issues the server search tokens without disclosing sensitive data. Creating, updating, and deleting records are not supported by static SSE.

After this, the researchers turned their attention to Dynamic SSE (DSSE) [20–26]. Secure DSSE schemes are challenging, from a security perspective, because database updates may reveal additional information to the server. Forward and backward privacy has been proposed as an essential security notion for dynamic SE schemes. The forward privacy property [27, 28] prevents a new update from being associated with previous operations (until the keyword matching the existing operation is searched). Many DSSE schemes are not as secure as they should be if an adversary knows something about the added documents, as has been demonstrated by file-injection attacks [29]. To reduce the risk of file-injection attacks [29], forward privacy is crucial. In order for DSSE schemes to avoid such attacks, forward security is essential, meaning that the server cannot find a link between newly added documents and prior search tokens [27]. As a result, we propose a forward-secure DSSE scheme that can achieve these goals.

Another privacy concept, backward privacy property, ensures that if a search is performed for keyword w after a document containing w is deleted, it does not reveal anything about the deleted document. Although this property was mentioned in [28] neither actual constructions nor a formal definition were presented. Bost et al. [30] provided the first formal definition of the concept of backward privacy, in which three types of leakage were described: Type-I, Type-II, and Type-III.

In an era where privacy concerns are paramount, the demand for secure methods to perform searches over encrypted data has escalated. Building upon this premise, our dynamic DSSE scheme emerges as a robust solution, ensuring not only the confidentiality of sensitive information but also the efficiency required for real-world applications. This paper delves into the intricacies of our proposed scheme, highlighting its unique features and advantages over existing approaches. The computational cost of query generation and the high storage requirements are challenges that most of the current schemes suffer from, as stated in Table 1, and it is still a difficulty that requires a solution for SDC. Constant storage cost for Smart Device Clients (SDCs) in the DSSE scheme addresses the challenge of efficient and secure keyword search on encrypted data, ensuring optimal performance in resource-limited smart devices across diverse applications.

We propose a scheme based on an inverted index structure presented in pairs (key, value) with control, to retrieve the required encrypted value without needing an SDC-side keyword counter to ensure security, efficiency, and less computational load on the SDC side. Researchers previously faced challenges in achieving constant client storage with backward and forward privacy. Client cannot transfer local storage to the cloud server, which can cause major leakage problems. Thus, we propose an efficient solution to address this issue. For retrieving values from the encrypted inverse index for a specific keyword, the client generates a token based on the keyword and its private key then sends the token to the cloud server. The random value is generated when a keyword is added as a link between the encrypted values of the same keyword in the index, obviating the requirement for an SDC-side keyword counter. The first value of that keyword is extracted from the encrypted index using a token that the SDC gives to the server. With the help of the random value, we can then access the next encrypted value, and so on. In order that the adversary server cannot establish a connection between the keywords that were added and deleted afterwards, the results are returned to the client as encrypted values (backward privacy). As a result, our scheme would efficiently store the constant SDC, as well as low query generation costs, with forward and backward security, as discussed later. The proposed DSSE scheme with constant storage cost for Smart Device Clients (SDCs) holds significant potential in real-world scenarios where privacy-preserving keyword search on encrypted data is vital. Applications include secure cloud storage, healthcare systems, and confidential communication platforms, ensuring data privacy on resource-constrained smart devices.

In summary, the contributions of this work are as follows:

1. Our scheme is the first DSSE framework that is efficient and secure and has a constant storage cost to fulfil the needs of an SDC. Furthermore, our scheme is almost theoretically and practically optimal, with respect to its computational complexity during the search and update processes. As shown in Table 1, it compares well with previous schemes. The scalability of the Dynamic Searchable Symmetric Encryption (DSSE) scheme is pivotal for practical utility in environments with expanding datasets and numerous keywords. Evaluation of our scheme reveals commendable scalability in client storage, as the storage cost remains constant regardless of database size. Computational costs exhibit constancy during query generation, independent of document or keyword numbers, enhancing scalability. Efficient search performance is maintained with a growing database, emphasizing the scheme’s focus on reducing search costs.
2. To the best of our knowledge, our scheme is the only DSSE framework to offer a constant ongoing client storage cost; furthermore, we prove that our system is secure versus semi-trusted adversaries.
3. Using Forward Privacy, new search tokens are generated using a one-time key. It is no longer possible for the server to infer if a previously searched keyword appears in newly added documents by linking previous search tokens with subsequent update tokens.
4. Type-II Backward Privacy. In this case, the server cannot see the update operations (delete or add) during the fulfilling of update queries. SDC-side refinement is performed on deleted documents. Previously searched results are stored on the server in plain text. In this case, re-encrypting such results will not provide any security advantage since they have already been leaked to the server. A further benefit is that plain text results can be read continuously, thereby enhancing the locality.
5. The proposed Dynamic Searchable Symmetric Encryption (DSSE) scheme achieves a remarkable query generation time of 6,460 nanoseconds, ensuring real-time responsiveness and minimal computational overhead. This efficiency, coupled with reduced server-side search costs, enhances user experience, resource utilization, and scalability in applications like secure cloud storage and encrypted messaging systems, showcasing the scheme’s practicality, efficiency, and responsiveness in real-world scenarios.

Our scheme provides keyword generation with low computing overheads O(o′_w+LCon), which is compatible with source-constrained devices.

2 Related work

Song et al. [9] introduced static Searchable Symmetric Encryption (SSE) with a linear search time construction. Curtmola et al. [13] formally defined the security of SSE schemes for the first time. In particular, they developed the first inverted index that kept a list of document identifiers per keyword, which resulted in a sublinear search time. Researchers [16, 18, 31–33] also studied the static case, in which encrypted databases are stored on cloud server where they cannot be changed after they are stored. According to Cash and Tessaro [15], locality, space overhead, and read efficiency must be balanced. To be clear, rather than just considering read efficiency, they also took into consideration a measure of overlapping reads. For this measure, they determined that a scheme has α overlapping reads if the reads for a new search overlap at the most α bits with all prior reads.

A dynamic version of SSE (DSSE) was then introduced to support database updates, which allows users to add, update and/or remove keywords/document couples at any time within a database [27, 34, 35]. DSSE with sublinear search times was introduced by Kamara et al. [22], but their solution revealed each update’s keyword hashes. The problem was later solved by Kamara and Papamanthou [23], by increasing the complexity of the space. These solutions do not withstand more sophisticated attacks, such as file-injection attacks [29] or leakage-abuse attacks [36]. The attacks reveal the importance of forward private security, an essential property of DSSE that was officially introduced in [28]. While Stefanov et al. [28] presented a forward private, secure DSSE scheme, their solution is complex, since the update protocol will need to be rebuilt at every data structure layer. Some schemes [24, 37, 38] that use Oblivious Random Access Machine (oblivious RAM), can achieve forward security but have high computational costs. Currently, these tools are too expensive for large databases, so they are not practical [39]. There are also schemes [26, 30] with optimal computational complexity and forward security that may suffer from some limitations. The database increases in size by increasing the number of updates (additions or deletions) to the encrypted database that is stored on the server. As the results returned by the server when searching are considered to be a leak access pattern, there are not deleted from the server when searching. Storing such information on the server or re-encrypting it will not increase security; rather, it will increase storage costs and subsequent searches. An official definition of forward privacy, together with a DSSE scheme that optimises communication (Sophos) was provided by Bost in [26]. For better theoretical computation complexity than [37], Sophos uses trapdoor permutations to link search and update tokens. Despite this, Sophos is inefficient in practice, as it relies on public key primitives for trapdoor permutation.

An informal mention of backward security was made in [28]. Bost et al. [30] defined backward security in formal terms and gave constructions that realized this property. Two schemes were then proposed by Chamani et al. [40]. The Mitra and Mitra* schemes describe a method that combines the best computational complexity and the best communication complexity, although it requires two rounds of communication to succeed. However, the problem with these schemes is that they suffer from an increase in memory cost at the server and to the client, by increasing the update operations (add/delete) on the data. The symmetric puncturable encryption proposed by Sun et al. [41] improves the puncturable encryption described in [30]. In different adversary models, constructions [39, 42] are provided to enhance privacy; however, the client storage cost is high because it needs data structures that are stored with the clients, such as the keyword counter, whose size increases linearly with the increase in the size of the database. Increasing the cost of client storage was solved in [43, 44]. One limitation is that the cost of search queries increases when searching, which prevents these structures from being used in smart devices.

In contrast from current frameworks, our presented Dynamic Searchable Symmetric Encryption (DSSE) scheme mitigates various constraints by proposing a two-party model that optimizes storage expenses for intelligent devices. Through the strategic utilization of forward and backward privacy measures, the scheme ensures the confidentiality of data during both updates and searches. Notably, the elimination of client-side table’s results in sustained storage, a distinctive feature that significantly enhances operational efficiency. Moreover, the incorporation of secure cryptographic primitives, coupled with a dynamic methodology, facilitates robust privacy-preserving search functionalities. Collectively, these innovations surmount deficiencies in prior schemes, presenting a more effective and secure solution for dynamic searchable symmetric encryption. When it comes to Dynamic Symmetric Searchable Encryption (DSSE), ensuring the dissociation of previous search queries from subsequent requires forward privacy when making updates. While backward privacy guarantees the non-association of subsequent search requests for retrieval of deleted documents from the past. This research introduces a comprehensive method for preserving both forward and backward privacy in DSSE. Impressively, this strategy signifies the first operational and non-interactive Type-II backward-private DSSE framework without relying on secure execution environments. The proposed DSSE scheme attains Type-II backward and forward privacy by generating a unique one-time (fresh) key, denoted as sk, for each search query. This yields distinct encryption outcomes for each encryption iteration. Furthermore, it safeguards against the server by discerning the underlying operation (delete or add) embedded in the update query.

Previous research in dynamic searchable symmetric encryption (DSSE) has primarily focused on balancing security and efficiency. Mitra [40], SD_d [43], and CLOSE-FB [44] represent efficient schemes in this domain, employing cryptographic symmetric primitives. However, their drawbacks include linear increases in client storage costs and query generation times as the database size grows.

Our proposed scheme distinguishes itself by achieving constant client storage costs and offering heightened efficiency for smart devices. It addresses the limitations of existing schemes, particularly mitigating the linear growth issues observed in Mitra and SD_d. Through a two-party model and encrypted index implementation, our DSSE scheme not only ensures robust security features, including forward and backward privacy, but also outperforms competitors in terms of search costs and query generation times. This paper provides a comprehensive analysis of the experimental results, substantiating the practical viability and superior performance of our proposed DSSE scheme.

3 Preliminaries

4 System model overview

This section presents our forward-backward privacy scheme. We developed an ongoing SDC storage cost, forward privacy, and backward privacy scheme based on Type-II definitions. This prevents subsequent searches from being able to relate to the deleted documents. According to the proposed scheme, a two-party model is used, where the client is the owner of the data, and the server is the one that provides large storage space and efficient computational power to the client.

A scheme comprises one algorithm setup and two protocols for updating and searching. In the setup algorithm, the client initializes specific parameters and structures used in other protocols to enable the DSSE system to operate correctly. The client encodes keywords/document couples for subsequent searches in the Update protocol. Based on the current global counter Con, an EDB is built for every keyword w in the update. The search token KT_w is generated by the client and sent to the server based on the keyword w and the number of global users. The search token can be used: the server produces all necessary addresses for keyword w and looks for documents in EDB, which are stored under keyword w.

Construction of proposed scheme. GenPRP(1^λ),GenPRF(1^λ)—a key is generated through this process. Functions, F:{0,1}^λ X{0,1}*→ {0,1}^λ is a pseudo-random function PRF, h:{0,1}*→ {0,1}^λ describes a hash function in the form of a random oracle, and G: {0,1}^λX{0,1}^λ→ {0,1}^λ is a pseudo-random permutation function PRP. We describe our scheme in one algorithm and two protocols.

Setup. K_f, K_t, and K_g represent the keys generated randomly by the Setup algorithm1; we formally describe each with a size determined by the security parameter λ. As a long-term key, K_f prevents a valid search token from being generated by the server in PRF F, PRP G uses K_g to protect pairs of (ind, op), while K_t constructs tags for keywords w. A constant and minimal amount of storage is required on the client side for the global counter Con (used with a search token for generating the locations Addr), and the client initiates two empty maps (S_e, S_r), which are sent to the server for storage. In Se, encrypted entries are stored for each call update protocol, while in S_r, plaintext entries are stored after the search operation is finished.

Update. As described in algorithm 2, it is important to remember that our scheme does not apply to a single keyword but to a document or set of documents. Therefore, the keyword index must be extracted from algorithm2 lines (1–4), which is self-evident in all efficient schemes that deal with the index directly without addressing its extraction. Clients in update protocols provide document collection DocColl and an update operation op, such as adding or deleting documents. A local state ϑ contains information about the keyword w, three keys (K_g,K_f,K_t), and the system constant Con. Adding a document set Doc to an encrypted database Se involves adding a keyword/document (w,ind) pair for every document in the set. A document is first taken out of the client lines (1–4) from algorithm2; in this step, keywords are extracted from each file in the collection (the keyword plus the documents it contains) indexing. This step is considered essential in all systems. Before adding or deleting keywords, the index is extracted. Therefore, it is the index that is dealt with, rather than the document directly. The extracted index is sent to a procedure called Process. The Process procedure works as follows:

When executing PRF F, the client uses K_f to calculate for each keyword w in index KTMap.KT_w is included in the calculation of the search token Key_w, which is combined with the system constant Con hash function; with each update, the value decreases. It is necessary to ensure that it does not conflict with the previous update, the forward privacy. Key_w is used to calculate the locations where encrypted values will reside in the server’s S_e Hash table. The location of the subsequent value is calculated using the random value rn, that is randomly generated for each pair(w,ind), except for the last couple in the index for the base word. An empty value ⊥ is incorporated as the index’s end tag in the subsequent search process. Next, the couples are encrypted (w,ind) to prevent them from being explicitly revealed to the server (backward privacy). A masked value Val is obtained by XORing the second outcome H(Key_w||0)with the encrypted entry E_id. These steps are repeated for all keywords in the document. Every time an update request is made, the Fresh Key sk is computed, so that the highest levels of privacy and security are achieved. During the update, this key is used to encrypt value (ind||op) to hide it from the server, as well as to prevent it from getting leaked.

A hash table is a data structure that stores information in a (key, value) format, allowing direct access to elements in a constant time. The innovative approach involves storing the rn value to calculate the next location for the same keyword within the current cell, ensuring that location calculation and retrieval tasks remain on the server for faster retrieval of results while maintaining data confidentiality. (Fig 1 illustrates this concept.)

When the process is complete, the system constant (Con−1) at the client is updated and the is added to the encrypted index S_e at the server. In Fig 1, the keyword w₁ is updated for a few file collections.

Search. Algorithm 3 formally describes the search. The algorithm receives input from both the client, denoted as ’ϑ,’ and the associated keyword. Additionally, it takes into account the contents of the server, encompassing both the encrypted S_e and explicit S_r databases.The client establishes a location within the explicit database, assigning it the value t_w, and concurrently generates a private key KT_w specifically for the keyword w lines (1–4) in algorthim3. At the start, the clients provide a tag value t_w, so that the server can return the document identifiers and the last constant Lcon value (if it exists) for w based on the most recently completed search request. Depending on the access pattern leakage, the explicit data will be leaked to the adversary, so it is stored explicitly in a hash table S_r[t_w] at the server after each search query. By hashing the keyword search token For Con times, the server calculates the locations for searching the encrypted database EDB S_e. Whenever the current Con equals the last constant Lcon stored in S_r[t_w], the search process terminates because no updates have occurred since the previous search. Otherwise, a set of locations Addr_w is computed for encrypted values in w, with each Con value between the last update and the last search. Consequently, the server calculates the location Addr_w for each encrypted value. Subsequently, the encrypted value for that specific location is positioned within the ID₂ group. Following this placement, the retrieved encrypted value is removed through the action of deleting (Delete S_e[Addr_w]) from the encrypted index. The value of the location Addr_w is calculated each time, with the help of the random number rn stored in the encrypted value of the previous location until the last value contains null, as shown in Fig 1. The steps (lines 11–22 in algorthim3) are repeated until the current constant Con number equals the last regular LCon number. The encrypted results, put in ID₂, are transmitted to the client, which possesses the requisite private keys for decrypting the results obtained from the server. Algorithm 3, specifically lines (25–27), is employed for the decryption process. Subsequently, the client generates a filter line (25–27) to identify and retain the values that were added, ensuring that only those additions and not the deleted values persist within the designated group ID₁. After decryption, the plaintext data and current Con are returned to the server for storage in the hash table S_r. This arises due to its classification as an access pattern leak. Re-encrypting it would result in an elevated computational cost during both encryption and decryption processes when subsequently conducting a search for the associated keyword w.

Alogorithm1 Setup(Con,λ;⊥)

  Client:

1: // Generate encryption and decryption keys

2: Con←System Constant // Give an initial value

3: ϑ←(K_g,K_f,K_t,Con) to the client side

4: S_e,S_r←empty map // Create two empty explicit and encrypted indexes

 Send S_e, S_r to the server side.

Algorithm 2 Update(ϑ,DocColl,op; S_e)

 Client:

1: KTMap ←MultiMap // create multimap: is contains a sorted list of key

2: for i = 1 to|DocColl| // Iterate over the number of documents in the collection

3: for j = 1 to |Doc_i| // Iterate over the number of keyword w in the document

4: KTMap[w_i]←KTMap[w_i]⋃{ind} // Collect IDs for documents that contain keyword w

5: // call function

6: Upgrade ϑ←(K_g,K_f,K_t,Con−1) // Update client state content

  Server:

7: Add To S_e // Update the encrypted index

1: (K_g,K_f,K_t,Con)←ϑ // Client content

2: Temp←empty map // Create empty group

3: for i = 1 to |KTMap| // Iterate along the explicit index

4:  // Create a key associated with the keyword w for first ind

5: Key_w←H(KT_w||Con) // Create fresh key for first ind

6: Addr_w←H(Key_w||1) // Calculate locations encrypted values for first ind

7: for j = 1 to |KTMap[w_i]|−1 // Iterate the number of ind that contain the keyword

8:   // Create random value rn

9:   // Create an encryption key for that value to be encrypted

10: E_id←G_sk(ind||op) // Encrypt the identifier and operation with a permutation function

10:  Val ←H(Key_w||0) ⊕(E_id||con||rn) // Creating the ultimate encrypted value

11: Temp[Addr_w]←Val // Store the encrypted value in the temporary index

12:  Add_rw←Add_rw⊕rn // Combine the rn with the current location to calculate a new location

13: E_id←G_sk(ind||op) // Encrypt the identifier and operation with a permutation function for last ind

14:  Val ←H(Key_w||0) ⊕(E_id||null) // Creating the ultimate encrypted value for last ind

15: Temp[Addr_w]←Val // Store the encrypted value in the temporary index for last ind

16: Return Temp

Algorithm 3 Search(ϑ, w;S_e,S_r)

Client:

1: (K_g,K_f,K_t,Con)←ϑ // Client content

2: ID₁,ID₂←empty set // Create two empty groups

3: // Create an location within the explicit database

4: // Create a private key for the keyword w

5: Send t_w,KT_w to the server side.

Server:

6: If S_r[t_w] ≠null // explicit database contains values for keyword w

7: (ID||con)←S_r[t_w] // Retrieve plaintext previous search values

8:  Lcon←con // Retrieve the constant system of the last search

9: Else

10: Lcon←System Constant // If there was no previous search for the keyword w

11: for i = Con to Lcon // Iterate over a constant system

12:  Key_w←H(KT_w||i) // Retrieve fresh key

13:  Addr_w←H(Key_w||1) // Calculate locations encrypted values

14:  If S_e[Addr_w]≠null // If this location contains an encrypted value

15:   (E_id||i||rn)←S_e[Addr_w]⊕H(Key_w||0) // Retrieve encrypted value

16:   ID₂←ID₂⋃{E_id||i} // Put the encrypted values into a group ID₂

17:   Delete S_e[Addr_w] // Delete the retrieved encrypted values from the database

18:   While rn ≠ null // Repeat until variable rn equals null

19:    Add_rw←Add_rw⊕rn||rn use to calculate the next location for the same w

20:  (E_id||i||rn)←S_e[Addr_w]⊕H(Key_w||0) // Retrieve encrypted value

21:   ID₂←ID₂⋃{E_id||i} // Put the encrypted values into a group ID₂

22:    Delete S_e[Addr_w] // Delete the retrieved encrypted values from the database

23: Send ID₁,ID₂ to the client side.

     Client:

24: for i = 1 to |ID₂| // Iterate the number of encrypted values retrieved

25:   (E_id||number)←ID₂[i] // Separating the variable number from the encrypted values

26:    // This variable goes into calculating the decryption key

27:   // Using the permutation function, the key returns the plaintext

28:   If op == "add" / A filter will be created for deleted values

29:    ID₁←ID₁ ⋃ {ind} // The remaining values are only added

30: Send ID₁,Con,t_w to the client side.

  Server:

31: S_r[t_w]←(ID₁||Con) // The plaintext results of the current search are stored on the server

Subsequent to each query on the keyword set denoted as w, a deduction of one is made from the constant value (Con−1) to produce a one-time key (sk​) specific to w. This sequential process serves to deactivate previously exposed keys. Consequently, when the keyword w is incorporated into a new document, its corresponding entry undergoes safeguarding through the assignment of a fresh key. This preventive measure precludes the server from establishing connections with prior issued search queries, thereby substantiating the concept of forward privacy. An instruction is given to the server to expunge all pertinent entries from the index in alignment with this security protocol.

5 Evaluation

In this section, our scheme is evaluated and compared with related schemes. Java is the programming language used in all schemes. Cryptographic hash functions h are performed with SHA-256 (160 bits long). PRF F is released with AES-128/256, while PRP G is released with AES-128/128. The experiments were conducted on a HUAWEI laptop running Windows 11 64-bit, x64-based operating system, using an Intel(R) Core (TM) i5-10210U CPU at 1.60GHz 2.11GHz, 8GB of RAM, and 512GB SSD disk.

The data set [47] consists of a large set of text e-mail messages exchanged between Enron employees. The data set is distinguished by its large size, which provides a diverse and realistic sample for testing information retrieval systems. The Enron email database serves as the foundation for document extraction and keyword processing. Each email file within the dataset is treated as a document, considering metadata and content. During the setup phase, keywords indicative of document content are extracted and subsequently encrypted using cryptographic functions such as pseudo-random functions (PRF) and pseudo-random permutations (PRP). The DSSE’s setup algorithm initializes critical parameters, generates cryptographic keys (K_f,K_t,K_g), and establishes the encrypted database (EDB) structure, mapping keywords to respective documents. Client-side storage encompasses essential information, including cryptographic keys and a global counter (Con), while maintaining data structures (S_e,S_r) in server side.

In these experiments, all document-keyword pairs in the Enron email dataset [47] were extracted and stored in an EDB. Variable size of the result was constructed throughout the experiment, ranging from 10 to 10⁵ documents. To simulate the performance impact of deletions on update operations, we simulated deletions with a probability ρ of 0.1. In the simulation of deletion processes during the system’s beta testing, a dynamic environment is established to replicate real-world scenarios where documents are systematically removed over time. Within the experimental framework, a deletion process involving pairs from the same database is incorporated at a rate of 10 percent. Specifically, for every addition of nine pairs (keyword, identifier), the tenth pair introduced corresponds to the removal of one of the preceding nine pairs, thus simulating the ongoing evolution of the database. When the time for processing each entry was calculated by repeating the experiment 30 times and then taking the average of the results; more entries were processed, the processing time for each entry decreased. The searchability of all keywords was preserved, even those that were misspelled or typed incorrectly. In addition, the file size did not affect search costs; it affected insertion costs, as bigger files typically include more keywords.

The proposed DSSE scheme undergoes a comprehensive evaluation, addressing client storage, computation cost, dynamic operation effects, and decryption cost on the client’s side. Focusing on efficiency as the database size expands; client storage assessment seeks a constant cost for smart devices with limited local storage. Computation cost measures query generation efficiency, emphasizing lower costs for enhanced scheme performance. Dynamic operation effects simulate the scheme’s behavior during updates and searches under dynamic scenarios in real world systems. Decryption cost evaluation ensures efficient result decryption, crucial for backward privacy in dynamic schemes. These metrics collectively offer a thorough assessment, aligning with key considerations in designing secure and efficient DSSE schemes, particularly in scenarios involving smart devices and dynamic data updates.

A comparison can be made between the proposed scheme and efficient schemes Mitra [40], SD_d [43] and CLOSE−FB [44]. Cryptographic symmetric primitives are used in all of the compared schemes, allowing for a fair comparison. For the simulation of dynamic search and update queries on a particular keyword, we created a sequence Seq of 100,000 queries that contained both the search and the update, interleaved by each other. As part of the construction of this sequence, a search parameter ρ was used to determine the probability of a search query appearing in the series, i.e. (1- ρ) is the probability of an update query occurring.

One of the criteria for selecting a variable-sized result is the quantity of documents containing the searched keyword and the associated deletion operations. Notably, in our proposed scheme, the addition and search operations are retained on the server to uphold data privacy.

6 Conclusion

Security features, such as forward and backward privacy, are crucial to preventing severe attacks on SSE. Using symmetric cryptographic primitives, we propose a dynamic SSE scheme that achieves forward privacy with a low client storage cost. Backward privacy is advanced by efficiently retrieving search results while concealing details about past updates. The solution should be implemented using a two-party model, in which the first party is the client. In contrast, the second party should act as the server, providing the client with extensive storage and efficient computation capabilities. The balanced distribution of responsibilities empowers both parties, optimizing the scheme for practical deployment in scenarios with dynamic data updates and the demand for efficient and secure search functionalities. The overall efficiency, including client storage, query generation costs, dynamic search performance, and decryption speed, is consistently demonstrated in comparison with Mitra and SD_d. This thorough alignment between claims and experiment outcomes establishes a robust empirical basis, underscoring the proposed DSSE scheme’s superiority across multiple metrics. The experiments serve as validation, providing clear and direct connections between claimed advantages and observed outcomes, reinforcing the scheme’s efficacy. The alignment between specific experiment results and claims establishes a clear connection, providing empirical support for the proposed DSSE scheme’s advantages. We propose using an encrypted index at the server, to join keywords with the document identifiers that share keywords. A constant client storage cost for the DSSE framework is proposed in this paper, focusing on DSSE in practice. In order to evaluate the performance of our scheme, it was implemented alongside two previous schemes. The results of the experiments indicated that our scheme performs better than the best of the other existing schemes.

In future work, the pursuit of efficiency and performance improvements in dynamic searchable encryption schemes is crucial. This involves exploring computational methodologies to reduce processing time for search and database updates, optimizing overall scheme performance. Dynamic key management ensures ongoing security, while verification on the client and server sides becomes imperative, particularly in scenarios with unreliable servers. Scalability exploration is vital for efficient and secure large-scale search functionalities.