A single-server pre-processing PIR dynamic update method

Abstract

This invention provides a dynamic update method for single-server preprocessing of Private Information Retrieval (PIR), including an offline preprocessing stage, a dynamic database update stage, an online query stage, and an update stage. Based on the existing single-server preprocessing PIR retrieval scheme Piano, this invention adds support for dynamic database operations, supporting CRUD (Create, Read, Update) operations on the database. Unlike the cumbersome preprocessing work of comparable schemes, this invention introduces incremental preprocessing technology, allowing the original preprocessing to continue to be used after database changes, while incurring update costs proportional to the number of changes, rather than proportional to the size of the database. Compared to existing technologies, this invention reduces total communication costs, client computation time, and client storage space.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a dynamic update method for preprocessing PIR on a single server. Background Technology

[0002] Private Information Retrieval (PIR) is a privacy-preserving technology designed to allow users to retrieve information from a database without revealing the specific content of the information they are retrieving. In today's cloud-based information systems, the trend of storing many files and databases on external data storage servers is increasingly prevalent. While outsourcing databases can save on maintenance costs and improve information retrieval efficiency, its security and confidentiality face significant risks. PIR imposes a computational linear lower bound because the database must operate on all objects to answer a query. After all, even omitting an object when answering a query reveals that the client is not interested in that object. To address this issue, an existing PIR approach follows the idea of ​​preprocessing the database offline to generate hints, and then using the hints in the online phase to answer one or more queries through sublinear computation and communication. "PIANO: Extremely Simple, Single-Server PIR with Sublinear Server Computation" constructs a single-server preprocessing private information retrieval (PIR) scheme with sublinear overhead that achieves an optimal trade-off between client storage and server computation. It is implemented... Server and client share the computation and Online communication, and requires The client-side storage is different from previous single-server PIR schemes that relied on heavy encryption mechanisms (such as homomorphic encryption). This scheme relies solely on pseudo-random functions (PRFs). In the offline preprocessing phase, the client downloads the entire database block by block in a streaming manner, generating an offset vector for each data block using the PRF key, constructing a main hint table and a backup hint table. In the online query phase, the client determines the data block containing the query element and the pseudo-random offset vector, sends the processed pseudo-random set to the server, the server returns the corresponding set of elements, and the client recovers the required element through an XOR operation. In the update phase, the client replaces consumed items in the main hint table with the backup hint table. The backup hint table prepared in the preprocessing phase supports multiple queries, achieving efficient privacy-preserving queries and updates. PIANO is the first practical single-server sublinear-time PIR scheme, with performance 10-300 times higher than state-of-the-art single-server PIR schemes. Compared to the most well-known dual-server PIR schemes, PIANO offers comparable performance and is much simpler to construct.

[0003] However, if the database changes, all existing schemes must redo the costly offline phase. The existing literature, Zhou, A. Park, W. Zheng and E. Shi, "PIANO: Extremely Simple, Single-Server PIR with Sublinear Server Computation," in 2024 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2024, pp. 58-58, Appendix A.2, Supporting Dynamic Databases, discloses an update scheme with high communication overhead: each update Q requires a preprocessing phase for a Q-sized database. Each 2Q update requires a preprocessing phase for a 2Q-sized database. This continues, resulting in high total communication costs. Local storage overhead: each time the client performs a preprocessing phase for a layer, it requires additional local space to store hints, increasing the client's local storage requirements. Summary of the Invention

[0004] To address the aforementioned problems in the existing technology, this invention provides a dynamic update method for preprocessing PIR on a single server. The technical problem to be solved by this invention is achieved through the following technical solution:

[0005] This invention provides a dynamic update method for preprocessing PIR on a single server, comprising:

[0006] During the offline preprocessing stage, the client downloads data blocks from the server and extracts the elements of the downloaded data blocks according to the pre-generated offset vector; the main hint table and the backup hint table are constructed using the elements extracted from all data blocks.

[0007] During the dynamic database update phase, the server determines whether the number of update operations on its own database has reached Q times. If so, the update result of the database is fed back to the client. The client updates its own main hint table and backup hint table according to the update result.

[0008] During the online query phase, the client determines the data block containing the element to be queried and its offset vector, removes the offset vector of the element's position from the pseudo-random set, and then sends it to the server. The server traverses all possible positions to obtain the corresponding set of elements. The client recovers the element to be queried by performing an XOR operation on the elements in the set of elements.

[0009] During the update phase, the client updates the item corresponding to the element to be queried in the main hint table and replaces the item corresponding to the element to be queried with a spare item in the spare hint table; when the items in the spare hint table are exhausted, the client re-enters the offline preprocessing phase.

[0010] Beneficial effects:

[0011] This invention provides a dynamic update method for single-server preprocessing of Private Information Retrieval (PIR), including an offline preprocessing stage, a dynamic database update stage, an online query stage, and an update stage. Based on the existing single-server preprocessing PIR retrieval scheme Piano, this invention adds support for dynamic database operations, supporting CRUD (Create, Read, Update) operations on the database. Unlike the cumbersome preprocessing work of comparable schemes, this invention introduces incremental preprocessing technology, allowing the original preprocessing to continue to be used after database changes, while incurring update costs proportional to the number of changes, rather than proportional to the size of the database. Compared to existing technologies, this invention reduces total communication costs, client computation time, and client storage space.

[0012] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a dynamic update method for preprocessing PIR on a single server provided by the present invention.

[0014] Figure 2 This is a schematic diagram of the structure of a dynamic update method for preprocessing PIR on a single server provided by the present invention;

[0015] Figure 3 The latest update operation provided by this invention is the processing flow intention of the add operation. Detailed Implementation

[0016] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0017] Combination Figures 1 to 3 This invention provides a dynamic update method for preprocessing PIR on a single server, comprising:

[0018] During the offline preprocessing stage, the client downloads data blocks from the server and extracts the elements of the downloaded data blocks according to the pre-generated offset vector; the main hint table and the backup hint table are constructed using the elements extracted from all data blocks.

[0019] In this phase, the client downloads data blocks from the server's database in a streaming manner and stores them locally. The database includes multiple data blocks. Each time a data block is downloaded, it is processed according to a pre-generated pseudo-random offset vector set to extract the corresponding elements from the data block. The processed data block is then deleted from the local machine. A main hint table and a backup hint table are constructed using the elements of all data blocks.

[0020] It is worth noting that the client processes each data block it downloads. The processing requires generating a pseudo-random offset vector using the PRF key beforehand. The processing is repeated until the data block is completely processed. During the processing, a main hint table and a backup hint table are constructed.

[0021] During the dynamic database update phase, the server determines whether the number of update operations on its own database has reached Q times. If so, the update result of the database is fed back to the client. The client updates its own main hint table and backup hint table according to the update result.

[0022] It's worth noting that when database changes occur, the server checks these updates after a certain number of accumulated update operations or query requests. The server sends the latest operation on the same element to the client. For insert operations, the server sends the newly added data item, and the client increments the number of columns in the pseudo-random offset vector. If the pseudo-random offset vector of the data item is in the pseudo-random set, both the primary and secondary hint tables are updated. For replacement operations, the client updates the primary and secondary hint tables based on the changes in the old and new values. For deletion operations, the client updates the primary and secondary hint tables based on the deleted data.

[0023] During the online query phase, the client determines the data block containing the element to be queried and its offset vector, removes the offset vector of the element's position from the pseudo-random set, and then sends it to the server. The server traverses all possible positions to obtain the corresponding set of elements. The client recovers the element to be queried by performing an XOR operation on the elements in the set of elements.

[0024] It's worth noting that the client determines the data block containing the element to be queried and its pseudo-random offset vector. The client queries the pseudo-random set containing the element's position. After removing the element's pseudo-random offset vector, the client sends the pseudo-random set to the server. The server iterates through all possible positions, calculates and sends back the corresponding set of database elements. The client uses this data to recover the value of the desired element through an XOR operation.

[0025] During the update phase, the client updates the item corresponding to the element to be queried in the main hint table and replaces the item corresponding to the element to be queried with a spare item in the spare hint table; when the items in the spare hint table are exhausted, the client re-enters the offline preprocessing phase.

[0026] It's worth noting that the client updates consumed items in the main hint table. Used items in the main hint table are replaced with alternative hints from the alternative hint table. When the alternative hint table is exhausted, another preprocessing operation is required.

[0027] Building upon the existing single-server preprocessing Private Information Retrieval (PIR) scheme, Piano, this invention adds support for dynamic database operations, enabling CRUD (Create, Read, Update, Delete) database operations. Unlike existing schemes that repeatedly perform cumbersome preprocessing, this invention introduces an incremental preprocessing technique using pseudo-random offset vector sets. This allows the original preprocessing to be reused after database changes, while incurring update costs proportional to the number of changes, rather than proportional to the database size. Compared to existing schemes, this reduces overall communication costs, client computation time, and client storage space.

[0028] In one specific embodiment of the present invention, the process of generating a pseudo-random offset vector set includes:

[0029] Select M1 PRF keys, represented as

[0030] in, α(κ) represents a function greater than any constant. As the predetermined parameter κ increases, the value of the function α(κ) also increases. n represents the total number of elements in all data blocks. Θ() represents the asymptotically tight bound of the function within the parentheses.

[0031] For any one of the M1 PRF keys Using this key sk, a pseudo-random offset vector is generated for the main hint table, denoted as:

[0032] in, This indicates that the key sk is used for the input data. The encrypted result, the output range of PRF is This represents a pseudo-random offset vector in each data block;

[0033] for Select M2 PRF keys, represented as

[0034] Among them, M2=Θ(logκ·α(κ));

[0035] For any one of the M2 PRF keys Using this key Generate a pseudo-random offset vector for the backup hint table, represented as:

[0036]

[0037] In one specific embodiment of the present invention, constructing the main hint table and the backup hint table using elements of all data blocks includes:

[0038] Initialize the element values ​​at all positions in the main hint table. Set to 0 and initialize the element values ​​at all positions in the spare hint table. =0;

[0039] All elements p of the data block j The main hint table is obtained by filling in the corresponding positions in the main hint table, representing...

[0040]

[0041] All elements of the data block Fill in the corresponding positions in the alternative hint table to obtain the alternative hint table, which is represented as follows:

[0042] Each data block is represented as The mapping between data blocks and their corresponding pseudo-random offset vectors in the database is represented by Set variables. All Set variables corresponding to these variables on the client side form a Set variable set, represented as follows:

[0043]

[0044] In one specific embodiment of the present invention, during the database dynamic update phase,

[0045] The server determines whether the number of update operations on its own database has reached Q. If so, it sends the latest update operation of the same element in the data block and the corresponding data item to the client.

[0046] The latest update operations include add, replace, and delete operations;

[0047] If the client determines that the latest update operation is an insert operation, it generates a pseudo-random offset vector to generate an additional item in response to the insert operation, and determines whether the generated additional item is in the Set variable set in the database. If it is, the main hint table and the backup hint table are updated; otherwise, no update is performed. If the latest update operation is a replacement operation, the main hint table and the backup hint table are updated according to the change between the old and new values. If the latest update operation is a deletion operation, the deletion operation is performed to delete the corresponding data, and the main hint table and the backup hint table are updated.

[0048] It is worth noting that when the database is changed, Every Q update operations (if a client initiates a query request, it is sent immediately even if there are fewer than Q updates), the server checks these Q updates, and for identical operations on the same element, it takes the latest operation and then sets {(index,pre_val,val)}. j} j∈Q Send to the client (if it is an add operation, pre_val is 0; if it is a delete operation, val is ⊥).

[0049] In one specific embodiment of the present invention, during the database dynamic update phase...

[0050] refer to Figure 3 The server determines whether the number of update operations on its own database has reached Q.

[0051]

[0052] If the number of update operations reaches Q, then for the same element in the data block, the latest update operation is taken, and the latest update operation and the corresponding data item {(index,pre_val,val)} are stored together. j} j∈Q Send to the client; where index represents the index value of the element being modified, pre_val represents the value of the element before the change, and val represents the value of the element after the change. If the latest update operation is an insert operation, then pre_val is 0; if it is a delete operation, then val is ⊥.

[0053] The client receives the corresponding data item {(index,pre_val,val)}.j} j∈Q Then, determine whether the latest update operation is an add, replace, or delete operation;

[0054] If it is an add operation, add the required m data items. Data blocks; for each sk in the main hint table and the alternate hint table, generate a k-column pseudo-random offset vector for each Set variable, represented as:

[0055] After generating k-column pseudo-random offset vectors, if Then update the main hint table and the backup hint table;

[0056] It's worth noting that if the server database is performing an insert operation, assuming m data items are added, that is, adding... For each data block, the client performs an incremental update operation on the set for each sk, that is, generates k additional pseudo-random offset vectors for each set.

[0057] If it is a replacement operation, then the index is at the [number]th position. In each data block, if for each sk Then update the main hint table and the backup hint table;

[0058] If it is a deletion operation, then the index is at the [number]th position. In each data block, for each sk,

[0059] Then update the main hint table and the backup hint table.

[0060] In one specific embodiment of the present invention, during the online query phase,

[0061] The client determines that it needs to query the element with index x in the database and its corresponding pseudo-random offset vector, where x is at the 1st index. In the i-th data block * The pseudo-random offset vector of each data block is δ i =

[0062]

[0063] Selecting the i-th variable from the Set variable set * The pseudo-random offset vector δ of the data block i Multiple corresponding Set variables Remove the i-th * A worthwhile Send to the server;

[0064] The server utilizes Traverse the database itself to determine the i-th element to be removed. * The position of each value in the database is used to recover δ. i The mapped Set variable is obtained by XORing all values ​​in the Set variable. Results Send to the client;

[0065] It's worth noting that since the server doesn't know which position of the value is being removed, it iterates through all possible positions, reconstructs the pseudo-random offset vector to match the actual index value in the database, and then XORs all the data at each index, resulting in a total of... Results Send to the client.

[0066] In sent to the client In the results,

[0067]

[0068]

[0069] ...

[0070]

[0071] ...

[0072]

[0073] The client follows right Perform an XOR operation to obtain the element with index x.

[0074] In one specific embodiment of the present invention, replacing the item corresponding to the element to be queried with a spare item from the spare hint table includes:

[0075] Select the i-th option from the list of available hints. * One backup item And according to the formula XOR replaces the item corresponding to the element queried in the main hint table with the result of the XOR operation.

[0076] It's worth noting that since the online query phase consumed one entry in the main hint table (which loses its privacy after being sent to the server and cannot be reused), it is now being updated and replaced. The replacement method starts from the i-th... * Select from the backup hint table use Replace the corresponding item in the main hint table.

[0077] It is worth noting that the terms "first" and "second" in this invention are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0078] Although this application has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings, the disclosure, and the appended claims in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality.

[0079] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for dynamically updating a single-server preprocessed PIR, characterized in that, include: During the offline preprocessing stage, the client downloads data blocks from the server and extracts the elements of the downloaded data blocks according to the pre-generated offset vector; Construct a main hint table and a backup hint table using elements extracted from all data blocks; PIR stands for Private Information Retrieval. During the dynamic database update phase, the server determines whether the number of update operations on its own database has reached Q times. If so, the update result of the database is fed back to the client. The client updates its own main hint table and backup hint table according to the update results; During the online query phase, the client determines the data block containing the element to be queried and its offset vector, removes the offset vector of the element's position from the pseudo-random set, and then sends it to the server. The server traverses all possible positions to obtain the corresponding set of elements. The client recovers the element to be queried by performing an XOR operation on the elements in the set of elements. During the update phase, the client updates the item corresponding to the element to be queried in the main hint table and replaces the item corresponding to the element to be queried with a spare item in the spare hint table; when the items in the spare hint table are exhausted, the client re-enters the offline preprocessing phase. During the dynamic update phase of the database The server determines whether the number of update operations on its own database has reached Q. If so, it sends the latest update operation of the same element in the data block and the corresponding data item to the client. The latest update operations include add, replace, and delete operations; If the client determines that the latest update operation is an insert operation, it generates a pseudo-random offset vector to generate an additional item in response to the insert operation, and then determines whether the generated additional item exists in the database. If the variables are in a set, update the main hint table and the backup hint table; otherwise, do not update them. If the latest update operation is a replacement operation, update the main hint table and the backup hint table according to the change in the old and new values. If the latest update operation is a deletion operation, then the deletion operation is performed to delete the corresponding data, and the main hint table and the backup hint table are updated.

2. The dynamic update method for single-server preprocessing PIR according to claim 1, characterized in that, During the offline preprocessing phase, the client performs the following procedure: Data blocks are downloaded from the server's database using a streaming method and stored locally, wherein the database includes multiple data blocks; Each time a data block is downloaded, the data block is processed according to a pre-generated set of pseudo-random offset vectors to extract the corresponding elements from the data block; Delete the processed data block from the local machine; Construct the main hint table and the alternate hint table using the elements of all data blocks.

3. The dynamic update method for single-server preprocessing PIR according to claim 2, characterized in that, The process of generating the pseudo-random offset vector set includes: Select A PRF key, represented as ; in, , Let represent a function greater than any constant, which increases with the predetermined parameter κ. The function value also keeps increasing. This represents the total number of elements in all data blocks. Indicates the asymptotically tight bound of the function within the parentheses; against Any key from the PRF keys Using the key Generate a pseudo-random offset vector for the main hint table, denoted as: ; in, This indicates that the key sk is used for the input data. The encrypted result, the output range of PRF is [0, ] represents the pseudo-random offset vector in each data block; Select A PRF key, represented as ; in, ; against Any key from the PRF keys Using this key Generate a pseudo-random offset vector for the backup hint table, represented as: 。 4. The dynamic update method for single-server preprocessing PIR according to claim 3, characterized in that, The construction of the main hint table and the backup hint table using elements from all data blocks includes: Initialize the element values ​​at all positions in the main hint table. Set to 0 and initialize the element values ​​at all positions in the spare hint table. =0; All elements of the data block The main hint table is obtained by filling in the corresponding positions in the main hint table, and is represented as follows: , , ; All elements of the data block Fill in the corresponding positions in the alternative hint table to obtain the alternative hint table, which is represented as follows: , , ; Each data block is represented as The mapping between data blocks and their corresponding pseudo-random offset vectors in the database is represented by Set variables. All Set variables corresponding to the client form a Set variable set, represented as follows: , Indicates the first A pseudo-random offset vector for each data block.

5. The dynamic update method for single-server preprocessing PIR according to claim 4, characterized in that, During the database dynamic update phase, The server determines whether the number of update operations on its own database has reached Q. ; If the number of update operations reaches Q, then for identical operations on the same element in the data block, take the latest update operation and then combine the latest update operation with the corresponding data item. Send to the client; among them, This indicates the index value of the element being modified. This represents the value of the element before it was changed. This represents the value of the element after it has been modified. If the latest update operation is an insert operation, then pre_val is 0; if it is a delete operation, then val is ⊥. The client receives the corresponding data item. Then, determine whether the latest update operation is an add, replace, or delete operation; If it is an add operation, add k= as needed for the m data items to be added. Each data block; for each in the main hint table and the alternate hint table. For each Set variable, generate a k-column pseudo-random offset vector, represented as: , After generating k pseudo-random offset vectors, if Then update the main hint table and the backup hint table; If it is a replacement operation, then the index is at the [number]th position. In each of the data blocks =index val If pre_val, then update the main hint table and the backup hint table; If it is a deletion operation, then the index is at the [number]th position. In each of the data blocks , Then update the main hint table and the backup hint table.

6. The dynamic update method for single-server preprocessing PIR according to claim 4, characterized in that, During the online search phase, The client determines that it needs to query the element with index x in the database and its corresponding pseudo-random offset vector, where x is at the 1st index. In the data block, the first The pseudo-random offset vector of each data block is ; Select the first variable from the Set variable set. pseudo-random offset vectors of data blocks Multiple corresponding Set variables Remove the first A worthwhile , Send it to the server; The server utilizes , Iterate through its own database to determine the first item to remove. The position of each value in the database, and the value recovered from that position. The mapped Set variable is obtained by XORing all values ​​in the Set variable. Send to the client; The client follows right Perform an XOR operation to obtain the element with index x.

7. The dynamic update method for single-server preprocessing PIR according to claim 4, characterized in that, The method of replacing the item corresponding to the element to be queried with a spare item from the spare hint table includes: From the spare Select the first One backup item ,and XOR replaces the item corresponding to the element queried in the main hint table with the result of the XOR operation.

Images