Ciphertext search method and apparatus

Abstract

Embodiments of the present application provide a ciphertext retrieval method and device, the method comprising: obtaining a first update count and a first search count corresponding to a current target keyword. Generating a first retrieval key according to the first search count and the target keyword. Generating a file identifier encryption key according to the target keyword, and determining a group index to which the target keyword belongs in a keyword ciphertext storage pool on a server according to the file identifier encryption key. Sending a query token to the server to enable the server to decrypt each update operation record to obtain a corresponding first operation type and a hash value of a first file identifier, and perform a corresponding operation in a target data group corresponding to the group index according to the first operation type and the hash value of the first file identifier. Receiving the first file identifier ciphertext in the updated target data group returned by the server to obtain a target file identifier corresponding to the target keyword, which can efficiently retrieve ciphertext data.

Description

Technical Field

[0001] This application relates to the field of data security storage technology, and in particular to a method and device for encrypted text retrieval. Background Technology

[0002] In cloud computing applications, storing large amounts of user data on cloud servers inevitably poses numerous security risks. To address data security in the cloud, users typically choose to encrypt their data locally before uploading it to the cloud server. While encrypted storage effectively protects data security, the encryption algorithm destroys the semantics and structure of the plaintext, making it impossible for users to retrieve the data as easily as they would retrieve plaintext later.

[0003] Currently, Dynamic Searchable Symmetric Encryption (DSSE) technology has become the mainstream technology to support efficient retrieval of encrypted data. It primarily achieves encrypted retrieval by constructing a mapping between keyword indexes and search tokens, combined with symmetric encryption algorithms. However, when dealing with dynamic data updates, DSSE often employs an interactive deletion mechanism. This requires multiple rounds of interaction between the client and server to delete encrypted data. This not only increases client communication overhead and reduces interaction efficiency but also poses a serious risk of privacy leakage. Update operations can easily reveal the association information between keywords and documents, failing to guarantee forward privacy, while the search process can easily expose the metadata of deleted data, making backward privacy protection difficult.

[0004] Therefore, there is an urgent need for a ciphertext retrieval scheme that can efficiently support dynamic data updates while simultaneously satisfying both forward and backward security. Summary of the Invention

[0005] This application provides a method and apparatus for ciphertext retrieval, which enables efficient retrieval of ciphertext data while also enabling efficient dynamic data updates.

[0006] In a first aspect, embodiments of this application provide a encrypted text retrieval method, applied to a client, the method comprising: In response to a user's search request triggered by a target keyword, obtain the first update count and the first search count corresponding to the current target keyword; A first retrieval key is generated based on the first search count and the target keyword; Generate a file identifier encryption key based on the target keyword, and determine the group index to which the target keyword belongs in the keyword ciphertext storage pool on the server based on the file identifier encryption key; Generate a query token based on the first update count, the grouping index, and the first retrieval key; The query token is sent to the server so that the server can retrieve all update operation records corresponding to the target keyword from the update operation storage pool according to the first retrieval key in the query token, and traverse the retrieved update operation records in reverse order starting from the position indicated by the first update count, decrypt each update operation record to obtain the hash value of its corresponding first operation type and first file identifier, and perform the corresponding operation in the target data group corresponding to the group index in the keyword encrypted storage pool according to the hash value of the first operation type and the first file identifier. The server receives the first file identifier ciphertext from the updated target data group, decrypts the first file identifier ciphertext, and obtains the target file identifier corresponding to the target keyword; the first file identifier ciphertext is the ciphertext generated by encrypting the target file identifier corresponding to the target file associated with the target keyword.

[0007] Secondly, embodiments of this application provide a encrypted text retrieval device applied to a client, the device comprising: The acquisition module is used to respond to a user's search request triggered by a target keyword and acquire the first update count and the first search count corresponding to the current target keyword; The first generation module is used to generate a first retrieval key based on the first search count and the target keyword; The determination module is used to generate a file identifier encryption key based on the target keyword, and determine the group index to which the target keyword belongs in the keyword ciphertext storage pool on the server based on the file identifier encryption key; The second generation module is used to generate a query token based on the first update count, the grouping index, and the first retrieval key. The sending module is used to send the query token to the server, so that the server can obtain all update operation records corresponding to the target keyword from the update operation storage pool according to the first retrieval key in the query token, and traverse the obtained update operation records in reverse order starting from the position indicated by the first update count, decrypt each update operation record to obtain the hash value of its corresponding first operation type and first file identifier, and perform the corresponding operation in the target data group corresponding to the group index in the keyword encrypted storage pool according to the hash value of the first operation type and the first file identifier. The decryption module is used to receive the first file identifier ciphertext in the updated target data group returned by the server, decrypt the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword; the first file identifier ciphertext is the ciphertext generated by encrypting the target file identifier corresponding to the target file associated with the target keyword.

[0008] Thirdly, embodiments of this application provide an electronic device applied to a client, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the encrypted retrieval method as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the encrypted retrieval method as described in the first aspect.

[0010] Fifthly, embodiments of this application provide a computer program product, including: a computer program or instructions, which, when executed by a processor of an electronic device, enable the processor to at least implement the encrypted retrieval method as described in the first aspect.

[0011] Sixthly, embodiments of this application provide a encrypted text retrieval method applied to a server, the method comprising: The system receives a query token sent by the client. The query token includes a first update count, a group index, and a first retrieval key. The first update count is the number of updates corresponding to the current target keyword. The group index is generated based on the file identifier encryption key. The first retrieval key is generated based on the target keyword and the first search count corresponding to the current target keyword. Based on the first retrieval key, retrieve all update operation records corresponding to the target keyword from the update operation storage pool; Starting from the position indicated by the first update count, traverse the obtained update operation records in reverse order, decrypt each update operation record, and obtain the hash value of its corresponding first operation type and first file identifier; Based on the first operation type and the hash value of the first file identifier, perform the corresponding operation in the target data group corresponding to the group index in the keyword ciphertext storage pool to obtain the updated target data group; The first file identifier ciphertext in the updated target data group is sent to the client so that the client can decrypt the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword.

[0012] Seventhly, embodiments of this application provide a encrypted text retrieval device applied to a server, the device comprising: The receiving module is used to receive a query token sent by the client. The query token includes a first update count, a group index, and a first retrieval key. The first update count is the number of updates corresponding to the current target keyword. The group index is generated based on the file identifier encryption key. The first retrieval key is generated based on the target keyword and the first search count corresponding to the current target keyword. The acquisition module is used to acquire all update operation records corresponding to the target keyword from the update operation storage pool according to the first retrieval key; The decryption module is used to traverse the acquired update operation records in reverse order starting from the position indicated by the first update count, decrypt each update operation record, and obtain the hash value of its corresponding first operation type and first file identifier. The processing module is configured to perform corresponding operations in the target data group corresponding to the grouping index in the keyword ciphertext storage pool according to the first operation type and the hash value of the first file identifier, so as to obtain the updated target data group. The sending module is used to send the first file identifier ciphertext in the updated target data group to the client, so that the client can decrypt the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword.

[0013] Eighthly, embodiments of this application provide an electronic device applied to a verification end, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the encrypted retrieval method as described in the sixth aspect.

[0014] In a ninth aspect, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the encrypted retrieval method as described in the sixth aspect.

[0015] In a tenth aspect, embodiments of this application provide a computer program product, including: a computer program or instructions that, when executed by a processor of an electronic device, enable the processor to at least implement the encrypted retrieval method as described in the sixth aspect.

[0016] In the encrypted retrieval scheme provided in this application embodiment, it can be applied to the client to generate a query token for querying the server for files containing target keywords. Based on the query token, the server queries the index update operation record corresponding to the target keyword and performs the corresponding update operation to return the encrypted file identifier of the file associated with the updated target keyword to the client, so that the client can obtain the corresponding file. This not only enables efficient retrieval of encrypted data, but also satisfies forward security and backward security while efficiently and dynamically updating data.

[0017] In specific implementation, firstly, in response to a user's search request triggered by a target keyword, the system obtains the first update count and the first search count corresponding to the current target keyword. Then, based on the first search count and the target keyword, a first retrieval key is generated. Next, a file identifier encryption key is generated based on the target keyword, and the group index to which the target keyword belongs in the server's keyword encrypted storage pool is determined based on the file identifier encryption key. Then, a query token is generated based on the first update count, the group index, and the first retrieval key. The query token is sent to the server, enabling the server to retrieve all update operation records corresponding to the target keyword from the update operation storage pool based on the first retrieval key in the query token. Starting from the position indicated by the first update count, the server iterates backward through the retrieved update operation records, decrypts each update operation record to obtain its corresponding first operation type and first file identifier hash value, and performs the corresponding operation in the target data group corresponding to the group index in the keyword encrypted storage pool based on the first operation type and the hash value of the first file identifier. Finally, the server receives the first file identifier encrypted text from the updated target data group, decrypts the first file identifier encrypted text, and obtains the target file identifier corresponding to the target keyword. The first file identifier ciphertext is the ciphertext generated by encrypting the target file identifier corresponding to the target file associated with the target keyword. After obtaining the target file identifier, the client can further retrieve the corresponding file from the server based on this target file identifier.

[0018] In the above scheme, the client generates a first retrieval key by combining the target keyword with the current first search count during each search. Since the first search count increases with each search, the generated retrieval keys are different even for the same keyword, effectively preventing access pattern leakage due to repeated searches and ensuring forward security. Simultaneously, a unique file identifier encryption key is derived based on the target keyword, and the encrypted ciphertext of that file identifier is indexed in the keyword ciphertext storage pool. This ensures that the same target keyword always maps to the same storage group, enabling the server to quickly and accurately locate its associated file identifier ciphertext. Furthermore, the server employs two core storage structures: the encrypted file identifiers for the same keyword are centrally stored in the same data group within the keyword ciphertext storage pool, while all historical update operation records are stored in the update operation storage pool. Therefore, after receiving the query token sent by the client, which contains the group index, the first update count, and the first retrieval key, the server retrieves all update operation records corresponding to the target keyword from the update operation storage pool according to the first retrieval key. It then decrypts each update operation record sequentially from the position indicated by the first update count, restoring the corresponding operation type and the hash value of the file identifier. The server then executes the corresponding update operation in the keyword ciphertext storage pool, thereby dynamically reconstructing the currently valid file set. Finally, the updated file identifier ciphertext is returned to the client for decryption to obtain the latest target file identifier. The entire process requires no client-server interaction during the update phase, achieving non-interactive dynamic ciphertext retrieval and updating, improving the efficiency of ciphertext retrieval and data updating. Furthermore, since the server only processes encrypted data and cannot know the plaintext keywords, file content, or operation semantics, both forward and backward security are satisfied, significantly enhancing privacy protection capabilities. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram of a encrypted text retrieval system provided in an embodiment of this application; Figure 2 A flowchart illustrating a encrypted text retrieval method provided in this application embodiment; Figure 3 A flowchart illustrating another encrypted text retrieval method provided in this application embodiment; Figure 4 A flowchart illustrating yet another encrypted text retrieval method provided in this application embodiment; Figure 5 An application scenario diagram of a encrypted text retrieval method provided in the embodiments of this application; Figure 6 A schematic diagram of the structure of a encrypted text retrieval device provided in an embodiment of this application; Figure 7 To and Figure 6 A schematic diagram of the electronic device corresponding to the encrypted text retrieval device provided in the illustrated embodiment; Figure 8 A schematic diagram of another encrypted text retrieval device provided in an embodiment of this application; Figure 9 To and Figure 8 The illustrated embodiment provides a schematic diagram of the electronic device corresponding to the encrypted text retrieval device. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. “Multiple” generally includes at least two, but does not exclude the inclusion of at least one. It should be understood that the term “and / or” as used herein is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character “ / ” in this document generally indicates that the preceding and following related objects are in an “or” relationship. Depending on the context, the words “if” or “when” as used herein can be interpreted as “when…” or “when…”.

[0023] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0024] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0025] Traditional encrypted retrieval schemes mostly employ searchable encryption (SE) or dynamically searchable symmetric encryption to achieve keyword retrieval of encrypted ciphertext. Specifically, under a searchable encryption mechanism, users first create a keyword index for files to be uploaded to a cloud server, then encrypt the files and index locally, and finally outsource the encrypted files and index to the cloud server. When a user needs to find a file of interest, they first enter a query keyword, generate a corresponding search credential, and then send this credential to the cloud server. Upon receiving the search credential, the cloud server verifies it against the encrypted data stored in the cloud. If the verification passes, it means that a file containing the query keyword exists on the cloud server, i.e., the target file the user needs; if the verification fails, it means that no file containing the keyword exists in the outsourced file set. Throughout the entire retrieval process, the cloud server cannot obtain the keyword content or any information related to the plaintext file.

[0026] However, this searchable encryption (SE) technology can only process static datasets in encrypted databases, cannot support subsequent data updates, and is not suitable for dynamically changing datasets.

[0027] In contrast, while dynamic searchable symmetric encryption technology supports adding and deleting data in the database, it typically employs an interactive deletion mechanism during data updates. This means the client needs to interact with the server multiple times to delete encrypted data. This approach not only increases client communication overhead and reduces interaction efficiency but also poses serious privacy risks: update operations can easily leak keyword-document association information, failing to guarantee forward privacy; and during searches, it may expose metadata about deleted data, making backward privacy protection difficult.

[0028] It's important to clarify here that forward security means newly added documents will not reveal previously searched keywords, while backward security means that after a document is deleted, subsequent searches will no longer retrieve that document. Currently, many existing solutions for dynamic updates are either inefficient or sacrifice these critical security attributes, such as forward and backward security.

[0029] To address the aforementioned technical issues, this application proposes a novel encrypted retrieval scheme. In this scheme, the client dynamically generates a retrieval key by combining the current search count with the target keywords, and derives a fixed file identifier encryption key based on the target keywords to determine the corresponding group index of the target keywords in the keyword encrypted storage pool. Simultaneously, the server employs a dual storage structure of keyword encrypted storage pool and update operation storage pool to work collaboratively, achieving efficient, non-interactive dynamic encrypted retrieval and data update operations. While ensuring forward and backward security, this scheme ensures that the server cannot know the user's search intent, operation content, or associated files.

[0030] The encrypted text retrieval scheme will be illustrated below with reference to the following embodiments.

[0031] Figure 1 This is a schematic diagram of a encrypted retrieval system provided in an embodiment of this application, as shown below. Figure 1 As shown, the system can include a client and a server.

[0032] The client can be any device that needs to initiate encrypted search requests to the server and obtain files associated with target keywords. Specifically, the client can be a mobile phone, a personal computer (PC), a tablet computer, a configuration application, etc. It can also be any device that can provide computing services, such as a cluster server, a regular server, a cloud server, a cloud host, a virtual data center, etc.

[0033] The server can be any device that receives encrypted retrieval requests from clients, stores encrypted files and update operation records, performs retrieval and update operations, and returns results. Specifically, the server can be a mobile phone, a personal computer (PC), a tablet computer, a configuration application, etc. It can also be any device capable of providing computing services, such as a cluster server, a regular server, a cloud server, a cloud host, a virtual data center, etc. Furthermore, both the server and the client are equipped with the encrypted retrieval device described in this application to perform the corresponding encrypted retrieval.

[0034] Furthermore, to achieve efficient encrypted retrieval and efficient update operations on encrypted files stored on the server, an update operation storage pool and a keyword encrypted storage pool can be set up on the server side. This allows the server to combine the two storage pools to perform the corresponding encrypted retrieval processing during subsequent encrypted retrieval operations. Specifically, the encrypted file identifiers for the same keyword are stored in the same data group within the keyword encrypted storage pool, and all historical update operation records corresponding to each keyword are stored in the update operation storage pool. In other words, the keyword encrypted storage pool uses a grouped storage approach to store the encrypted file identifiers for each keyword. This allows for quick location of all encrypted file identifiers corresponding to a given keyword, avoiding the need to search the entire keyword encrypted storage pool. Furthermore, the update operation storage pool only stores update operation records that the server has not yet executed. The server will actually execute the corresponding update operation during the encrypted search process corresponding to the target keyword. After the update operation is actually executed, all update operation records corresponding to the target keyword in the update operation storage pool will be cleared. This not only protects the semantics of the client's operation, but also eliminates the need for the client to interact with the server during the update phase, realizing non-interactive dynamic encrypted updates. This improves the efficiency of encrypted search and data updates, satisfies both forward security and backward security, and significantly enhances privacy protection capabilities.

[0035] In practical applications, when a client wants to retrieve files associated with a target keyword from the cloud repository corresponding to the server, the user can trigger a search request using the client for the target keyword. The client then uses a encrypted retrieval device to generate a query token corresponding to the target keyword and sends the generated query token to the corresponding server. Upon receiving the query token, the server can use its encrypted retrieval device to obtain all update operation records corresponding to the target keyword. Starting from the position indicated by the latest first update count, the server decrypts each update operation record in reverse order and performs the corresponding operation. This returns the first file identifier encrypted text corresponding to the latest file associated with the target keyword to the client, allowing the client to obtain the latest target file identifier corresponding to the target keyword based on the first file identifier encrypted text, and thus obtain the latest file associated with it.

[0036] In practice, firstly, the client responds to a user's search request triggered by the target keyword by obtaining the first update count and the first search count corresponding to the current target keyword. Then, the client generates a first retrieval key based on the first search count and the target keyword. Next, the client generates a file identifier encryption key based on the target keyword and determines the group index to which the target keyword belongs in the server's update operation storage pool based on the file identifier encryption key. Finally, the client generates a query token based on the first update count, the group index, and the first retrieval key, and sends the query token to the server.

[0037] After receiving the query token, the server retrieves all update operation records corresponding to the target keyword from the update operation storage pool based on the first retrieval key in the query token. Starting from the position indicated by the first update count, it traverses the retrieved update operation records in reverse order, decrypting each update operation record to obtain the hash value of its corresponding first operation type and first file identifier. Based on the hash value of the first operation type and first file identifier, it executes the corresponding operation in the target data group corresponding to the grouping index in the keyword ciphertext storage pool. Finally, after executing the update operations corresponding to all update operation records, it sends all the first file identifier ciphertexts contained in the updated target data group in the keyword ciphertext storage pool to the client. Here, the first file identifier ciphertext refers to the ciphertext generated after encrypting the target file identifier corresponding to the target file associated with the target keyword.

[0038] The client receives the first file identifier ciphertext from the updated target data group returned by the server, decrypts it to obtain the target file identifier corresponding to the target keyword. After obtaining the target file identifier, the client can further retrieve the corresponding file from the server based on this identifier.

[0039] In summary, in this embodiment, the client generates a unique retrieval key by combining the target keyword with the current search count during the search, and determines the grouping index based on the encrypted file identifier key derived from the keyword. This, in turn, constructs a query token containing the grouping index, update count, and retrieval key. To efficiently respond to such query tokens, the server employs two core storage structures: encrypted file identifiers for the same keyword are centrally stored in the same data group within the keyword encrypted storage pool, and all historical update operation records are stored in the update operation storage pool. Thus, the server can accurately locate data based on the information in the query token, reverse-replay update operation records, and dynamically reconstruct the latest file set, achieving efficient and secure non-interactive dynamic retrieval and executing corresponding update operations during the retrieval process without exposing plaintext semantics.

[0040] In other words, by employing a two-tiered storage architecture of an update operation storage pool and a keyword encrypted storage pool, the new encrypted data corresponding to keywords is separated from historical valid encrypted data, optimizing the retrieval path and improving search performance in large-scale scenarios. Furthermore, by utilizing the keyword encrypted storage pool and counter status, the server can independently complete encrypted deletion or addition processing, achieving non-interactive file deletion or addition. By offloading complex index maintenance and deletion operations to the server, and performing the actual deletion or addition processing only when executing specific retrieval operations on the server, not only is the client's burden reduced, but the server also remains unaware of the client's specific operations.

[0041] To facilitate understanding of the specific process of encrypted retrieval between the client and server, combined with... Figure 2 The specific process of encrypted retrieval performed by the client is illustrated by example.

[0042] Figure 2 A flowchart of a encrypted text retrieval method provided in this application embodiment; as follows: Figure 2 As shown, this method is applied to the client side, and specifically, the method may include the following steps: 201. In response to a user's search request triggered by a target keyword, obtain the first update count and the first search count corresponding to the current target keyword.

[0043] 202. Generate the first search key based on the first search count and the target keyword.

[0044] 203. Generate a file identifier encryption key based on the target keyword, and determine the group index to which the target keyword belongs in the keyword encrypted storage pool on the server based on the file identifier encryption key.

[0045] 204. Generate a query token based on the first update count, the grouping index, and the first retrieval key.

[0046] 205. Send the query token to the server so that the server can retrieve all update operation records corresponding to the target keyword from the update operation storage pool based on the first retrieval key in the query token, and traverse the retrieved update operation records in reverse order starting from the position indicated by the first update count, decrypt each update operation record to obtain the hash value of its corresponding first operation type and first file identifier, and perform the corresponding operation in the target data group corresponding to the group index in the keyword encrypted storage pool based on the hash value of the first operation type and first file identifier.

[0047] 206. Receive the first file identifier ciphertext from the updated target data group returned by the server, decrypt the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword. The first file identifier ciphertext is the ciphertext generated by encrypting the target file identifier corresponding to the file associated with the target keyword.

[0048] In practical applications, when a user wants to retrieve encrypted files associated with the keyword "ciphertext security algorithm," they can trigger a search request using a client. To better understand the specific implementation process of the ciphertext retrieval provided in this application, the process is explained in detail below in this application scenario.

[0049] When the client's encrypted retrieval device receives a search request triggered by a user targeting a specific keyword, it responds by obtaining the first update count and the first search count corresponding to the current target keyword. The target keyword is a feature term pre-defined by the user for the encrypted file to be stored on the server, used to identify the core content of the file. This target keyword has a one-to-one or many-to-one correspondence with the file.

[0050] The client-side local cache stores historical update counts and historical search counts for the target keyword. An update counter records the number of updates for the target keyword; each time a user performs an update operation on a file associated with the target keyword, this update counter increments to obtain the latest update count for the current target keyword. Similarly, a search counter records the number of searches for the target keyword; each time a user triggers a search request for the target keyword, this search counter increments to obtain the latest search count for the current target keyword.

[0051] In practical applications, when a client receives a search request, it reads the latest update sequence number associated with the target keyword from the update counter to obtain the first update count for the current target keyword. It also reads the cumulative search count associated with the target keyword from the search counter to obtain the first search count for the current target keyword.

[0052] For example, the first update count refers to the cumulative number of all update operations (including file addition and deletion) corresponding to the target keyword "ciphertext security algorithm" in the server-side update operation storage pool up to the current moment, and the first update count is maintained and cached independently by the client.

[0053] Specifically, assuming the server performs three update operations on the target keyword "ciphertext security algorithm": the first operation adds file A (marked as F1), the second adds file B (marked as F2), and the third deletes file A (marked as F1). As of now, the first update count for this target keyword is 3. After the client responds to the search request, it reads this real-time synchronized count from its local cache, thus obtaining the first update count as 3.

[0054] The first search count refers to the cumulative number of times the user has triggered search requests for the target keyword "ciphertext security algorithm" through this client up to the current moment. This first search count is maintained independently locally by the client. Specifically, assuming the user has previously triggered two search requests for "ciphertext security algorithm" through this client, and this is the third trigger, the first search count maintained locally by the client is "3". After the client responds to this search request, it directly reads the local count and increments it by 1 (the search count is updated to 3 in this instance) to obtain the current first search count = 3.

[0055] It should be noted that the first search count is only bound to the current client and the current target keyword. The search counts for the same keyword on different clients are independent of each other, and the search counts for different keywords on the same client are also maintained separately. This ensures that the retrieval key generated for each search request is unique, further protecting the privacy and security of the retrieval process and avoiding the risk of information leakage caused by duplicate keys.

[0056] After obtaining the first search count, a first retrieval key is generated based on the first search count and the target keyword. This first retrieval key is primarily used to decrypt the encrypted file identifier returned by the server, and to ensure the integrity and timeliness of operations during the verification and processing of update operation records. Furthermore, since the first search count increases with each search, even for the same target keyword, the generated first retrieval key is different each time, effectively hiding duplicate search behavior, preventing access pattern leakage, and ensuring forward security.

[0057] In an optional embodiment, the specific implementation process for generating the first retrieval ciphertext can be as follows: Obtain the master key; concatenate the target keyword and the first search count to obtain the first concatenated string; and generate the first retrieval key using a message checksum function based on the SM3 algorithm, with the master key as the key and the first concatenated string as the data. The master key can be generated during the initialization phase. When performing ciphertext retrieval, the pre-generated master key can be obtained, and this master key is mainly used to construct a search token (search trapdoor). In practical applications, a random number generator can optionally be used to generate the master key, and the master key can be a 32-byte or 16-byte random number. The SM3 algorithm is a self-designed message digest algorithm that can digest messages smaller than... Any data digest of bits is converted into a unique 256-bit value.

[0058] For example, suppose the master key is Target keywords Let it be indicated that the first search count is Therefore, when generating the first search key, the target keyword and the first search calculation can be concatenated to obtain... Then, based on the SM3 algorithm, the message checksum function generates the first retrieval key using the master key as the key and the first concatenated string as the data. That is, the first retrieval key is HMAC is a message checksum algorithm based on the SM3 algorithm.

[0059] Next, a file identifier encryption key is generated based on the target keyword. This key is primarily used to encrypt the file identifier associated with the target keyword, generating encrypted file identifiers for secure storage. Simultaneously, this encryption key is also used to derive a grouped index of the target keyword in the server-side keyword encrypted storage pool, ensuring that the same keyword always maps to the same storage group. This allows the server to efficiently locate and dynamically update the encrypted file identifiers associated with the target keyword during the retrieval process.

[0060] In one optional embodiment, the specific implementation process for generating the file identifier encryption key can be as follows: obtain the master key, and generate the file identifier encryption key using the master key as the key and the target keyword as the data through a message checksum function based on the SM3 algorithm. For example, assume the master key is... The target keywords are The generated file identifier encryption key is .

[0061] Specifically, after generating the file identifier encryption key, the group index to which the target keyword belongs in the keyword encrypted storage pool on the server is determined based on this key. The keyword encrypted storage pool uses a structured storage method organized by group index, centrally storing all file identifier encrypted texts corresponding to the same keyword within the same data group. This allows the server to quickly locate the corresponding data group based on this group index when performing encrypted text retrieval operations on the target keyword, efficiently reading or updating the file identifier encrypted text associated with that target keyword, avoiding a full pool scan, and significantly improving retrieval and synchronization performance.

[0062] In an optional embodiment, an SM3 hash operation can be performed on a string of all zero bits of length λ using the file identifier encryption key to generate a group index to which the target keyword belongs in the keyword ciphertext storage pool. For example, the file identifier encryption key is... The target keywords are Then the grouping index corresponding to the generated target keyword is .in, It is a hash function, employing the SM3 hash algorithm (GM / T 0003 SM3 Cryptographic Hash Algorithm). Based on this grouped index, the server can easily group the current search structure with previous search structures for the same target keyword, thereby managing the index history of the same keyword and quickly locating the search scope.

[0063] Then, a query token is generated based on the first update count, the group index, and the first retrieval key. The query token includes these three pieces of information: the first update count tells the server to traverse the update operation records corresponding to the target keyword backwards from the latest record (i.e., the first update count); the group index tells the server which data group all valid ciphertext pairs corresponding to the target keyword are stored in; this valid ciphertext pair includes the file identifier ciphertext corresponding to the file associated with the target keyword and the operation type ciphertext corresponding to the operation performed on the file associated with the target keyword. The file identifier ciphertext is the ciphertext generated by encrypting the file identifier corresponding to the file associated with the target keyword. The operation type ciphertext is the ciphertext generated by encrypting the operation type corresponding to the update operation performed on the file associated with the target keyword. The first retrieval key is the key used by the server to decrypt each update operation record.

[0064] The query token is then sent to the server, enabling the server to retrieve all update operation records corresponding to the target keyword from the update operation storage pool based on the first retrieval key in the query token. Starting from the position indicated by the first update count, the server traverses the retrieved update operation records in reverse order, decrypts each update operation record to obtain the hash value of its corresponding first operation type and first file identifier, and performs the corresponding operation in the target data group corresponding to the group index in the keyword encrypted storage pool based on the hash value of the first operation type and first file identifier.

[0065] Finally, the system receives the updated ciphertext of the first file identifier from the target data group returned by the server, decrypts it to obtain the target file identifier corresponding to the target keyword. The first file identifier is the ciphertext generated by encrypting the target file identifier associated with the target keyword.

[0066] Since the first file identifier ciphertext is generated by encrypting it with a symmetric key, this symmetric ciphertext is both the key for encrypting and decrypting the file identifier. Furthermore, in an optional embodiment, the SM4 algorithm can be used to generate this key. The specific key generation and the process for generating the first file identifier ciphertext are not described in detail here; please refer to the relevant description below. Specifically, when decrypting the first file identifier ciphertext, the key for decrypting the file identifier can be obtained, and this key can be used to decrypt the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword.

[0067] After obtaining the target file identifier, the server can further retrieve the encrypted file corresponding to the target file identifier from the server and decrypt the encrypted ciphertext to obtain the corresponding file to be searched. In addition, in practical applications, the server can return the first file identifier ciphertext to the client along with the corresponding encrypted file's ciphertext. In summary, in this embodiment, the client generates a first search key by combining the target keyword with the current first search count during each search. Since the first search count increases with each search, even for the same keyword, the generated search keys are different, effectively preventing access pattern leakage due to repeated searches and ensuring forward security. Simultaneously, a unique file identifier encryption key is derived based on the target keyword, and the group index of the encrypted file identifier in the keyword ciphertext storage pool is used. This ensures that the same target keyword always maps to the same storage group, enabling the server to quickly and accurately locate its associated file identifier ciphertext. Furthermore, the server employs two core storage structures, centrally storing the file identifier ciphertext of the same keyword in the same data group of the keyword ciphertext storage pool, and storing all historical update operation records in the update operation storage pool. Therefore, after receiving the query token sent by the client, which contains the group index, the first update count, and the first retrieval key, the server retrieves all update operation records corresponding to the target keyword from the update operation storage pool according to the first retrieval key. It then decrypts each update operation record sequentially from the position indicated by the first update count, restoring the corresponding operation type and the hash value of the file identifier. The server then executes the corresponding update operation in the keyword ciphertext storage pool, thereby dynamically reconstructing the currently valid file set. Finally, the updated file identifier ciphertext is returned to the client for decryption to obtain the latest target file identifier. The entire process requires no client-server interaction during the update phase, achieving non-interactive dynamic ciphertext retrieval and updating, improving the efficiency of ciphertext retrieval and data updating. Furthermore, since the server only processes encrypted data and cannot know the plaintext keywords, file content, or operation semantics, both forward and backward security are satisfied, significantly enhancing privacy protection capabilities.

[0068] Furthermore, once the client obtains the target file identifier corresponding to the target keyword, it can also control the search calculator to increment by one, obtaining the second search count corresponding to the current target keyword. It can also control the update counter to be set to 0, obtaining the second update count corresponding to the current target keyword.

[0069] In other words, after a search operation is completed, all temporary encrypted text in this batch in the update operation storage pool has been processed, either deleted or moved to the keyword encrypted text storage pool. The server already knows the final state of the keyword up to the time of this search. The update count is reset to zero after each search, meaning it will never grow to a very large value (the maximum will not exceed the number of updates between two searches), making client-side storage very lightweight.

[0070] Furthermore, thanks to the collaborative work of the keyword encrypted storage pool and the update operation storage pool, as well as the control of setting the update counter to 0, the client does not need to re-encrypt and upload all valid results after the search. The server has already organized the results and stored them in the keyword encrypted storage pool, avoiding interactive re-encryption and achieving non-interactive deletion.

[0071] Building upon encrypted text retrieval, to support dynamic data changes, the client in this embodiment can also securely and efficiently perform update operations such as adding or deleting files. Similar to the search process, the update operation also relies on the counter state bound to the keyword and the encryption key derivation mechanism to ensure forward security and server indistinguishability. Specifically, after receiving an update request initiated by the user, the client generates corresponding update parameters based on the target keyword, constructs an update instruction containing the operation type and file identifier encrypted text, and sends it to the server to complete the non-interactive encrypted update. The following details the specific implementation process of the client executing this update operation.

[0072] Figure 3 A flowchart illustrating another encrypted text retrieval method provided in this application embodiment; see attached document. Figure 3 As shown, specifically, based on the above embodiments, the method may further include the following steps: 301. In response to a user's update request triggered by a target keyword, obtain the third update count and third search count corresponding to the current target keyword. The update request includes a second operation type performed on the file associated with the target keyword.

[0073] 302. Determine the second file identifier corresponding to the file associated with the target keyword.

[0074] 303. Increment the control update counter to update the third update calculation to the fourth update count corresponding to the current target keyword.

[0075] 304. Based on the fourth update count and the second operation type, generate the search index and operation type ciphertext corresponding to the current update operation.

[0076] 305. Using the SM4 algorithm, the second file identifier is encrypted with the symmetric key corresponding to the client to obtain the ciphertext of the second file identifier.

[0077] 306. Send the update operation ciphertext, which includes the search index, operation type ciphertext, and second file identifier ciphertext, to the server so that the server can use the search index as the index key and write the operation type ciphertext and the second file identifier ciphertext as the corresponding storage values ​​into the update operation storage pool.

[0078] In practical applications, when a user needs to perform an update operation on a file associated with a target keyword, the client can trigger an update request for the target keyword. Upon receiving the update request, the client's encrypted retrieval device responds by obtaining the third update count and the third search count corresponding to the current target keyword.

[0079] The update request includes a second operation type performed on the file associated with the target keyword. The third update count is the cumulative number of all update operations corresponding to the target keyword in the server-side update operation storage pool up to the current time (the time corresponding to the update request response). The third search count refers to the cumulative number of times the user has triggered a search request for the target keyword through this client up to the current time (the time corresponding to the update request response). Then, the second file identifier corresponding to the file associated with the target keyword is determined. This second file identifier can be determined by reading local file metadata, the file path entered by the user, or the file information bound to the target keyword in the application-layer index table.

[0080] Next, the update counter is incremented to update the third update count to the fourth update count corresponding to the current target keyword. That is, by... To accumulate target keywords The number of updates, and update this modification to Since the ciphertext pairs in the final generated update operation record are bound to the update count, multiple update operations for the same target keyword can be distinguished. Therefore, when the client executes an update operation, it needs to update the third update count corresponding to the current target keyword first to determine the fourth update count corresponding to this update operation.

[0081] After obtaining the fourth update count corresponding to this update operation, a search index and operation type ciphertext are generated based on the fourth update count and the second operation type. The search index is a unique identifier generated through encryption operations based on the core parameters of the current update operation (including the fourth update count, the second operation type, target keyword information, etc.). This search index serves as a retrieval index, primarily used to associate all core information of the current update operation, enabling rapid location and retrieval of update operation records. Specifically, the server-side update operation storage pool stores the operation type ciphertext and file identifier ciphertext corresponding to this search index. The operation type ciphertext essentially contains the encrypted operation type (operation command) and the encrypted file identifier.

[0082] One possible implementation for generating the ciphertext of the search index and operation type corresponding to the current update operation is as follows: A second retrieval key is generated based on the third search count, the target keyword, and the master key; a file identifier encryption key is generated based on the target keyword and the master key; an SM3 hash operation is performed on the second file identifier using the file identifier encryption key to generate the hash value of the file identifier; and the ciphertext of the search index and operation type corresponding to the current update operation is generated based on the second retrieval key, the fourth update count, the second operation type, and the hash value. Specifically, the second retrieval key can be generated using the same implementation method as in the above embodiments for generating the first retrieval key, and the file identifier encryption key corresponding to the target keyword can be generated using the same implementation method as in the above embodiments for generating the file identifier encryption key.

[0083] For example, suppose the second file identifier is The third search count is The target keywords are The master key is The generated second retrieval key is then... The generated file identifier encryption key is... Then, the encrypted target keyword generates the search index and operation type ciphertext corresponding to the current update operation. Specifically, the file identifier encryption key is used to perform an SM3 hash operation on the second file identifier to generate the hash value of the file identifier. The second retrieval key and the fourth update count are hashed to obtain their corresponding target hash values. The hash values ​​of the second operation type and the file identifier are then concatenated to obtain their corresponding concatenated strings. The target hash value and the concatenated strings are then XORed to generate the search index L and operation type ciphertext D corresponding to the current update operation. .in, This refers to a padding string of λ zeros used for bit length alignment. L is the high-order value of the XOR encryption result. The resulting bit, ciphertext D, is the low-order bit of the XOR encryption result described above. Obtained from bits.

[0084] As described above, this generation method ensures the uniqueness and security of the search index and operation type ciphertext through a combination of multi-dimensional encryption parameters. The master key serves as the core encryption foundation, combining with the third search count and target keywords to generate the second retrieval key. This ensures the key's uniqueness (associating with update request counts and target keywords) and enhances encryption strength. It uses a file identifier encryption key to perform an SM3 hash operation on the second file identifier, preventing plaintext leakage of the file identifier. The generated hash value matches the subsequent server-side verification logic. Finally, the second retrieval key, the fourth update count, the second operation type, and the hash value are merged to generate the search index and operation type ciphertext. This allows the search index to accurately associate with the current update operation, and the operation type ciphertext to securely store the core instructions and file identifier information of the update operation. This provides secure and matching basic data for the server to receive update information, execute update operations, and perform subsequent searches, while also meeting the core requirements of this application for end-to-end encryption and efficient retrieval.

[0085] Then, the second file identifier is encrypted using the SM4 algorithm and the client's corresponding symmetric key to obtain the ciphertext of the second file identifier. This symmetric key can be the encryption key generated during the initialization phase for encrypting or decrypting the file identifier for the client. Furthermore, the SM4 algorithm can be used to generate this symmetric key. The SM4 block cipher algorithm (GM / T 0002-2012 SM4 Block Cipher Algorithm) is a symmetric cryptography standard that can be used for data encryption and decryption, with both key length and block length being 128 bits.

[0086] For example, in an alternative embodiment, assuming the symmetric key is K, the generated second file identifier ciphertext is: The second file identifier, id, is encrypted using the CBC mode of the SM4 algorithm.

[0087] Finally, the update operation ciphertext, which includes the search index, operation type ciphertext, and second file identifier ciphertext, is sent to the server so that the server can use the search index as the index key and write the operation type ciphertext and the second file identifier ciphertext as the corresponding storage values ​​into the update operation storage pool.

[0088] In addition, while sending the ciphertext of the update operation to the server, the encrypted ciphertext corresponding to the file associated with the target keyword can also be sent to the server, so that the server can store the encrypted ciphertext corresponding to the file in the corresponding database. The specific implementation process involved in this application embodiment can be referred to the content of the above embodiments, and will not be repeated here.

[0089] In summary, in this embodiment, when responding to an update request on the client side, the current third update count and third search count are obtained based on the target keywords to determine the second file identifier of the file to be operated on. After incrementing the update counter, a search index and operation type ciphertext are generated using the new fourth update count and operation type. Then, the file identifier is encrypted using the SM4 algorithm to obtain the second file identifier ciphertext. Finally, the three are encapsulated into update operation ciphertext and sent to the server. This achieves a non-interactive, forward-secure dynamic ciphertext update mechanism. The server only writes the encrypted operation record to the update operation storage pool based on the search index, without needing to know the plaintext keywords, file content, or operation semantics. This not only protects user privacy but also supports accurate replay of update operation records to reconstruct the latest file set during subsequent retrieval processes, effectively balancing dynamism, security, and execution efficiency.

[0090] The above embodiments describe the specific implementation process of ciphertext retrieval and update operations performed on the client side. The following describes the specific implementation process of ciphertext retrieval performed on the server side from the server side's perspective.

[0091] Figure 4 A flowchart illustrating another encrypted text retrieval method provided in the embodiments of this application; as follows: Figure 4 As shown, this method is applied to the server side, and specifically, the method may include the following steps: 401. Receive a query token sent by the client. The query token includes a first update count, a group index, and a first search key. The first update count is the number of updates corresponding to the current target keyword, the group index is generated based on the file identifier encryption key, and the first search key is generated based on the target keyword and the first search count corresponding to the current target keyword.

[0092] 402. Based on the first retrieval key, retrieve all update operation records corresponding to the target keyword from the update operation storage pool.

[0093] 403. Starting from the position indicated by the first update count, traverse the obtained update operation records in reverse order, decrypt each update operation record, and obtain the hash value of its corresponding first operation type and first file identifier.

[0094] 404. Based on the first operation type and the hash value of the first file identifier, perform the corresponding operation in the target data group corresponding to the group index in the keyword ciphertext storage pool to obtain the updated target data group.

[0095] 405. Send the first file identifier ciphertext in the updated target data group to the client so that the client can decrypt the first file identifier ciphertext and obtain the target file identifier corresponding to the target keyword.

[0096] In practical applications, after the server receives the query token sent by the client, it extracts the first update count, group index, and first retrieval key from the query token. Then, based on the first retrieval key, it retrieves all update operation records corresponding to the target keyword from the update operation storage pool.

[0097] One approach is to iteratively retrieve all update operation records corresponding to the target keyword from the update operation storage pool. Specifically, in an optional embodiment, retrieving all update operation records corresponding to the target keyword from the update operation storage pool can be achieved by iteratively executing the following process until all update operation records corresponding to the target keyword are retrieved from the update operation storage pool.

[0098] Using the first retrieval key, perform an SM3 hash operation on the current update count to obtain the hash result. The initial value of the current update count is the first update count. Use the high-order bits of the hash result as the search index corresponding to the update operation associated with the current update count, and use the low-order bits of the hash result as the decryption mask corresponding to the update operation associated with the current update count. From the update operation storage pool, retrieve the operation type ciphertext and the second file identifier ciphertext corresponding to the search index. The operation type ciphertext is obtained by encrypting the operation type corresponding to the update operation, and the second file identifier ciphertext is obtained by encrypting the file identifier of the file targeted by the update operation.

[0099] After obtaining all update operation records corresponding to the target keyword, the obtained update operation records can be traversed in reverse order starting from the position indicated by the first update count. Each update operation record is decrypted to obtain the hash value of its corresponding first operation type and first file identifier.

[0100] In one optional embodiment, the specific implementation of decrypting each update operation record can be as follows: iteratively execute the following process until the update count is 0.

[0101] Obtain the decryption mask and operation type ciphertext corresponding to the update operation associated with the current update count; perform an XOR operation on the decryption mask and operation type ciphertext to decrypt the hash value of the first operation type and the first file identifier corresponding to the update operation associated with the current update count.

[0102] Next, based on the hash value of the first operation type and the first file identifier, the corresponding operation is performed in the target data group corresponding to the group index in the keyword ciphertext storage pool to obtain the updated target data group.

[0103] In one optional embodiment, the specific implementation of performing a corresponding operation in the target data group corresponding to the grouping index in the keyword ciphertext storage pool, based on the first operation type and the hash value of the first file identifier, to obtain the updated target data group can be as follows: If the first operation type is a deletion operation, then the hash value of the first file identifier is added to the deleted file identifier set; the target data group corresponding to the grouping index is obtained from the keyword ciphertext storage pool; the ciphertext of the file identifier corresponding to the hash value of the first file identifier in the target data group is deleted, thus obtaining the updated target data group. If the first operation type is an addition operation and the deleted file identifier set does not include the hash value of the first file identifier, then the hash value of the first file identifier and the ciphertext of the file identifier corresponding to the hash value of the first file identifier are added to the target data group in the keyword ciphertext storage pool.

[0104] To facilitate understanding of the above implementation process, the following example illustrates the specific implementation process of generating the updated target data group. Assume the first update count is... The first retrieval key is The file identifier of the file corresponding to the current update operation is Starting from the position indicated by the first update count, traverse in reverse order. This involves traversing the update operation records in reverse order, iterating from tupdate to 0 for each update operation record. Since the specific implementation process of executing the corresponding update operation for each update operation record is roughly the same, the following details the execution process for a single update operation record.

[0105] Using the first retrieval key, perform an SM3 hash operation on the current update count to obtain the hash result. The high-order bits of the hash result are used as the search index L corresponding to the update operation associated with the current update count, and the low-order bits of the hash result are used as the decryption mask D′ corresponding to the update operation associated with the current update count. Take the higher Bit, Take the lower Bit. That is... Then, based on the search index L, retrieve the update operation from the storage pool. In this process, the ciphertext D of the operation type corresponding to the search index and the ciphertext C of the second file identifier are retrieved. Next, obtain the decryption mask D′ and operation type ciphertext D corresponding to the update operation associated with the current update count. Perform an XOR operation on the decryption mask and operation type ciphertext to decrypt the hash value X = G(K2,id) of the first operation type op and the first file identifier corresponding to the update operation associated with the current update count. If the first operation type is Then Recorded It also deletes all keywords that existed in the keyword encrypted storage pool prior to this search. And Old cipher .like Then: If , then Record to group Remove all the aforementioned ciphertext found in the CDB storage pool, and group... The remaining encrypted file identifiers are returned to the client.

[0106] Finally, the updated ciphertext of the first file identifier in the target data group is sent to the client, allowing the client to decrypt the ciphertext and obtain the target file identifier corresponding to the target keyword. Furthermore, after sending the updated ciphertext of the first file identifier in the target data group to the client, the method further includes: deleting all update operation records corresponding to the target keyword from the update operation storage pool.

[0107] The specific implementation process involved in the embodiments of this application can be referred to the content of the above embodiments, and will not be repeated here.

[0108] In summary, in this embodiment, the server employs two core storage structures. File identifier ciphertexts for the same keyword are centrally stored in the same data group within the keyword ciphertext storage pool, while all historical update operation records are stored in the update operation storage pool. Furthermore, during each search, the client generates a first retrieval key by combining the target keyword with the current first search count. Since the first search count increments with each search, even for the same keyword, the generated retrieval keys are different, effectively preventing access pattern leakage due to repeated searches and ensuring forward security. Simultaneously, a unique file identifier encryption key is derived based on the target keyword, and the group index of the file identifier ciphertext in the keyword ciphertext storage pool is used. This ensures that the same target keyword always maps to the same storage group, enabling the server to quickly and accurately locate its associated file identifier ciphertext. Therefore, after receiving the query token sent by the client, which contains the group index, the first update count, and the first retrieval key, the server retrieves all update operation records corresponding to the target keyword from the update operation storage pool according to the first retrieval key. It then decrypts each update operation record sequentially from the position indicated by the first update count, restoring the corresponding operation type and the hash value of the file identifier. The server then executes the corresponding update operation in the keyword ciphertext storage pool, thereby dynamically reconstructing the currently valid file set. Finally, the updated file identifier ciphertext is returned to the client for decryption to obtain the latest target file identifier. The entire process requires no client-server interaction during the update phase, achieving non-interactive dynamic ciphertext retrieval and updating, improving the efficiency of ciphertext retrieval and data updating. Furthermore, since the server only processes encrypted data and cannot know the plaintext keywords, file content, or operation semantics, both forward and backward security are satisfied, significantly enhancing privacy protection capabilities.

[0109] To facilitate understanding of the above-mentioned encrypted retrieval process, examples of encrypted retrieval processes in specific application scenarios will be provided.

[0110] In practical applications, such as Figure 5 In the application scenario shown, the client performs an update operation on the target keyword and wants to retrieve the file associated with the target keyword.

[0111] In practice, the first step is to initialize the two storage pools corresponding to the server, the counter corresponding to the client, and generate the symmetric key and master key corresponding to the client.

[0112] Specifically, initialize the counter corresponding to the client. and storage structure Among them, EDB (Encrypted Database) is the storage pool for update operations, and CDB (Ciphertext Database) is the storage pool for these operations. (Grouped Retrieval Pool). And define an operation type. The operation type can take two values: add=0 for an add operation and del=1 for a delete operation. It also generates a symmetric key K and a master key. .

[0113] Next, in response to a user's update request triggered by the target keyword, the update count and search count corresponding to the current target keyword are obtained. The update request includes the type of operation performed on the file associated with the target keyword. The file identifier corresponding to the file associated with the target keyword is determined. The update counter is incremented to update the current update count to the latest update count corresponding to the current target keyword. Based on the latest update count and operation type, the search index and operation type ciphertext corresponding to the current update operation are generated. The file identifier is encrypted using the SM4 algorithm and the master key to obtain the file identifier ciphertext.

[0114] Specifically, the client executes the following process to generate the ciphertext for the update operation: Step 1: Retrieve the current count value If the count value If it is empty, it needs to be initialized. Step 2: By To accumulate keywords The number of updates, and update this modification to Step 3: Calculate the key , HMAC is a message checksum algorithm based on the SM3 algorithm.

[0115] Step 4: Encrypt keywords: ,in , It is a hash function, using the SM3 hash algorithm (GM / T 0003 SM3 Cryptographic Hash Algorithm). , Take the higher Bit, Take the lower Bit.

[0116] Step 5: Encrypt the input file identifier to That is, the key is K, and the ID is encrypted using the CBC mode of the SM4 algorithm.

[0117] Step 6: Update operation ciphertext Send to the server.

[0118] Then, the update operation ciphertext, which includes the search index, operation type ciphertext, and second file identifier ciphertext, is sent to the server so that the server can use the search index as the index key to write the operation type ciphertext and the second file identifier ciphertext as the corresponding storage values ​​into the update operation storage pool.

[0119] Specifically, the server configures... To store the encrypted update operation received.

[0120] When a user wants to retrieve encrypted text corresponding to a target keyword from the server, firstly, in response to the user's search request triggered by the target keyword, the server obtains the first update count and the first search count corresponding to the current target keyword. Next, based on the first search count and the target keyword, a first search key is generated. A file identifier encryption key is generated based on the target keyword, and based on the file identifier encryption key, the group index to which the target keyword belongs in the server's update operation storage pool is determined. Finally, a query token is generated based on the first update count, the group index, and the first search key.

[0121] Specifically, the client executes the following process to generate a query token: Step 1: Retrieve the current count value .

[0122] Step 2: Calculate the key , , used to generate keywords Search traps.

[0123] Step 3: Calculate the index This allows the server to group the current search result with previous search results for the same keyword.

[0124] Step 4: Query Token Send it to the corresponding database on the server.

[0125] Then, the query token is sent to the server. Based on the first retrieval key in the query token, the server retrieves all update operation records corresponding to the target keyword from the update operation storage pool. Starting from the position indicated by the first update count, it iterates backward through the retrieved update operation records, decrypts each update operation record to obtain the hash value of its corresponding first operation type and first file identifier, and performs the corresponding operation in the target data group corresponding to the grouping index in the keyword encrypted storage pool based on the hash value of the first operation type and the first file identifier.

[0126] Specifically, the server performs the following operations to perform the corresponding update operation in the target data group corresponding to the grouped index, and returns the updated file identifier ciphertext to the client: Step 5: Initialize an empty collection , .

[0127] Step 6: Calculation , Take the higher Bit, Take the lower Bit.

[0128] Step 7: Based on the index from Retrieve encrypted text.

[0129] Step 8: Decryption .

[0130] Step 9: If Then: Recorded And delete all existing data that existed prior to this search. And Old cipher .

[0131] Step 10: If Then: If , then Record to group middle.

[0132] Step 11: Remove from structure All of the above ciphertexts were found.

[0133] Step 12: Group The remaining encrypted file identifiers are returned to the client.

[0134] The server receives the first file identifier ciphertext from the updated target data group, decrypts the first file identifier ciphertext, and obtains the target file identifier corresponding to the target keyword.

[0135] Specifically, the client performs the following operations to obtain the target file identifier corresponding to the target keyword: Step 13: Using a symmetric key Decrypt all received ciphertext and return the target file identifier.

[0136] Step 14: By Set as And update To accumulate keywords The number of searches.

[0137] Step 15: By setting Update .

[0138] In summary, the symmetric cryptography algorithms involved in this application's embodiments all employ the SM4 algorithm, and the hash algorithm employs SM3, ensuring the algorithms are autonomously controllable. Furthermore, Steps 1-9 of the method delete the ciphertext without requiring the client to re-encrypt and re-upload all matching and still valid ciphertext to the server, achieving true non-interactive deletion. And, in this application... The client only needs to perform 4 SM3 digest operations and 1 SM4 encryption operation, protocol The client needs to perform 3 SM3 digest operations and 1 SM4 decryption operation, resulting in low computational complexity. (This is from an embodiment of the application.) The amount of data transmitted from the client to the server is simply the file identifier ciphertext plus 256 bits (the length of L||D); protocol The search trapdoor length is 64 bits (t), plus a 256-bit index and a 128-bit SM4 key, resulting in low transmission bandwidth consumption. The encrypted retrieval security implemented in this application satisfies both forward and backward security requirements. The encrypted retrieval apparatus of one or more embodiments of this application will be described in detail below. Those skilled in the art will understand that these apparatuses can be configured using commercially available hardware components through the steps taught in this solution.

[0139] Figure 6 This is a schematic diagram of the structure of a encrypted text retrieval device provided in an embodiment of this application, applied to a client, such as... Figure 6 As shown, the device includes: an acquisition module 11, a first generation module 12, a determination module 13, a second generation module 14, a sending module 15, and a decryption module 16.

[0140] The acquisition module 11 is used to acquire the first update count and the first search count corresponding to the target keyword in response to a search request triggered by the user for the target keyword. The first generation module 12 is used to generate a first retrieval key based on the first search count and the target keyword; The determination module 13 is used to generate a file identifier encryption key based on the target keyword, and determine the group index to which the target keyword belongs in the keyword ciphertext storage pool on the server based on the file identifier encryption key; The second generation module 14 is used to generate a query token based on the first update count, the grouping index and the first retrieval key; The sending module 15 is used to send the query token to the server so that the server can obtain all update operation records corresponding to the target keyword from the update operation storage pool according to the first retrieval key in the query token, and traverse the obtained update operation records in reverse order starting from the position indicated by the first update count, decrypt each update operation record to obtain the hash value of its corresponding first operation type and first file identifier, and perform the corresponding operation in the target data group corresponding to the group index in the keyword ciphertext storage pool according to the hash value of the first operation type and the first file identifier. The decryption module 16 is used to receive the first file identifier ciphertext in the updated target data group returned by the server, decrypt the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword; the first file identifier ciphertext is the ciphertext generated by encrypting the target file identifier corresponding to the target file associated with the target keyword.

[0141] Optionally, the decryption module 16 is further configured to: control the search counter to increment by one to obtain the second search count corresponding to the current target keyword; and control the update counter to set to 0 to obtain the second update count corresponding to the current target keyword.

[0142] Optionally, the decryption module 16 is further configured to: respond to an update request triggered by a user for the target keyword, obtain a third update count and a third search count corresponding to the current target keyword; the update request includes a second operation type to be performed on the file associated with the target keyword; determine a second file identifier corresponding to the file associated with the target keyword; control the update counter to be incremented by one to update the third update count to a fourth update count corresponding to the current target keyword; generate a search index and operation type ciphertext corresponding to the current update operation based on the fourth update count and the second operation type; encrypt the second file identifier using the symmetric key corresponding to the client through the SM4 algorithm to obtain a second file identifier ciphertext; send the update operation ciphertext containing the search index, the operation type ciphertext, and the second file identifier ciphertext to the server, so that the server uses the search index as the index key to write the operation type ciphertext and the second file identifier ciphertext as corresponding storage values ​​into the update operation storage pool.

[0143] Optionally, the decryption module 16 is further configured to: generate a second retrieval key based on the third search count, the target keyword, and the master key; generate the file identifier encryption key based on the target keyword and the master key; perform an SM3 hash operation on the second file identifier using the file identifier encryption key to generate a hash value for the file identifier; and generate a search index and operation type ciphertext corresponding to the current update operation based on the second retrieval key, the fourth update count, the second operation type, and the hash value.

[0144] Optionally, the first generation module 12 is specifically used to: obtain a master key; concatenate the target keyword and the first search count to obtain a first concatenated string; and generate a first retrieval key using a message checksum function based on the SM3 algorithm, with the master key as the key and the first concatenated string as the data.

[0145] Optionally, the determining module 13 is specifically used to: obtain the master key; and generate a file identification encryption key using the master key as the key and the target keyword as the data through a message checksum function based on the SM3 algorithm.

[0146] Optionally, the determining module 13 is specifically used to: perform an SM3 hash operation on a string of all zero bits of length λ using the file identifier encryption key to generate the group index to which the target keyword belongs in the keyword ciphertext storage pool.

[0147] Figure 6 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0148] In one possible design, the above Figure 6 The structure of the encrypted retrieval device shown can be implemented as an electronic device, such as... Figure 7 As shown, the electronic device may include: a memory 21, a processor 22, and a communication interface 23. The memory 21 stores executable code, which, when executed by the processor 22, enables the processor 22 to at least implement the encrypted retrieval method performed by the client as provided in the foregoing embodiments.

[0149] Figure 8 This is a schematic diagram of another encrypted text retrieval device provided in an embodiment of this application, applied to a server, such as... Figure 8 As shown, the device includes: a receiving module 31, an acquisition module 32, a decryption module 33, a processing module 34, and a sending module 35.

[0150] The receiving module 31 is used to receive a query token sent by the client. The query token includes a first update count, a group index, and a first retrieval key. The first update count is the number of updates corresponding to the current target keyword. The group index is generated based on the file identifier encryption key. The first retrieval key is generated based on the target keyword and the first search count corresponding to the current target keyword. The acquisition module 32 is used to acquire all update operation records corresponding to the target keyword from the update operation storage pool according to the first retrieval key; The decryption module 33 is used to traverse the obtained update operation records in reverse order starting from the position indicated by the first update count, decrypt each update operation record, and obtain the hash value of its corresponding first operation type and first file identifier. Processing module 34 is used to perform corresponding operations in the target data group corresponding to the grouping index in the keyword ciphertext storage pool according to the first operation type and the hash value of the first file identifier, so as to obtain the updated target data group; The sending module 35 is used to send the first file identifier ciphertext in the updated target data group to the client, so that the client can decrypt the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword.

[0151] Optionally, the decryption module 32 is specifically used to: iteratively execute the following process until all update operation records corresponding to the target keyword are retrieved from the update operation storage pool; use the first retrieval key to perform an SM3 hash operation on the current update count to obtain a hash operation result; the initial value of the current update count is the first update count; use the high bits of the hash operation result as the search index corresponding to the update operation associated with the current update count, and use the low bits of the hash operation result as the decryption mask corresponding to the update operation associated with the current update count; obtain the operation type ciphertext and the second file identifier ciphertext corresponding to the search index from the update operation storage pool; the operation type ciphertext is the ciphertext obtained by encrypting the operation type corresponding to the update operation, and the second file identifier ciphertext is the ciphertext obtained by encrypting the file identifier of the file targeted by the update operation.

[0152] Optionally, the decryption module 32 is specifically used to: iteratively execute the following process until the update count is 0; obtain the decryption mask and operation type ciphertext corresponding to the update operation associated with the current update count; perform an XOR operation on the decryption mask and the operation type ciphertext to decrypt the hash value of the first operation type and the first file identifier corresponding to the update operation associated with the current update count.

[0153] Optionally, the processing module 34 is specifically used to: if the first operation type is a deletion operation, add the hash value of the first file identifier to the deleted file identifier set; obtain the target data group corresponding to the group index from the keyword ciphertext storage pool; delete the file identifier ciphertext corresponding to the hash value of the first file identifier in the target data group to obtain the updated target data group.

[0154] Optionally, the processing module 34 is specifically used to: if the first operation type is an add operation and the hash value of the first file identifier is not included in the deleted file identifier set, then add the hash value of the first file identifier and the file identifier ciphertext corresponding to the hash value of the first file identifier to the target data group in the keyword ciphertext storage pool.

[0155] Optionally, the sending module 35 is further configured to: delete all update operation records corresponding to the target keyword in the update operation storage pool. Figure 8 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0156] In one possible design, the above Figure 8 The structure of the encrypted retrieval device shown can be implemented as an electronic device, such as... Figure 9 As shown, the electronic device may include: a memory 41, a processor 42, and a communication interface 43. The memory 41 stores executable code, which, when executed by the processor 42, enables the processor 42 to at least implement the encrypted retrieval method performed by the server as provided in the foregoing embodiments.

[0157] Furthermore, this application embodiment also provides a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the encrypted retrieval method provided in the foregoing embodiments.

[0158] In addition, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, enable the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by a computer program or instructions.

[0159] In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0160] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0161] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a necessary general-purpose hardware platform, or by a combination of hardware and software. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a computer product. This application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0162] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for retrieval encrypted text, characterized in that, Applied to a client, the method includes: In response to a user's search request triggered for a target keyword, the system obtains the first update count and the first search count corresponding to the target keyword; the first update count is the cumulative number of all update operations corresponding to the target keyword in the server-side update operation storage pool; the first search count is the cumulative number of times the user triggers a search request for the target keyword through the client. A first retrieval key is generated based on the first search count and the target keyword; A file identifier encryption key is generated based on the target keyword, and the group index to which the target keyword belongs in the keyword ciphertext storage pool on the server is determined based on the file identifier encryption key; wherein, the keyword ciphertext storage pool uses a group storage form to store the file identifier ciphertext corresponding to each keyword, and the file identifier ciphertext of the same keyword is stored in the same data group of the keyword ciphertext storage pool; Generate a query token based on the first update count, the grouping index, and the first retrieval key; The query token is sent to the server, so that the server retrieves all update operation records corresponding to the file associated with the target keyword from the update operation storage pool according to the first retrieval key in the query token. Starting from the position indicated by the first update count, the server traverses the retrieved update operation records in reverse order, decrypts each update operation record to obtain the hash value of its corresponding first operation type and first file identifier, and performs the corresponding update operation in the target data group corresponding to the group index in the keyword encrypted storage pool according to the first operation type and the hash value of the first file identifier, to obtain the updated target data group; wherein, the update operation storage pool stores update operation records that the server has not yet executed. The system receives the first file identifier ciphertext from the updated target data group returned by the server, decrypts the first file identifier ciphertext, and obtains the target file identifier corresponding to the target keyword; the first file identifier ciphertext is the ciphertext generated by encrypting the target file identifier corresponding to the file associated with the target keyword. The method further includes: In response to an update request triggered by a user for the target keyword, obtain the third update count and the third search count corresponding to the target keyword; the update request includes a second operation type to be performed on the file associated with the target keyword; Determine the second file identifier corresponding to the file associated with the target keyword; The control update counter is incremented by one to update the third update count to the fourth update count corresponding to the current target keyword; Based on the fourth update count and the second operation type, generate the search index and operation type ciphertext corresponding to the current update operation; The second file identifier is encrypted using the SM4 algorithm and the symmetric key corresponding to the client, resulting in the ciphertext of the second file identifier. The update operation ciphertext, which includes the search index, the operation type ciphertext, and the second file identifier ciphertext, is sent to the server so that the server uses the search index as the index key to write the operation type ciphertext and the second file identifier ciphertext as corresponding storage values ​​into the update operation storage pool.

2. The method according to claim 1, characterized in that, After decrypting the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword, the method further includes: The search counter is incremented by one to obtain the second search count corresponding to the current target keyword; Set the update counter to 0 to obtain the second update count corresponding to the current target keyword.

3. The method according to claim 1, characterized in that, The step of generating the search index and operation type ciphertext corresponding to the current update operation based on the fourth update count and the second operation type includes: A second search key is generated based on the third search count, the target keyword, and the master key; Generate the file identification encryption key based on the target keyword and master key; The second file identifier is hashed using the file identifier encryption key to generate a hash value for the file identifier; Based on the second retrieval key, the fourth update count, the second operation type, and the hash value, generate the search index and operation type ciphertext corresponding to the current update operation.

4. The method according to claim 1, characterized in that, The step of generating a first retrieval key based on the first search count and the target keyword includes: Obtain the master key; The target keyword and the first search count are concatenated to obtain the first concatenated string; Using the SM3 algorithm-based message verification code function, the master key is used as the key and the first concatenated string is used as the data to generate the first retrieval key.

5. The method according to claim 1, characterized in that, The step of generating a file identifier encryption key based on the target keyword includes: Obtain the master key; Using a message verification code function based on the SM3 algorithm, a file identification encryption key is generated using the master key as the key and the target keyword as the data.

6. The method according to claim 5, characterized in that, The step of determining the group index to which the target keyword belongs in the keyword ciphertext storage pool on the server, based on the file identifier encryption key, includes: The file identifier encryption key is used to perform an SM3 hash operation on a string of all zero bits of length λ to generate the group index to which the target keyword belongs in the keyword ciphertext storage pool.

7. A method for retrieval encrypted text, characterized in that, Applied to the server side, the method includes: The system receives a query token sent by the client. The query token includes a first update count, a group index, and a first retrieval key. The first update count is the cumulative number of all update operations corresponding to the target keyword in the server-side update operation storage pool. The group index is generated based on the file identifier encryption key. The first retrieval key is generated based on the target keyword and the first search count corresponding to the current target keyword. The first search count is the cumulative number of times the user triggers a search request for the target keyword through the client. Based on the first retrieval key, retrieve all update operation records corresponding to the file associated with the target keyword from the update operation storage pool; wherein, the update operation storage pool stores update operation records that have not yet been executed by the server; Starting from the position indicated by the first update count, traverse the obtained update operation records in reverse order, decrypt each update operation record, and obtain the hash value of its corresponding first operation type and first file identifier; Based on the first operation type and the hash value of the first file identifier, a corresponding update operation is performed in the target data group corresponding to the group index in the keyword ciphertext storage pool to obtain the updated target data group; wherein, the keyword ciphertext storage pool uses a group storage form to store the file identifier ciphertext corresponding to each keyword, and the file identifier ciphertext of the same keyword is stored in the same data group of the keyword ciphertext storage pool. The first file identifier ciphertext in the updated target data group is sent to the client so that the client can decrypt the first file identifier ciphertext to obtain the target file identifier corresponding to the target keyword; The method further includes: The system receives an update operation ciphertext sent by the client, which includes a search index, an operation type ciphertext, and a second file identifier ciphertext. Using the search index as the index key, the system writes the operation type ciphertext and the second file identifier ciphertext as corresponding storage values ​​into the update operation storage pool. The search index and operation type ciphertext are generated by the client in response to a user's update request for the target keyword, based on a fourth update count and a second operation type. The update request includes the second operation type to be performed on the file associated with the target keyword. The fourth update count is obtained by incrementing an update counter to update the current third update count for the target keyword to the fourth update count. The second file identifier ciphertext is obtained by encrypting the second file identifier corresponding to the file associated with the target keyword using the SM4 algorithm and the client's corresponding symmetric key.

8. The method according to claim 7, characterized in that, The step of retrieving all update operation records corresponding to the target keyword from the update operation storage pool based on the first retrieval key includes: The following process is executed iteratively until all update operation records corresponding to the target keyword are retrieved from the update operation storage pool; Using the first retrieval key, perform an SM3 hash operation on the current update count to obtain the hash result; the initial value of the current update count is the first update count. The high bits of the hash operation result are used as the search index corresponding to the update operation associated with the current update count, and the low bits of the hash operation result are used as the decryption mask corresponding to the update operation associated with the current update count. From the update operation storage pool, obtain the operation type ciphertext and the second file identifier ciphertext corresponding to the search index; the operation type ciphertext is the ciphertext obtained by encrypting the operation type corresponding to the update operation, and the second file identifier ciphertext is the ciphertext obtained by encrypting the file identifier of the file targeted by the update operation.

9. The method according to claim 8, characterized in that, The step of traversing the obtained update operation records in reverse order starting from the position indicated by the first update count, decrypting each update operation record to obtain its corresponding first operation type and first file identifier, includes: The following process is executed iteratively until the update count is 0; Obtain the decryption mask and operation type ciphertext corresponding to the update operation associated with the current update count; Perform an XOR operation on the decryption mask and the operation type ciphertext to decrypt the hash value of the first operation type and the first file identifier corresponding to the update operation associated with the current update count.

10. The method according to claim 9, characterized in that, The step of performing corresponding operations in the target data group corresponding to the grouping index in the keyword ciphertext storage pool according to the first operation type and the hash value of the first file identifier to obtain the updated target data group includes: If the first operation type is a deletion operation, then the hash value of the first file identifier is added to the deleted file identifier set; Obtain the target data group corresponding to the group index from the keyword encrypted storage pool; Delete the file identifier ciphertext corresponding to the hash value of the first file identifier in the target data group to obtain the updated target data group.

11. The method according to claim 10, characterized in that, The method further includes: If the first operation type is an add operation and the set of deleted file identifiers does not include the hash value of the first file identifier, then the hash value of the first file identifier and the ciphertext of the file identifier corresponding to the hash value of the first file identifier are added to the target data group in the keyword ciphertext storage pool.

12. The method according to claim 8, characterized in that, After sending the first file identifier ciphertext in the updated target data group to the client, the method further includes: Delete all update operation records corresponding to the target keyword from the update operation storage pool.

13. An electronic device, characterized in that, include: The device includes a memory, a processor, and a communication interface; wherein the memory stores executable code, which, when executed by the processor, causes the processor to perform the encrypted retrieval method as described in any one of claims 1 to 7 or claims 8 to 12.

Images