A method, system, server and client for enabling retrieval of private information

Abstract

The one or more embodiments of the specification provide a method, system, server and client for realizing privacy information retrieval. In the method, a server encrypts a database to obtain a query base and sends the query base to a client; the client and the server use an exchangeable order encryption / decryption algorithm for encryption / decryption performed on the same target; in a retrieval process, the client sends a sensitive field encrypted by itself to the server and obtains a same sensitive field encrypted by the server through interaction with the server; the client retrieves in the query base according to the sensitive field encrypted by the server to obtain an identification of a matching record; and the server and the client transmit a value of a field of interest in a record corresponding to the matching identification in the database to the client through a careless transmission mode.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of privacy computing technology, and in particular relate to a method, system, server, and client for implementing privacy information retrieval. Background Technology

[0002] Privacy-preserving computing is a set of technologies that enable data analysis and computation while protecting the data itself from external disclosure, achieving data usability without visibility. Through privacy-preserving computing technologies, the value of data can be transformed and released while fully protecting data and privacy.

[0003] Currently, the mainstream technologies for achieving privacy-preserving computation mainly fall into three categories: the first is cryptography-based privacy computation technology, represented by Secure Multi-Party Computation (SMPC); the second is technology derived from the integration of artificial intelligence and privacy protection technologies, represented by Federated Learning (FL); and the third is confidential computing (CC) technology based on trusted hardware, represented by Trusted Execution Environments (TEEs). In addition, differential privacy (DP) is also included. Differential privacy (DP) actually protects the computation result, not the computation process; while federated learning, secure multi-party computation, and confidential computing protect both the computation process and its intermediate results.

[0004] The first category of secure multi-party computation includes four fundamental technologies: Garbled Circuit (GC), Secret Sharing, Oblivious Transfer, and Homomorphic Encryption (HE). Homomorphic encryption is a special type of encryption algorithm that performs calculations directly on the ciphertext, yielding the same result as calculations based on the decrypted plaintext. It further includes Partially Homomorphic Encryption (PHE) and Fully Homomorphic Encryption (FHE).

[0005] Secure multi-party computation (SMPC) provides privacy protection for input secret data based on its solid security theoretical foundation, thus achieving security in the privacy-preserving computation process. Currently, there are two main implementation technical approaches to SMPC: general-purpose SMPC and problem-specific SMPC. The former can solve various computational problems, but this "universal" approach is usually large and has significant overhead. The latter designs dedicated protocols for specific problems, such as Private Set Intersection (PSI) and Privacy Information Retrieval (PIR), which often achieve computational results at a lower cost than general-purpose SMPC protocols. However, these protocols require careful design by domain experts for specific application scenarios, are generally not applicable to general scenarios, and have high design costs.

[0006] Privacy-preserving set intersection is the process by which participating parties obtain the intersection of their respective data sets without revealing any additional information. Additional information refers to any information beyond the intersection of their data sets. Privacy-preserving set intersection is extremely useful in real-world scenarios, such as data alignment in longitudinal federated learning or friend discovery using contact lists in social media.

[0007] Privacy information retrieval is a method by which a client retrieves information from a database. During the retrieval process, the querying party hides the identifier of the query target, and the data service provider provides matching query results without knowing the specific query target. Summary of the Invention

[0008] The purpose of this specification is to provide a method, system, server, and client for retrieving privacy information, including:

[0009] A method for retrieving privacy information involves the server encrypting a database to obtain a query base and sending the query base to the client; the client and server perform encryption / decryption on the same target using an encryption / decryption algorithm with interchangeable order.

[0010] A single search process includes:

[0011] The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server;

[0012] The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server;

[0013] The server and the client transmit the value of the field of interest in the record corresponding to the matching identifier in the database to the client through an unintentional transmission method.

[0014] A method for retrieving privacy information involves the server encrypting a database to obtain a query base and sending the query base to the client; the client and server perform encryption / decryption on the same target using an encryption / decryption algorithm with interchangeable order.

[0015] A single search process includes:

[0016] The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server;

[0017] The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server, and generates a confusion set of size m containing the fields of interest.

[0018] The server and the client transmit the value of the field indicated by the obfuscation set of size m in the matching record in the database to the client through an unintentional transmission method.

[0019] A method for retrieving privacy information involves the server encrypting a database to obtain a query base and sending the query base to the client; the client and server perform encryption / decryption on the same target using an encryption / decryption algorithm with interchangeable order.

[0020] A single search process includes:

[0021] The client sends its own encrypted sensitive field to the server and obtains the same encrypted sensitive field from the server through interaction with the server.

[0022] The client retrieves a matching identifier from the query base based on the sensitive fields encrypted by the server.

[0023] The server uses a double unintentional transmission method to return the value of the field of interest in the corresponding record of the predetermined size identifier set, including the matching identifier, in the database to the client; the double unintentional transmission method is a combination of unintentional transmission of the predetermined size identifier set and unintentional transmission of the field of interest.

[0024] A system for retrieving privacy information includes a server and a client. The client and server perform encryption / decryption on the same target using an encryption / decryption algorithm with an interchangeable order, and:

[0025] The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client.

[0026] During a search process:

[0027] The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server;

[0028] The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server;

[0029] The server and the client transmit the value of the field of interest in the record corresponding to the matching identifier in the database to the client through an unintentional transmission method.

[0030] A server for retrieving privacy information, wherein the server and client perform encryption / decryption on the same target using an encryption / decryption algorithm with interchangeable order, and:

[0031] The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client.

[0032] During a search process:

[0033] The server receives sensitive fields sent by the client, which it has encrypted, and then encrypts them again before returning them to the client. The server also transmits the values ​​of the fields of interest in the records corresponding to the matching identifiers in the database to the client via unintentional transmission.

[0034] A client for retrieving privacy information, wherein the client and server perform encryption / decryption on the same target using an encryption / decryption algorithm with interchangeable order, and:

[0035] The client is configured with a query base, which is obtained by the server after encrypting the database.

[0036] During a search process:

[0037] The client sends a sensitive field encrypted by itself to the server, and obtains the same sensitive field encrypted by the server through interaction with the server; the client also retrieves the identifier of the matching record in the query base based on the sensitive field encrypted by the server; the client also obtains the value of the field of interest in the record corresponding to the matching identifier in the database through unintentional transmission between the client and the server.

[0038] A system for retrieving privacy information includes a server and a client. The client and server perform encryption / decryption on the same target using an encryption / decryption algorithm with an interchangeable order, and:

[0039] The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client.

[0040] During a search process:

[0041] The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server;

[0042] The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server, and generates a confusion set of size m containing the fields of interest.

[0043] The server and the client transmit the value of the field indicated by the obfuscation set of size m in the matching record in the database to the client through an unintentional transmission method.

[0044] A system for retrieving private information includes a server and a client. The client and server perform encryption / decryption on the same target using an encryption / decryption algorithm with an interchangeable order, and:

[0045] The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client.

[0046] During a search process:

[0047] The client sends its own encrypted sensitive field to the server and obtains the same encrypted sensitive field from the server through interaction with the server.

[0048] The client retrieves a matching identifier from the query base based on the sensitive fields encrypted by the server.

[0049] The server uses a double unintentional transmission method to return the value of the field of interest in the corresponding record of the predetermined size identifier set, including the matching identifier, in the database to the client; the double unintentional transmission method is a combination of unintentional transmission of the predetermined size identifier set and unintentional transmission of the field of interest.

[0050] In the above embodiments, by pre-configuring the query base on the client, the client can locate the identifier of the field to be queried in the query base through interaction with the server and the query base without exposing the database in plaintext. The client then initiates a query to the server based on the identifier, ensuring the server's privacy protection of the database and supporting structured query statements. Furthermore, the transmission of the matching identifier's corresponding record / value of the field of interest in the corresponding record between the server and the client uses an inadvertent transmission method, thus not exposing the client's matching identifier to the server and protecting the client's privacy. Attached Figure Description

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

[0052] Figure 1 This is a flowchart illustrating one embodiment;

[0053] Figure 2 This is a flowchart illustrating one embodiment;

[0054] Figure 3 This is a flowchart illustrating one embodiment;

[0055] Figure 4 This is a flowchart of one embodiment. Detailed Implementation

[0056] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0057] As mentioned earlier, PIR (Proof-of-Reference) is a method for clients to retrieve information from a database. The PIR scheme was proposed by Chor B et al. in 1995 to address the protection of user query privacy. The main purpose of the PIR scheme is to ensure that queries submitted by users to the database on the server are completed without the leakage of the user's private information; that is, the server is unaware of the specific query information or the retrieved data items during the retrieval process.

[0058] Application scenarios for privacy information retrieval include:

[0059] i. If a patient wants to search for medications to treat their disease through the medical system, and the search is based on the disease name, the medical system will know that the patient may have such a disease, thus compromising the patient's privacy. Searching for private information can avoid this type of leakage.

[0060] ii. During the domain name and trademark application process, users need to submit their domain name or trademark information to the relevant database to check if it already exists, but they do not want the service provider to know their application name so that they can register it first.

[0061] iii. In the securities market, a user wants to query information about a certain stock, but cannot disclose the stock they are interested in to the service provider, thereby affecting the stock price and their own preferences.

[0062] A simple implementation involves the database sending all data to the client, but this fails to protect database security, meaning it cannot guarantee server-side privacy. A PIR that simultaneously guarantees privacy for both the client and the database is called a Symmetrical PIR (SPIR), while one that guarantees privacy for either the client or the database is called an Asymmetrical PIR (APIR). Based on the number of database replicas, PIRs are categorized into multi-replica PIRs and single-replica PIRs. Multi-replica PIR protocols require that multiple database replicas cannot collude, which is difficult to satisfy in real-world scenarios; therefore, single-replica PIRs are more commonly considered. Single-replica PIRs only achieve computational security (CPIR). Most PIR schemes assume the client knows which bit in the database they are retrieving (a single bit). However, in real-world scenarios, clients often search by keyword (without knowing the specific location of the keyword in the database) and expect to retrieve a string (multiple bits). In summary, a practical PIR typically needs to simultaneously satisfy multiple conditions, including symmetry, single copy, key-based retrieval, and string return, while achieving a balance between computational and communication efficiency. These conditions can be met or partially met through cryptographic techniques such as homomorphic encryption, oblivious transfer (OT), and one-way trapdoor functions.

[0063] This specification provides an embodiment of a method for retrieving privacy information.

[0064] In this embodiment, the server can encrypt the database in advance to obtain the query base and send the query base to the client.

[0065] Typically, the server has a local database that clients can query. A typical example of a local server database would be as follows:

[0066] id_0 A 24 anhui 263158 id_1 B 25 Shanghai 223700 id_2 C 30 anhui 193267 id_3 D 46 henan 183456 id_4 E 34 shandong 193345 id_5 F 54 Shanghai 271156 id_6 G 24 beijing 223455 id_7 H 34 shandong 274500 id_8 I 42 guangdong 805591 id_9 J 56 zhejiang 708947

[0067] Table 1. Databases available on the server

[0068] In the example in Table 1 above, there are four fields: ID, Name, Age, and Native_place. For example, there are 10 records, from id_0 to id_9, with each row representing one record. Here, id_0, ..., id_9 serve as the identifier for each record in each row.

[0069] To enable client-side retrieval without exposing server-side privacy, the server can encrypt the database to obtain the query base. Encryption methods can include RSA (a widely used asymmetric encryption algorithm proposed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman) or ECC (Elliptical Curve Cryptography). Specifically, the server can encrypt the data using an RSA private key / ECC private key α, meaning that every field except the ID column (i.e., the data in each cell) is encrypted using the RSA private key / ECC private key α.

[0070] When using the ECC encryption / decryption algorithm, the server can generate and securely store a secret value α, which is the ECC private key. Furthermore, the server can convert the value of the name field into a point on an elliptic curve using a hash function, which can be expressed as Hash(C) or H(C).

[0071] According to the operational properties of scalar multiplication on elliptic curves, given a point P on an elliptic curve and an integer k, it is easy to calculate Q = kP, and the result Q is also a point on the elliptic curve. Conversely, if a pair of points P and Q on the elliptic curve is known, it is difficult to find the value of k in Q = kP that makes the equation true.

[0072] Here, α·H(C) is easily calculated using scalar multiplication on elliptic curves, but knowing the result of α·H(C) and H(C) makes it difficult to deduce the value of α. Given the difficulty in obtaining the value of α, knowing the result of α·H(C) also makes it difficult to know the value of H(C).

[0073] Therefore, the database encrypted by the server using the secret value α is shown below:

[0074] id_0 α·H(A) α·H(24) α·H(anhui) α·H(263158) id_1 α·H(B) α·H(25) α·H(shanghai) α·H(223700) id_2 α·H(C) α·H(30) α·H(anhui) α·H(193267) id_3 α·H(D) α·H(46) α·H(henan) α·H(183456) id_4 α·H(E) α·H(34) α·H(shandong) α·H(193345) id_5 α·H(F) α·H(54) α·H(shanghai) α·H(271156) id_6 α·H(G) α·H(24) α·H(beijing) α·H(223455) id_7 α·H(H) α·H(34) α·H(shandong) α·H(274500) id_8 α·H(I) α·H(42) α·H(guangdong) α·H(805591) id_9 α·H(J) α·H(56) α·H(zjejiang) α·H(708947)

[0075] Table 2. Query base encrypted with ECC private key on the server side

[0076] It's important to note that the hash function described above not only converts the original input into a fixed-length, formatted output, but also converts the output into the x-axis coordinate of a point on an elliptic curve. For example, using an elliptic curve like curve25519, any 256-bit data can be used as a valid x-axis coordinate on this elliptic curve. Correspondingly, SHA256 or SHA3-256 can be used, or 256 bits can be truncated from the results of SHA384, SHA512, or SHA3-384, SHA3-512. More broadly, any hash value (not limited to a 256-bit hash result) can be modulo the order of the elliptic curve, and the product of the modulo result and the generator (scalar multiplication) represents a point on that elliptic curve.

[0077] Then, the server can send the query base to the client that needs to perform the retrieval. In one approach, the server can send the query base directly to the client, such as directly to the client's device or to the client's proxy server; in another approach, the server can publish the query base on a Uniform Resource Locator (URL), and the client can then obtain the query base from that URL.

[0078] Correspondingly, the client can receive the query base and store the received query base locally.

[0079] Similarly, when using RSA, the server can generate and securely store a secret value α, which is the RSA private key. Furthermore, the server can convert the value of the name field into a point on an elliptic curve using a hash function, which can be expressed as Hash(C) or H(C).

[0080] Based on the properties of modular exponentiation, given the secret value α, calculate p = g for a large prime number q and a base g. α Mod q is easy; conversely, if p, q, and the base g are known, solving p = g is straightforward. α Finding the value of α that makes the equation true in mod q is difficult. The base g is also called the primitive root.

[0081] Here, (H(C)) is calculated based on simulation operations. α Mod q is easy, but knowing (H(C)) is crucial. α The result modulo q, along with H(C) and q, makes it difficult to deduce the value of α. Given the difficulty in obtaining the value of α, knowing (H(C)) is insufficient. α The result of modulo q also makes it difficult to know the value of H(C). Subsequently, we will use the form (H(C)). αThe expression with mod q omitting mod q is abbreviated as (H(C)). α .

[0082] Therefore, the database encrypted by the server using the secret value α is shown below:

[0083] id_0 <![CDATA[(H(A)) α ]]> <![CDATA[(H(24)) α ]]> <![CDATA[(H(anhui)) α ]]> <![CDATA[(H(263158)) α ]]> id_1 <![CDATA[(H(B)) α ]]> <![CDATA[(H(25)) α ]]> <![CDATA[(H(shanghai)) α ]]> <![CDATA[(H(223700)) α ]]> id_2 <![CDATA[(H(C)) α ]]> <![CDATA[(H(30)) α ]]> <![CDATA[(H(anhui)) α ]]> <![CDATA[(H(193367)) α ]]> id_3 <![CDATA[(H(D)) α ]]> <![CDATA[(H(46)) α ]]> <![CDATA[(H(henan)) α ]]> <![CDATA[(H(183456)) α ]]> id_4 <![CDATA[(H(E)) α ]]> <![CDATA[(H(34)) α ]]> <![CDATA[(H(shandong)) α ]]> <![CDATA[(H(193345)) α ]]> id_5 <![CDATA[(H(F)) α ]]> <![CDATA[(H(54)) α ]]> <![CDATA[(H(shanghai)) α ]]> <![CDATA[(H(271156)) α ]]> id_6 <![CDATA[(H(G)) α ]]> <![CDATA[(H(24)) α ]]> <![CDATA[(H(beijing)) α ]]> <![CDATA[(H(223455)) α ]]> id_7 <![CDATA[(H(H)) α ]]> <![CDATA[(H(34)) α ]]> <![CDATA[(H(shandong)) α ]]> <![CDATA[(H(274500)) α ]]> id_8 <![CDATA[(H(I)) α ]]> <![CDATA[(H(42)) α ]]> <![CDATA[(H(guangdong)) α ]]> <![CDATA[(H(805591)) α ]]> id_9 <![CDATA[(H(J)) α ]]> <![CDATA[(H(56)) α ]]> <![CDATA[(H(zhejiang)) α ]]> <![CDATA[(H(708947)) α ]]>

[0084] Table 3. Query base encrypted with RSA private key on the server side

[0085] Then, the server can send the query base to the client that needs to perform the retrieval. Similarly, the server can send the query base directly to the client, for example, directly to the client's device, or to the client's proxy server; in another approach, the server can publish the query base on a Uniform Resource Locator (URL), and the client can then obtain the query base from that URL.

[0086] Correspondingly, the client can receive the query base and store the received query base locally.

[0087] S110: The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server.

[0088] For example, a client's search condition might be that the Age field value is 25, and 25 is a sensitive field that the client doesn't want the other end to know. To prevent the server from knowing that the client's search condition is the Age field value 25, the client can encrypt this 25. For example, it can use RSA / ECC private key encryption, and the encryption algorithm used by the client is the same as the encryption algorithm used by the server to generate the query base.

[0089] Specifically, when using RSA private key encryption, the client generates and securely stores its own secret β. Then, the client can encrypt 25 using its own private key β. Specifically, this can be done by encrypting 25 or its hash value. Here, we will use hash encryption of 25 as an example. The case of direct encryption of 25 is similar; the client and server use the same hash algorithm. For example, the client uses the same large prime number q as the modulus as the server. The client can use β to perform RSA encryption on the hash value of 25, obtaining (H(25)). β Therefore, the sensitive field sent by the client to the server can be (H(25)). β Among them, (H(25)) β This represents the ciphertext of the sensitive field's value 25.

[0090] On the other hand, the client can also construct a search statement, encrypt the sensitive fields in the search statement to obtain the privacy fields, replace the sensitive fields with the privacy fields, and send the replaced privacy search statement to the server.

[0091] For example, the client constructs the query statement as select Name where Age=25.

[0092] To protect privacy, specifically to prevent the server from accessing the query condition Age=25, for example, by protecting the 25, the result would be as follows:

[0093] select Name where Age=?

[0094] Where, ? represents the search statement after replacement.

[0095] Specifically, the client can encrypt 25 using an RSA private key. For example, the client can perform a hash calculation on 25 using the same hash function as the server, and then use β to encrypt the hash value of 25 using RSA, resulting in (H(25)). β The query statement sent by the client to the server would be, for example, as follows:

[0096] select Name where Age=(H(25)) β

[0097] As mentioned earlier, (H(25)) β This is encrypted text, which is the content represented by "?" in the above search statement. The server cannot know β and 25 after obtaining it.

[0098] When using ECC private key encryption, the client uses the same elliptic curve as the server, meaning it has the same elliptic curve parameters and generators. The client generates its own secret β and stores it securely. Then, the client can encrypt 25 using its own private key β. Specifically, it can encrypt the hash value of 25, using the same hash algorithm as the server. For example, the client can use β to perform ECC encryption on the hash value of 25, obtaining β·H(25). The sensitive field sent by the client to the server can then be β·H(25), where β·H(25) represents the ciphertext of the sensitive field value 25.

[0099] On the other hand, the client can also construct a search statement, encrypt the sensitive fields in the search statement to obtain the privacy fields, replace the sensitive fields with the privacy fields, and send the replaced privacy search statement to the server.

[0100] For example, the client constructs the query statement as select Name where Age=25.

[0101] To protect privacy, specifically to prevent the server from accessing the query condition Age=25, for example, by protecting the 25, the result would be as follows:

[0102] select Name where Age=?

[0103] Where, ? represents the search statement after replacement.

[0104] Specifically, the client can encrypt 25 using its ECC private key. For example, the client uses the same elliptic curve as the server, meaning it has the same elliptic curve parameters and generators. The client can replace sensitive fields in the search query with its own ECC private key and send the replaced privacy search query to the server. For example, the client generates its own secret β and stores it securely. In addition, the client can perform a hash calculation on 25 using the same hash function as the server, and then use β to perform ECC encryption on the hash value of 25, obtaining β·H(25). The query query sent by the client to the server would be as follows:

[0105] select Name where Age=β·H(25)

[0106] As mentioned earlier, β·H(25) is ciphertext, which is the content represented by "?" in the above search statement. The server cannot know β and 25 after obtaining it.

[0107] The client obtains the same sensitive field encrypted by the server through interaction with the server. This can include the server re-encrypting the sensitive field encrypted by the client using its own key and sending it to the client, and the client decrypting the double-encrypted sensitive field using its own key to obtain the sensitive field encrypted by the server. The core of this concept is finding an encryption algorithm that allows for decryption in interchangeable orders after two consecutive encryption operations (encryption by both parties sequentially). Based on the cryptographic properties of ECC, both parties agree to use the same elliptic curve, meaning they have the same elliptic curve parameters and generators, and each holds private keys α and β. The encryption operation involves scalar multiplication using α (or β). Regardless of whether α is used first followed by β or vice versa, the encryption result can be decrypted in the same or different orders. Similarly, based on the cryptographic properties of RSA, both parties agree to use the same large prime number q and primitive root g, each holding a private key α and β. The encryption operation involves exponentiation of α (or β) and modulo of q. Regardless of whether α is used first and then β, or vice versa, the encryption result can be decrypted in the same or different orders. In short, the client and server use interchangeable encryption / decryption algorithms for the same target.

[0108] Specifically, the server can receive a privacy search query, encrypt the privacy fields again, and then return them to the client. Alternatively, the server can receive sensitive fields encrypted by the client, encrypt them again using its own key, and then return them to the client. The client then uses its own key to decrypt the double-encrypted sensitive fields to obtain the server-encrypted sensitive fields.

[0109] For example, case 1: The server can receive (H(25)) sent by the client. β .

[0110] The server can re-encrypt the encrypted sensitive fields (i.e., privacy fields) and return the re-encrypted sensitive fields to the client. Specifically, the server can re-encrypt the privacy fields (H(25)). β Encrypt again using your own RSA private key α to obtain ((H(25)) β ) α .

[0111] For example, case 1': The server can receive the privacy search statement sent by the client: select Name whereAge=(H(25)) β In this way, the server can obtain the privacy field (H(25)) from the privacy retrieval statement. β .

[0112] The server can re-encrypt the privacy field and return the re-encrypted privacy field to the client.

[0113] Specifically, the server can handle privacy fields (H(25)). β Encrypt again using your own RSA private key α to obtain ((H(25)) β ) α The specific process is similar to that described above, and will not be repeated here.

[0114] For example, case 2: The server can receive β·H(25) sent by the client.

[0115] The server can encrypt the privacy field again and return the re-encrypted privacy field to the client. Specifically, the server can encrypt the privacy field β·H(25) again using its own ECC private key α to obtain α·β·H(25).

[0116] For example, in case 2': the server can receive the privacy search statement "select Name whereAge=β·H(25)" sent by the client. In this way, the server can obtain the privacy field β·H(25) in the privacy search statement.

[0117] The server can re-encrypt the privacy field and return the re-encrypted privacy field to the client.

[0118] Specifically, the server can re-encrypt the privacy field β·H(25) using its own ECC private key α to obtain α·β·H(25). The specific process is similar to the above, and will not be repeated here.

[0119] The server re-encrypts the sensitive field (i.e., the privacy field) that was encrypted by the client using its own key and sends it to the client. The client can then decrypt the double-encrypted privacy field using its own key to obtain the sensitive field encrypted by the server.

[0120] For example, corresponding to cases 1 and 1' above, the client receives ((H(25)) sent by the server. β ) α The power operation has the following property: ((H(25)) β ) α =(H(25)) βα =(H(25)) αβ =((H(25)) α ) β Furthermore, the client can use the inverse of its own private key β. Decrypting the sensitive fields after double encryption is as follows: In this way, the client obtains the same sensitive field encrypted by the server, namely (H(25)). α .

[0121] Corresponding to cases 2 and 2' above, the client receives α·β·H(25) sent by the server, where the scalar multiplication operation has the following property: α·β2H(25)=β·α·H(25). Furthermore, the client can use the inverse of its own private key β, βinverse. -1 Decrypting the sensitive field after double encryption is as follows: β -1 ·α·β·H(25)=β -1 ·β·α·H(25)=α·H(25). In this way, the client also obtains the same sensitive field encrypted by the server, namely α·H(25).

[0122] It should be noted that in RSA, according to Euler's theorem, pk·sk = 1 mod (p-1)·(q-1), where p and q are two large prime numbers, so pk and sk are inverses of each other. Similarly, in ECC, pk = sk*G, where G is a generator on the ECC selected curve, so pk and sk are also inverses of each other.

[0123] S120: The client retrieves the identifier of the matching record from the query base based on the sensitive field encrypted by the server, and returns the identifier to the server.

[0124] After S110 is executed, the client can obtain the same sensitive field encrypted by the server.

[0125] The client can query the query base based on this sensitive field encrypted by the server. For example, after decryption, the client obtains the private field α·H(25) or (H(25)) encrypted by the server. α Therefore, the client can use this privacy field to query the query base, for example, querying Table 2 or Table 3 respectively, and can obtain the record with ID=d_1 containing this privacy field in Age, where ID is the identifier of this record. In this way, the client can locate the identifier of the matching record after querying the query base based on this privacy field encrypted by the server.

[0126] The client returns the identifier of the matched record to the server, which can include two scenarios.

[0127] One scenario is in S110, where the client constructs a search statement, encrypts sensitive fields within the search statement to obtain private fields, replaces the sensitive fields with the private fields, and sends the replaced private search statement to the server. In this case, the client can directly return the identifier of the matching record to the server.

[0128] Another scenario is in S110, where the client sends the value of a sensitive field, encrypted by itself, to the server. In this case, in S120, the client can construct a search statement, for example, the search statement is:

[0129] select Name where ID = id_1

[0130] Thus, in S120, the client can send the constructed search query to the server. This search query contains the identifier of the matching record and indicates that the field of interest is Name, which is the field name immediately following select.

[0131] In other words, in steps S110 and S120, you can choose to send a search query that includes the field of interest in one of the steps.

[0132] S130: The server returns the value of the field of interest in the record corresponding to the identifier in the database to the client.

[0133] Following the example above, after receiving the identifier from the client, the server can search for the record corresponding to the identifier in the database, retrieve the corresponding value from the found record according to the field of interest in S110 or S120, and return the retrieved value of the field of interest to the client. For example, returning Name=B from the record corresponding to id_1 means returning B to the client.

[0134] In the above embodiments, by pre-configuring the query base on the client, the client can locate the identifier of the field to be queried in the query base through interaction with the server and the query base without exposing the plaintext of the database. Then, based on the identifier, the client initiates a query to the server to obtain the value of the field of interest in the record corresponding to the identifier. Compared to traditional multi-replica PIR, this obviously eliminates the assumption that multiple replica databases cannot collude, making it more practical. Compared to the traditional single-replica PIR, which only allows bit-level retrieval, this embodiment does not require attention to the specific location (bit position) of the keyword to be retrieved in the database, enabling string queries and supporting Structured Query Language (SQL). In this embodiment, the database remains on the server, while the encrypted query base is configured on the client. This allows the client to locate data based on the query base to obtain the record identifier during retrieval. Furthermore, the encryption of the query base ensures that the client does not obtain the database content, guaranteeing the server's privacy protection of the database. Overall, the database and query base configurations in this embodiment can be referred to as "asymmetric dual replicas" when the database is configured on one server and the query base is configured on one client, and as "asymmetric multiple replicas" when the query base is configured on multiple clients.

[0135] In the above embodiments, the client can initiate a query for fields of interest using SQL query statements, such as the Name field to be queried in the `select Name...` statement. This exposes the client's fields of interest to some extent. Alternatively, the client can query records that meet certain conditions, i.e., the entire row of data that meets the conditions. This protects the client's privacy, but requires the server to return the entire record, which exposes the server's entire row of data to some extent. For example, in S110 / S120, a retrieval statement like "select *where Age=?" or "select *where ID=id_1" can be used. In this case, the server can return the record for id_1, as shown below:

[0136] id_1B 25shanghai

[0137] In addition, to ensure the security of the transmission process, the server can encrypt and return the value of the record corresponding to the identifier / the field of interest in the corresponding record in the database to the client. For example, the server can use a symmetric key negotiated with the client to encrypt the value of the record corresponding to the identifier / the field of interest in the corresponding record in the database before returning it to the client, or it can use the public key from the client's asymmetric key to encrypt the value of the record corresponding to the identifier / the field of interest in the corresponding record in the database before returning it to the client. Thus, the client can decrypt it using its own private key, or a digital envelope method can be used, etc.

[0138] In S120 above, the client directly returns the matched ID to the server. Although the server can obtain the record corresponding to the ID or the field of interest in the record, as in S130, this exposes the client's privacy to some extent, as it lets the server know that the identifier the client wants to query is id_1. To protect the client's privacy, it can be achieved in the following embodiment:

[0139] S210: The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server.

[0140] For example, a client's search condition might be that the Age field value is 25, and 25 is a sensitive field that the client doesn't want the other end to know. To prevent the server from knowing that the client's search condition is the Age field value 25, the client can encrypt this 25. For example, it can use RSA / ECC private key encryption, and the encryption algorithm used by the client is the same as the encryption algorithm used by the server to generate the query base.

[0141] Specifically, when using RSA private key encryption, the client generates and securely stores its own secret β. Then, the client can encrypt 25 using its own private key β. Specifically, this can be done by encrypting 25 or its hash value. Here, we will use hash encryption of 25 as an example. The case of direct encryption of 25 is similar; the client and server use the same hash algorithm. For example, the client uses the same large prime number q as the modulus as the server. The client can use β to perform RSA encryption on the hash value of 25, obtaining (H(25)). β Therefore, the sensitive field sent by the client to the server can be (H(25)). β Among them, (H(25)) β This represents the ciphertext of the sensitive field's value 25.

[0142] When using ECC private key encryption, the client uses the same elliptic curve as the server, meaning it has the same elliptic curve parameters and generators. The client generates its own secret β and stores it securely. Then, the client can encrypt 25 using its own private key β. Specifically, it can encrypt the hash value of 25, using the same hash algorithm as the server. For example, the client can use β to perform ECC encryption on the hash value of 25, obtaining β·H(25). The sensitive field sent by the client to the server can then be β·H(25), where β·H(25) represents the ciphertext of the sensitive field value 25.

[0143] The client obtains the same sensitive field encrypted by the server through interaction with the server. This can include the server re-encrypting the sensitive field encrypted by the client using its own key and sending it to the client, and the client decrypting the double-encrypted sensitive field using its own key to obtain the sensitive field encrypted by the server. The core of this concept is finding an encryption algorithm that allows for decryption in interchangeable orders after two consecutive encryption operations (encryption by both parties sequentially). Based on the cryptographic properties of ECC, both parties agree to use the same elliptic curve, meaning they have the same elliptic curve parameters and generators, and each holds private keys α and β. The encryption operation involves scalar multiplication using α (or β). Regardless of whether α is used first followed by β or vice versa, the encryption result can be decrypted in the same or different orders. Similarly, based on the cryptographic properties of RSA, both parties agree to use the same large prime number q and primitive root g, each holding a private key α and β. The encryption operation involves exponentiation of α (or β) and modulo of q. Regardless of whether α is used first and then β, or vice versa, the encryption result can be decrypted in the same or different orders. In short, the client and server use interchangeable encryption / decryption algorithms for the same target.

[0144] Specifically, after receiving sensitive fields encrypted by the client, the server may encrypt these fields again using its own key and return them to the client. The client then uses its own key to decrypt the double-encrypted sensitive fields to obtain the server-encrypted sensitive fields.

[0145] For example, case 1: The server can receive (H(25)) sent by the client. β .

[0146] The server can re-encrypt the encrypted sensitive fields (i.e., privacy fields) and return the re-encrypted sensitive fields to the client. Specifically, the server can re-encrypt the privacy fields (H(25)). βEncrypt again using your own RSA private key α to obtain ((H(25)) β ) α .

[0147] For example, case 2: The server can receive β·H(25) sent by the client.

[0148] The server can encrypt the privacy field again and return the re-encrypted privacy field to the client. Specifically, the server can encrypt the privacy field β·H(25) again using its own ECC private key α to obtain α·β·H(25).

[0149] The server re-encrypts the sensitive field (i.e., the privacy field) that was encrypted by the client using its own key and sends it to the client. The client can then decrypt the double-encrypted privacy field using its own key to obtain the sensitive field encrypted by the server.

[0150] For example, corresponding to case 1 above, the client receives ((H(25)) sent by the server. β ) α The power operation has the following property: ((H(25)) β ) α =(H(25)) βα =(H(25)) αβ =((H(25)) α ) β Furthermore, the client can use the inverse of its own private key β. Decrypting the sensitive fields after double encryption is as follows: In this way, the client obtains the same sensitive field encrypted by the server, namely (H(25)). α .

[0151] Corresponding to scenario 2 above, the client receives α·β·H(25) sent by the server, where the scalar multiplication operation has the following property: α·β·H(25)=β·α·H(25). Furthermore, the client can use the inverse of its own private key β, βin. -1 Decrypting the sensitive field after double encryption is as follows: β -1 ·α·β·H(25)=β -1 ·β·α·H(25)=α·H(24). In this way, the client also obtains the same sensitive field encrypted by the server, namely α·H(25).

[0152] It should be noted that in RSA, according to Euler's theorem, pk·sk = 1 mod (p-1)·(q-1), where p and q are two large prime numbers, so pk and sk are inverses of each other. Similarly, in ECC, pk = sk·G, where G is a generator on the ECC selected curve, so pk and sk are also inverses of each other.

[0153] S220: The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server.

[0154] After S210 is executed, the client can obtain the same sensitive field encrypted by the server.

[0155] The client can query the query base based on this sensitive field encrypted by the server. For example, after decryption, the client obtains the private field α·H(25) or (H(25)) encrypted by the server. α Therefore, the client can use this privacy field to query the query base, for example, querying Table 2 or Table 3 respectively, and can obtain the record with ID=d_1 containing this privacy field in Age, where ID is the identifier of this record. In this way, the client can locate the identifier of the matching record after querying the query base based on this privacy field encrypted by the server.

[0156] S230: The server returns the value of the field of interest in the corresponding record of the predetermined size set of identifiers, including the matching identifier, in the database to the client using an unintentional transmission method.

[0157] In S220, the client does not return the matched ID to the server, so the server cannot know which record(s) the client is looking for. In S210, the client sends sensitive fields that are encrypted by the client, so the server also cannot know which record(s) the client's search will match; only the client knows. This protects the client's privacy. However, the search still needs to be completed, which requires the server to return the record(s) the client wants to query.

[0158] Here, the server can use an unintentional transmission method.

[0159] Oblivious Transfer (OT) can be implemented based on RSA, ECC, etc., and can realize various OTs such as 1-out-of-2, 1-out-of-n, 1-out-of-m, and k-out-of-m (k<m<n). The principle is illustrated by taking 1-out-of-2 OT as an example: a sender has two secrets, m₁ and m₂ respectively, and needs to send the two secrets to a receiver; the receiver can only select and decrypt one of them without obtaining the other, and meanwhile the sender also cannot know which one the receiver has selected. Taking RSA as an example, a simple implementation process of 1-out-of-2 OT is as follows:

[0160] First, the sender generates two different pairs of public and private keys, and discloses the two public keys, which are recorded as public key 1 and public key 2 respectively. Suppose the receiver wants to obtain m₁, but does not want the sender to know that he wants m₁. The receiver generates a random number r, encrypts r with public key 1, and transmits the encrypted r to the sender. The sender decrypts the encrypted r with its own two private keys, obtains r₁ by decryption with private key 1, and obtains r₂ by decryption with private key 2. Obviously, only r₁ is equal to r, and r₂ is a string of meaningless numbers (which is also a decryption result). However, the sender does not know which public key the receiver used for encryption, so the sender also cannot know which of r₁ and r₂ calculated by the sender is the real r. After that, the sender performs symmetric encryption on m₁ with r₁, performs symmetric encryption on m₂ with r₂, and transmits the two symmetric encryption results to the receiver. The receiver locally has r = r₁, so the receiver can obtain m₁ by performing symmetric decryption on the two transmitted results respectively with r, but cannot obtain m₂ by decryption. This is because r possessed by the receiver is not equal to r₂, and the receiver thus cannot use the correct symmetric key to decrypt and obtain the value of m₂. In this process, the sender also does not know whether the receiver obtained m₁ or m₂.

[0161] With 1-out-of-2 OT as the foundation, two public-private key pairs can be extended into n public-private key pairs to form 1-out-of-n OT. The core of 1-out-of-n OT lies in that: a server encrypts n records in the data table / values of interest fields corresponding to the records with n different keys respectively to obtain n encryption results, and transmits the n encryption results to a client; the client decrypts one encryption result corresponding to a matching identifier among the n encryption results transmitted by the server by using the key corresponding to the matching identifier.

[0162] With reference to the foregoing embodiments of this specification, assume that there are a total of n records in the data table of the server, and accordingly there are also n encrypted records in the query base of the client. For convenience, the IDs of the data records are sequentially identified as id_0, id_1, id_2, ... id_n-1. A simple implementation process is as follows:

[0163] S231: the server pre-generates n different public-private key pairs and discloses the public keys.

[0164] Here, n equals the number of records in the database.

[0165] The server generates n distinct public-private key pairs (pk-sk; pk is the public key, sk is the secret key; the public key can be made public, but the private key must be kept secret), for example, pk0-sk0, pk1-sk1, pk2-sk2, ..., pk n-1 -sk n-1 And publish these n public keys, that is, publish pk0, pk1, pk2, ..., pk n-1 After the server publishes these n ordered public keys, the client can obtain these n public keys.

[0166] S232: The client generates a random number r, encrypts r with the public key corresponding to the desired ID, and sends it to the server.

[0167] Here, we assume the client wants to obtain the record with ID_1, but doesn't want the server to know that the client wants the record with ID_1. In this case, the client can encrypt r using pk1 and send it to the server. The "order" mentioned above mainly refers to the correspondence between IDs and public keys, and this correspondence can be known to the client. For example, in the above example, the client wants to obtain the record with ID_1 but doesn't want the server to know that the client wants the record with ID_1; the client can encrypt r using pk1 corresponding to ID_1 and send it to the server. Similarly, the client wants to obtain the record with ID_t but doesn't want the server to know that the client wants the record with ID_t; the client can encrypt r using pk1 corresponding to ID_t. t After encrypting r, it is sent to the server.

[0168] In addition, the client can encrypt r using pk1 and send it along with a search statement containing the obfuscation set, for example:

[0169] select Name where ID=id_t|Enc(r,pk1)

[0170] The "|" symbol is used to separate the preceding search statement from the following encrypted random number. Alternatively, the client can use pk1 to encrypt 'r' and send it to the server along with the field of interest.

[0171] S233: After receiving the encrypted r, the server decrypts it using n private keys respectively.

[0172] The server uses sk0, sk1, sk2, ..., sk respectively.n-1 Decrypt the random number r encrypted with pk1. For example, the server decrypts r0 using sk0, r1 using sk1, ..., and so on. n-1 Decryption yields r(n-1).

[0173] Clearly, only r1 is equal to r, because only those decrypted using sk1 are encrypted using the corresponding pk1; while those decrypted using sk0, sk2, ..., sk1, which do not correspond to pk1, are not. n-1 The decryption results r0, r2, ..., r(n-1) will not be the same as r. Through decryption, the server only obtains decryption results with the same form, but does not know what the real r is, nor does it know which public key the client used for encryption. In other words, the server does not know which public key the client used to encrypt r, and therefore the server does not know which of the n decryption results r0, r1, r2, ..., r(n-1) is the real r.

[0174] S234: The server performs symmetric encryption on each record in the database according to its sequence number using the decryption result corresponding to that sequence number, and sends the symmetrically encrypted result to the client.

[0175] For example, the server performs symmetric encryption on the record id_0 using r0, on the record id_1 using r1, ..., on the record id_n-1 using r(n-1), and sends these n symmetric encryption results to the client.

[0176] S235: The client uses the random number r to perform symmetric decryption on the encrypted result corresponding to the ID expected to be obtained in the symmetric encryption result, and obtains the retrieval result.

[0177] The client uses the random number r to symmetrically decrypt the encrypted result corresponding to the ID it expects to obtain from the symmetric encryption result. Specifically, for example, in S232 above, if the client expects to obtain the record / value of the field of interest in the record corresponding to id_1, then the client uses the corresponding public key pk1 to encrypt the random number r; in S233, the server uses the corresponding private key sk1 to decrypt the decryption result, obtaining r1 = r, and uses sk0, sk2, ..., sk1, which do not correspond to pk1. n-1The decryption results r0, r2, ..., r(n-1) will not be the same as r. In S234, the server uses r0, r1, r2, ..., r(n-1) to perform symmetric encryption on the values ​​of the fields of interest in the corresponding records id_0, id_1, ..., id_n-1 respectively, and sends these n symmetric encryption results to the client. In S235, the client uses the random number r to perform symmetric decryption on the n symmetric encryption results. Among the n symmetric decryption results, only the encryption result of id_1 is symmetrically encrypted using r. Therefore, only by decrypting the encryption result of id_1 using r can the correct value be obtained. Thus, the client can obtain the correct search result, that is, obtain the corresponding record / the value of the field of interest in the corresponding record.

[0178] Of course, to reduce the amount of computation, the client can use only the random number r to perform symmetric decryption on the encryption result corresponding to the ID expected to be obtained from the n symmetric encryption results. That is, the client only uses r to decrypt the encryption result of id_1, thereby obtaining the corresponding record of id_1 / the value of the field of interest in the corresponding record, without having to use r to perform symmetric decryption on the symmetric encryption results of id_0, id_2, ..., id_n-1, because the client can know that these encryption results are not symmetric encryptions performed using r, and even if r is used for symmetric decryption, the correct result cannot be obtained.

[0179] To illustrate this more clearly, the client's use of the random number r to perform symmetric decryption on the n symmetric encryption results is explained as follows:

[0180] In S234, the server uses r0, r1, r2, ..., r(n-1) to perform symmetric encryption on the values ​​of the fields of interest in the corresponding records id_0, id_1, ..., id_n-1 respectively. For example, symmetric encryption is performed on the corresponding records id_0, id_1, ..., id_n-1:

[0181] Enc(id_0, r0), where r0 ≠ r;

[0182] Enc(id_1, r1), where r1 = r;

[0183] Enc(id_2, r2), where r2 ≠ r; ...

[0185] Enc(id_n-1, r(n-1)), where r(n-1) ≠ r;

[0186] The above Enc stands for Encrypt. The first part of Enc(), id_0, id_1, id_2, ..., id_n-1, represents the value of the field of interest in n records / n records, and the second part, r0, r1, r2, ..., r(n-1), represents the encryption key.

[0187] In S235, the client uses a random number r to perform symmetric decryption on the encryption result in S234. Specifically, the client uses the random number r to perform symmetric decryption on the following contents respectively:

[0188] Dec(Enc(id_0, r0), r), where r0 ≠ r;

[0189] Dec(Enc(id_1, r1), r), where r1 = r;

[0190] Dec(Enc(id_2, r2), r), where r2 ≠ r; ...

[0192] Dec(Enc(id_n-1, r(n-1), r), where r(n-1) ≠ r;

[0193] The above Dec means decryption. The first part of Dec() represents the object to be decrypted, which is the encryption result above. The second part of Dec() represents the key used for decryption.

[0194] As can be seen, the client can only decrypt the record with ID_1, but cannot deduce the other records. This is because the server only used a random number r for symmetric encryption on the record with ID_1, while it used a non-random number r for symmetric encryption on the other IDs. Therefore, the client cannot obtain r0, r2, ..., r(n-1) other than r1=r.

[0195] It should be noted that S231 can be after S230 or before S230; there is no restriction here.

[0196] The above describes how, when the client retrieves 1 matching record from the query base, it inadvertently transmits the values ​​of all records corresponding to the matching identifier, including the matching identifier, or the values ​​of the fields of interest in the corresponding records to the client through an n-choose-1 method.

[0197] In the above embodiments, the server does not know which ID(s) the client is querying, but instead encrypts all records in the database and returns them to the client, protecting the client's privacy. However, in S233, the server uses n private keys to decrypt the received encrypted r, performing a large number of asymmetric decryption calculations, which consumes a significant amount of CPU and memory resources. Furthermore, transmitting n symmetrically encrypted results in S234 will also consume a large amount of bandwidth. Especially when n is large, the server's computational load and bandwidth consumption are substantial.

[0198] Furthermore, the number of matching results might be greater than 1, for example, k records (k>1). This can be achieved through unintentional transmission of n-select-k records. Regarding n-select-k, one implementation is to group every k records from the n records into a set, with each set corresponding to a public-private key pair. This will result in a total of... (C represents the combination formula, the number of combinations formed by randomly selecting k elements from n). Next, we will use... Option 1, the unintentional transmission method, transmits the values ​​of all records corresponding to the matching identifier, or the fields of interest in the corresponding records, to the client. The unintentional transmission method of selecting option 1 is implemented in a similar process to the unintentional transmission method of selecting option n described above. That is, the server uses... Each of the k records in the data table is encrypted with a different key, and the value of the field of interest in each corresponding record is obtained. The encrypted result is sent. The server sends an encrypted result to the client; the client then uses the key corresponding to the matching identifier to decrypt the result sent by the server. One encrypted result is matched with the identifier in each encrypted result. The specific implementation is similar to the process described in S231-S235 above, and will not be repeated here.

[0199] It should be noted that 'r' mentioned above can also be the public key in an asymmetric key. In this case, after receiving the result encrypted by 'r', the client can decrypt it using its own private key to obtain the result. That is, in S234 and S235, the server performs asymmetric encryption on the record 'id_0' using 'r0', on the record 'id_1' using 'r1', ..., on the record 'id_n-1' using 'r(n-1)', and sends these n encryption results to the client. After receiving these encryption results, the client can use its own private key to asymmetricly decrypt the encryption result corresponding to the desired ID to obtain the result. The following steps are similar and will not be repeated.

[0200] Based on this, this specification provides the following implementation method that adds the construction of the confusion set:

[0201] S310: The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server.

[0202] For example, a client's search condition might be that the Age field value is 25, and 25 is a sensitive field that the client doesn't want the other end to know. To prevent the server from knowing that the client's search condition is the Age field value 25, the client can encrypt this 25. For example, it can use RSA / ECC private key encryption, and the encryption algorithm used by the client is the same as the encryption algorithm used by the server to generate the query base.

[0203] Specifically, when using RSA private key encryption, the client generates and securely stores its own secret β. Then, the client can encrypt 25 using its own private key β. Specifically, this can be done by encrypting 25 or its hash value. Here, we will use hash encryption of 25 as an example. The case of direct encryption of 25 is similar; the client and server use the same hash algorithm. For example, the client uses the same large prime number q as the modulus as the server. The client can use β to perform RSA encryption on the hash value of 25, obtaining (H(25)). β Therefore, the sensitive field sent by the client to the server can be (H(25)). β Among them, (H(25)) β This represents the ciphertext of the sensitive field's value 25.

[0204] When using ECC private key encryption, the client uses the same elliptic curve as the server, meaning it has the same elliptic curve parameters and generators. The client generates its own secret β and stores it securely. Then, the client can encrypt 25 using its own private key β. Specifically, it can encrypt the hash value of 25, using the same hash algorithm as the server. For example, the client can use β to perform ECC encryption on the hash value of 25, obtaining β·H(25). The sensitive field sent by the client to the server can then be β·H(25), where β·H(25) represents the ciphertext of the sensitive field value 25.

[0205] The client obtains the same sensitive field encrypted by the server through interaction with the server. This can include the server re-encrypting the sensitive field encrypted by the client using its own key and sending it to the client, and the client decrypting the double-encrypted sensitive field using its own key to obtain the sensitive field encrypted by the server. The core of this concept is finding an encryption algorithm that allows for decryption in interchangeable orders after two consecutive encryption operations (encryption by both parties sequentially). Based on the cryptographic properties of ECC, both parties agree to use the same elliptic curve, meaning they have the same elliptic curve parameters and generators, and each holds private keys α and β. The encryption operation involves scalar multiplication using α (or β). Regardless of whether α is used first followed by β or vice versa, the encryption result can be decrypted in the same or different orders. Similarly, based on the cryptographic properties of RSA, both parties agree to use the same large prime number q and primitive root g, each holding a private key α and β. The encryption operation involves exponentiation of α (or β) and modulo of q. Regardless of whether α is used first and then β, or vice versa, the encryption result can be decrypted in the same or different orders. In short, the client and server use interchangeable encryption / decryption algorithms for the same target.

[0206] Specifically, after receiving sensitive fields encrypted by the client, the server may encrypt these fields again using its own key and return them to the client. The client then uses its own key to decrypt the double-encrypted sensitive fields to obtain the server-encrypted sensitive fields.

[0207] For example, case 1: The server can receive (H(25)) sent by the client. β .

[0208] The server can re-encrypt the encrypted sensitive fields (i.e., privacy fields) and return the re-encrypted sensitive fields to the client. Specifically, the server can re-encrypt the privacy fields (H(25)). β Encrypt again using your own RSA private key α to obtain ((H(25)) β ) α .

[0209] For example, case 2: The server can receive β·H(25) sent by the client.

[0210] The server can encrypt the privacy field again and return the re-encrypted privacy field to the client. Specifically, the server can encrypt the privacy field β·H(25) again using its own ECC private key α to obtain α·β·H(25).

[0211] The server re-encrypts the sensitive field (i.e., the privacy field) that was encrypted by the client using its own key and sends it to the client. The client can then decrypt the double-encrypted privacy field using its own key to obtain the sensitive field encrypted by the server.

[0212] For example, corresponding to case 1 above, the client receives ((H(25)) sent by the server. β ) α The power operation has the following property: ((H(25)) β ) α =(H(25)) βα =(H(25)) αβ =((H(25)) α ) β Furthermore, the client can use the inverse of its own private key β. Decrypting the sensitive fields after double encryption is as follows: In this way, the client obtains the same sensitive field encrypted by the server, namely (H(25)). α .

[0213] Corresponding to scenario 2 above, the client receives α·β·H(25) sent by the server, where the scalar multiplication operation has the following property: α·β·H(25)=β·α·H(25). Furthermore, the client can use the inverse of its own private key β, βin. -1 Decrypting the sensitive field after double encryption is as follows: β -1 ·α·β·H(25)=β -1 ·β·α·H(25)=α·H(25). In this way, the client also obtains the same sensitive field encrypted by the server, namely α·H(25).

[0214] It should be noted that in RSA, according to Euler's theorem, pk·sk = 1 mod (p-1)·(q-1), where p and q are two large prime numbers, so pk and sk are inverses of each other. Similarly, in ECC, pk = sk·G, where G is a generator on the ECC selected curve, so pk and sk are also inverses of each other.

[0215] S320: The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server.

[0216] After S310 is executed, the client can obtain the same sensitive field encrypted by the server.

[0217] The client can query the query base based on this sensitive field encrypted by the server. For example, after decryption, the client obtains the private field α·H(25) or (H(25)) encrypted by the server.α , whereby the client queries in the query base based on the privacy field, for example, querying in Table 2 or Table 3 respectively, the record with the privacy field included in Age that can be obtained is the record with ID=d_1, and the ID is the identifier of this record. In this way, the client queries in the query base based on the privacy field encrypted by the server, and can locate and obtain the identifier of the matching record after matching the record.

[0218] S330: The server returns the values of the interested fields in the records corresponding to the identifier set of a predetermined size including the matching identifier in the database to the client in an oblivious transfer manner.

[0219] In S310, the sensitive field encrypted by the client sent by the client makes the server unable to know which record the sensitive field searched by the client will hit, and only the client itself knows this. In this way, the privacy of the client is protected. However, the retrieval still needs to be completed eventually, which requires the server to return the record that the client wants to query to the client.

[0220] The foregoing Figure 2 The corresponding embodiment provides an implementation of 1-out-of-n oblivious transfer. Here, 1-out-of-m oblivious transfer can be adopted, where m<n. In S320, the client may not return the matched ID to the server separately, but mixes and combines the matched ID with some other forged IDs to construct a obfuscated set, and sends the obfuscated set to the server. In this way, the server cannot accurately know which record in the obfuscated set the client wants to search, and it is necessary to ensure that the client can only obtain the record to be searched therein, and cannot obtain other records. In S320, the obfuscated set sent by the client can be sent together with the retrieval statement, for example, select Name where ID=obfuscated set. Alternatively, the obfuscated set can also be sent in S330 below, which is not limited herein.

[0221] With reference to the foregoing embodiments of this specification, assuming that there are a total of n records in the data table of the server, accordingly, there are also n encrypted records in the query base of the client. For convenience, the IDs of data records are sequentially identified as id_0, id_1, id_2, ... id_n-1. A simple implementation process is as follows:

[0222] S331: The server pre-generates n different public-private key pairs and discloses the public keys.

[0223] The server generates n different public-private key pairs (pk-sk; pk is public key, representing the public key; sk is secret key, representing the private key), for example, they are pk0-sk0, pk1-sk1, pk2-sk2, ..., pk n-1 -skn-1 And publish these n public keys, that is, publish pk0, pk1, pk2, ..., pk n-1 After the server publishes these n ordered public keys, the client can obtain these n public keys.

[0224] S332: The client generates a confusion set of size m containing the ID to be obtained, generates a random number r, encrypts r with the public key corresponding to the ID to be obtained, and sends it to the server along with the confusion set.

[0225] Here, we assume that the client wants to obtain the record with ID_1, but does not want the server to know that the client wants to obtain the record with ID_1. Therefore, a confusion set of size m is generated. When m=4, this confusion set is, for example, {id_1,id_2,id_3,id_4}.

[0226] These four IDs and public key pairs have the following correspondence:

[0227] pk1, id_1

[0228] pk2, id_2

[0229] pk3, id_3

[0230] pk4, id_4

[0231] The client can encrypt r using pk1 and send it to the server along with the obfuscation set.

[0232] Furthermore, the client can send the obfuscation set along with the search query to the server. In this way, the client can encrypt `r` using `pk1` and send it along with the search query containing the obfuscation set, for example:

[0233] select Name where ID={id_1,id_2,id_3,id_4}|Enc(r,pk1)

[0234] The "|" symbol is used to separate the preceding search statement from the following encrypted random number.

[0235] S333: After receiving the obfuscation set and the encrypted r, the server decrypts the encrypted r using the corresponding m private keys.

[0236] The server uses sk1, sk2, sk3, and sk4 respectively to decrypt the random number r encrypted by pk1. For example, the server decrypts r1 with sk1, r2 with sk2, r3 with sk3, and r4 with sk4.

[0237] Clearly, only r1 is equal to r, because only decryption using sk1 corresponds to encryption using the corresponding pk1; decryption using sk2, sk3, and sk4 (which do not correspond to pk1) will result in r2, r3, and r4, which will all be different from r. Through decryption, the server only obtains a decryption result with the same form, but does not know what the real r is, nor which public key the client used for encryption. In other words, the server does not know which public key the client used to encrypt r, and therefore, the server does not know which of the four decryption results r1, r2, r3, and r4 is the real r.

[0238] In addition, after the server receives the obfuscation set {id_1,id_2,id_3,id_4}, it can know from the obfuscation set that the data the client wants to obtain is one of the four IDs in the obfuscation set, but it is not sure which one it is, thus protecting the client's privacy.

[0239] S334: The server performs symmetric encryption on the records specified in the obfuscation set using the decryption result of the corresponding sequence number, and sends the symmetrically encrypted result to the client.

[0240] For example, the server performs symmetric encryption on record id_1 using r1, record id_2 using r2, record id_3 using r3, and record id_4 using r4, and sends these four symmetric encryption results to the client.

[0241] S335: The client uses the random number r to perform symmetric decryption on the encrypted result corresponding to the ID expected to be obtained in the symmetric encryption result, and obtains the retrieval result.

[0242] The client uses the random number r to symmetrically decrypt the encrypted result corresponding to the ID it expects to obtain from the symmetric encryption result. Specifically, for example, in S332 above, if the client expects to obtain the value of the field of interest in the record / record corresponding to id_1, the client uses the corresponding public key pk1 to encrypt the random number r; in S333, the server uses the corresponding private key sk1 to decrypt the decryption result, obtaining r1 = r, while the results r2, r3, and r4 obtained by decrypting with sk2, sk3, and sk4 which do not correspond to pk1 will not be the same as r; in S334, the server uses r1, r2, r3, and r4 to symmetrically encrypt the values ​​of the fields of interest in the corresponding records / records id_1, id_2, id_3, and id_4 respectively, and sends this symmetric encryption result to the client; in S335, the client uses the random number r to symmetrically decrypt the four symmetric encryption results. Of the four symmetric decryption results, only the encryption result of id_1 was symmetrically encrypted using r. Therefore, only by decrypting the encryption result of id_1 using r can the correct value be obtained. Thus, the client can obtain the correct search results, that is, obtain the corresponding record / the value of the field of interest within the corresponding record.

[0243] Of course, to reduce the amount of computation, the client can use only the random number r to perform symmetric decryption on the encryption result corresponding to the ID expected to be obtained from the four symmetric encryption results. That is, the client only uses r to decrypt the encryption result of id_1, thereby obtaining the corresponding record of id_1 / the value of the field of interest in the corresponding record, without having to use r to perform symmetric decryption on the symmetric encryption results of id_2, id_3, and id_4, because the client can know that these encryption results were not symmetricly encrypted using r, and even if r is used for symmetric decryption, the correct result cannot be obtained.

[0244] The above steps S331 to S335 are merely an exemplary implementation. In another implementation, the construction and transmission of the oblivious set can be decoupled from the execution of the OT protocol, and the OT protocol is used to transmit the key. Specifically, on one hand, the client can send the oblivious set of size m to the server, and the client certainly knows which position in the oblivious set of size m corresponds to the identifier of the result that is truly intended to be obtained. On the other hand, the server can generate m symmetric keys, and through 1-out-of-m OT, the client can obtain the specified symmetric key, that is, the client obtains the symmetric key corresponding to the identifier of the result that is truly intended to be obtained. In this way, the server can encrypt the records corresponding to the m identifiers in the client's oblivious set with the corresponding symmetric keys and then send them to the client, so that the client decrypts the truly intended result with the correct symmetric key to obtain the result. Wherein, the server can generate m symmetric keys in advance, so that the key preparation work can be completed in batches before the OT interaction, without occupying the execution time of the OT protocol.

[0245] The above is the scenario where when the number of matching records retrieved by the client from the query base is 1, the server transmits the records corresponding to the m identifiers specified in the oblivious set / the values of the fields of interest in the corresponding records to the client through 1-out-of-m oblivious transfer. In addition, the number of matching results may be greater than 1, for example, k records (k>1), which can be implemented through k-out-of-m oblivious transfer. The core of k-out-of-m oblivious transfer is that the client constructs an oblivious set of size m and sends it to the server, where 1<m<n, and one subset among the m oblivious elements includes the identifiers of the k matched records. For example, when m=4, k=2, and the matching identifiers are id_1 and id_3, the constructed oblivious set is, for example, {{id_1, id_3}, {id_2 and id_4}, {id_3 and id_4}, {id_2}}, and obviously the first one is the subset composed of matching identifiers; further, the server generates m symmetric keys, and enables the client to obtain the specified symmetric key through the 1-out-of-m OT protocol; the server encrypts the m subsets in the oblivious set respectively with m different symmetric keys to obtain m encrypted result subsets, and sends the m encrypted result subsets to the client; the client decrypts the subset composed of the matching identifiers with the obtained symmetric key, thereby obtaining the correct decrypted result. The specific implementation is similar to the above process of decoupling the construction and transmission of the oblivious set from the execution of the OT protocol and using the OT protocol to transmit the key, and will not be elaborated further.

[0246] The above Figure 1 In the corresponding implementation process, whether the fields of interest are sent in step S110 or step S120, the plaintext of the sent fields of interest will expose the fields of interest retrieved by the client, for example, Name in the above example. The above Figure 2In the corresponding implementation process, regardless of whether the field of interest is sent in S210, S232, S310, or S332, the plaintext of the sent field of interest will expose the field of interest retrieved by the client, such as "Name" in the example above. This will expose the client's privacy to some extent.

[0247] To further enhance the protection of client privacy, similarly, OT (Operational Technology) can be used to transmit fields of interest.

[0248] Specifically, for example Figure 3 The above includes:

[0249] S410: The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server.

[0250] S420: The client retrieves the identifier of the matching record from the query base based on the sensitive field encrypted by the server, and returns the identifier to the server.

[0251] S430: The server and the client transmit the value of the field of interest in the record corresponding to the matching identifier in the database to the client through an unintentional transmission method.

[0252] S410 and S420 are similar to S110 and S120 respectively, and will not be described in detail here.

[0253] In S420, the identifier of the matching record is returned to the server, allowing the server to determine the row containing the record the client is looking for. However, the client does not send fields of interest, such as Name, to the server; therefore, the server does not know which field in the record corresponding to the ID the client is seeking. S410 is similar; the client sends its own encrypted sensitive fields to the server but does not send fields of interest.

[0254] However, in S430, the server still needs to match the value of the field of interest in the corresponding record and transmit it to the client. This can be done by transmitting it unintentionally.

[0255] Assuming the server-side data table has n fields besides ID, in the example of Tables 1, 2, and 3, n=4, meaning it includes the fields Name, Age, Native_place, and Job_number. These four fields can be identified as field_1, field_2, field_3, and field_4. Then S430 can include the following process:

[0256] S431: The server pre-generates n different public-private key pairs and publishes the public key.

[0257] Here, n equals the number of fields in the database other than ID, such as the four fields mentioned above.

[0258] The server generates n distinct public-private key pairs (pk-sk; pk is the public key, sk is the secret key; the public key can be made public, but the private key must be kept secret), for example, pk1-sk1, pk2-sk2, ..., pk n -sk n And publish these n public keys, that is, publish pk1, pk2, ..., pk n After the server publishes these n ordered public keys, the client can obtain these n public keys.

[0259] S432: The client generates a random number r, encrypts r with the public key corresponding to the desired field, and sends it to the server.

[0260] Here, we assume the client wants to obtain the value of field_1, but doesn't want the server to know that the client wants the value of field_1. In this case, the client can encrypt r using pk1 and send it to the server. The "order" mentioned above mainly refers to the correspondence between fields and public keys, and this correspondence can be known to the client. For example, in the above example, the client wants to obtain the value of field_1 but doesn't want the server to know that the client wants the value of field_1; the client can encrypt r using pk1 corresponding to field_1 and send it to the server. Similarly, the client wants to obtain the value of field_t but doesn't want the server to know that the client wants the value of field_t; the client can encrypt r using pk1 corresponding to field_t. t After encrypting r, it is sent to the server.

[0261] S433: After receiving the encrypted r, the server decrypts it using n private keys respectively.

[0262] The server uses sk1, sk2, ..., sk respectively. n Decrypt the random number r encrypted with pk1. For example, the server decrypts r1 using sk1, ..., and then decrypts it using sk1. n Decryption yields rn.

[0263] Clearly, only r1 is equal to r, because only those decrypted using sk1 are encrypted using the corresponding pk1; while those decrypted using sk2, ..., sk1, which do not correspond to pk1, are not. nThe decryption results r2, ..., rn will not be the same as r. Through decryption, the server only obtains decryption results with the same form, but does not know what the real r is, nor does it know which public key the client used for encryption. In other words, the server does not know which public key the client used to encrypt r, and therefore the server does not know which of the n decryption results r1, r2, ..., rn is the real r.

[0264] S434: The server performs symmetric encryption on each field of the matched record in the database according to the sequence number and the corresponding decryption result, and sends the symmetrically encrypted result to the client.

[0265] For example, the server performs symmetric encryption on field_1 using r1, field_2 using r2, ..., and field_n using rn, and sends these n symmetric encryption results to the client.

[0266] S435: The client uses the random number r to perform symmetric decryption on the encryption result corresponding to the field to be obtained in the symmetric encryption result, and obtains the retrieval result.

[0267] The client uses the random number r to symmetrically decrypt the encrypted result corresponding to the desired field in the symmetric encryption result. Specifically, for example, in S432 above, if the client expects to obtain the value of field_1, the client uses the corresponding public key pk1 to encrypt the random number r; in S433, the server uses the corresponding private key sk1 to decrypt the result, obtaining r1 = r, and uses sk2, ..., sk which do not correspond to pk1 to decrypt the result. n The decrypted results r2, ..., rn will not be the same as r; in S434, the server uses r1, r2, ..., rn to perform symmetric encryption on the values ​​of the corresponding fields field_1, ..., field_n respectively, and sends these n symmetric encryption results to the client; in S435, the client uses the random number r to perform symmetric decryption on the n symmetric encryption results. Among the n symmetric decryption results, only the encryption result of field_1 was symmetrically encrypted using r, therefore, only by decrypting the encryption result of field_1 using r can the correct value be obtained. Thus, the client can obtain the correct search results, that is, obtain the values ​​of the fields of interest in the corresponding records.

[0268] Of course, to reduce the amount of computation, the client can use only the random number r to perform symmetric decryption on the encryption results corresponding to the fields to be obtained in the n symmetric encryption results. That is, the client only uses r to decrypt the encryption result of field_1 to obtain the value of the field of interest in the corresponding record of field_1, without having to use r to perform symmetric decryption on the symmetric encryption results of field_2, ..., field_n, because the client can know that these encryption results are not symmetric encryptions performed using r, and even if r is used for symmetric decryption, the correct result cannot be obtained.

[0269] It should be noted that S431 can be after S430 or before S430; there is no restriction here.

[0270] The above describes how, when the client retrieves a matching record with 1 field of interest from the query base, it inadvertently transmits the values ​​of the fields of interest from all records corresponding to the identifier, including the matching identifier, in the database to the client via an n-choose-1 method.

[0271] In the above embodiment, the server does not know which field the client is querying. Instead, it encrypts all fields of the matching records in the database and returns them to the client, protecting the client's privacy. However, in S433, the server uses n private keys to decrypt the received encrypted r, performing a large number of asymmetric decryption calculations, which consumes a significant amount of CPU and memory resources. Furthermore, transmitting n symmetrically encrypted results in S434 also consumes a large amount of bandwidth. Especially when n is large, the server's computational load and bandwidth consumption are substantial.

[0272] Furthermore, if the number of records matching a record has more than one field of interest, for example, k records (k>1), this can be achieved through unintentional transmission of n-select-k data. Regarding n-select-k, one implementation is to group every k fields from the n fields into a set, with each set corresponding to a public-private key pair. This will result in a total of... (C represents the combination formula, the number of combinations formed by randomly selecting k elements from n). Next, we will use... Option 1, the unintentional transmission method, transmits the values ​​of all fields in the database, including the field of interest, to the client. The unintentional transmission method of selecting option 1 is implemented in a similar process to the unintentional transmission method of selecting option n described above. That is, the server uses... Each of the k fields in the matching record is encrypted using a different key to obtain... The encrypted result is sent. The server sends an encrypted result to the client; the client then decrypts the data sent by the server using the key corresponding to the field of interest. a corresponding one of the n encryption results. The specific implementation is similar to the foregoing process of S431-S435, and is not repeated herein.

[0273] It should be noted that the foregoing r may also be a public key in an asymmetric key, so that after receiving a result encrypted with r, the client can decrypt it with its own private key to obtain the result. That is, in S434 and S435, the server asymmetrically encrypts the field field_1 with r1, asymmetrically encrypts the field field_2 with r2, ..., asymmetrically encrypts the field field_n with rn, and sends the n encryption results to the client. After receiving these encryption results, the client can asymmetrically decrypt the encryption result corresponding to the desired interested field with its own private key to obtain the result. The following is similar and will not be repeated.

[0274] In addition, this specification provides an implementation mode that adds a constructed field confusion set as follows:

[0275] S510: The client sends a self-encrypted sensitive field to the server, and obtains the same sensitive field encrypted by the server through interaction with the server.

[0276] S520: The client retrieves in a query base according to the sensitive field encrypted by the server, to obtain an identifier of a matching record.

[0277] S530: The server returns a value of an interested field in a record corresponding to the matching identifier in the database to the client in an oblivious transfer manner.

[0278] The foregoing Figure 3 corresponding embodiment provides an implementation of 1-out-of-n oblivious transfer. Here, 1-out-of-m oblivious transfer may be adopted, where m < n. In S520, the client may also perform confusion combination on the interested field with some other forged interested fields to construct a confusion set, and send the confusion set to the server, such that the server cannot accurately know which field in the confusion set the client wants to query, and it needs to be ensured that the client can only obtain the target interested field to be queried therein, and cannot obtain other fields. In S520, the confusion set sent by the client may be sent together with a retrieval statement, or the confusion set may also be sent in S532 below, which is not limited herein.

[0279] With reference to the foregoing embodiments of this specification, assuming that a total number of fields excluding IDs in a data table of the server is n, a simple implementation process is as follows:

[0280] S531: The server pre-generates n different public-private key pairs and discloses the public keys.

[0281] The server generates n distinct public-private key pairs (pk-sk; pk is the public key, sk is the private key), for example, pk1-sk1, pk2-sk2, ..., pk n -sk n And publish these n public keys, that is, publish pk1, pk2, ..., pk n After the server publishes these n ordered public keys, the client can obtain these n public keys.

[0282] S532: The client generates a confusion set of size m containing the fields of interest, generates a random number r, encrypts r with the public key corresponding to the expected fields of interest, and sends it to the server along with the confusion set.

[0283] Here, we assume that the client wants to obtain the field of field_1, but does not want the server to know that the client wants to obtain the record of field_1. Therefore, a confusion set of size m is generated. When m=4, this confusion set is, for example, {field_1,field_2,field_3,field_4}.

[0284] These four fields have the following correspondence with the public key pair, for example:

[0285] pk1, field_1

[0286] pk2, field_2

[0287] pk3, field_3

[0288] pk4, field_4

[0289] The client can encrypt r using pk1 and send it to the server along with the obfuscation set.

[0290] Furthermore, the client can send the obfuscation set along with the search query to the server. In this way, the client can encrypt `r` using `pk1` and send it along with the search query containing the obfuscation set, for example:

[0291] select{field_1,field_2,field_3,field_4}where ID=1|Enc(r,pk1)

[0292] The "|" symbol is used to separate the preceding search statement from the following encrypted random number.

[0293] S533: After receiving the obfuscation set and the encrypted r, the server decrypts the encrypted r using the corresponding m private keys.

[0294] The server uses sk1, sk2, sk3, and sk4 respectively to decrypt the random number r encrypted by pk1. For example, the server decrypts r1 with sk1, r2 with sk2, r3 with sk3, and r4 with sk4.

[0295] Clearly, only r1 is equal to r, because only decryption using sk1 corresponds to encryption using the corresponding pk1; decryption using sk2, sk3, and sk4 (which do not correspond to pk1) will result in r2, r3, and r4, which will all be different from r. Through decryption, the server only obtains a decryption result with the same form, but does not know what the real r is, nor which public key the client used for encryption. In other words, the server does not know which public key the client used to encrypt r, and therefore, the server does not know which of the four decryption results r1, r2, r3, and r4 is the real r.

[0296] In addition, after the server receives the obfuscation set {field_1, field_2, field_3, field_4}, it can know from the obfuscation set that the data the client wants to obtain is one of the four fields in the obfuscation set, but it is not sure which one it is, thus protecting the client's privacy.

[0297] S534: The server performs symmetric encryption on the fields specified in the obfuscation set using the decryption result of the corresponding sequence number, and sends the symmetrically encrypted result to the client.

[0298] For example, the server performs symmetric encryption on field_1 using r1, field_2 using r2, field_3 using r3, and field_4 using r4, and then sends these four symmetric encryption results to the client.

[0299] S535: The client uses the random number r to perform symmetric decryption on the encrypted result corresponding to the field of interest to be obtained in the symmetric encryption result, and obtains the retrieval result.

[0300] The client uses the random number r to symmetrically decrypt the encrypted result corresponding to the desired field of interest in the symmetric encryption result. Specifically, for example, in S532 above, if the client expects to obtain the value of the field corresponding to field_1, the client uses the corresponding public key pk1 to encrypt the random number r; in S533, the server uses the corresponding private key sk1 to decrypt the result, obtaining r1 = r, while the results r2, r3, and r4 obtained by decrypting with sk2, sk3, and sk4 which do not correspond to pk1 will not be the same as r; in S534, the server uses r1, r2, r3, and r4 to symmetrically encrypt the values ​​of the corresponding fields field_1, field_2, field_3, and field_4 respectively, and sends this symmetric encryption result to the client; in S535, the client uses the random number r to symmetrically decrypt the four symmetric encryption results. Among the four symmetric decryption results, only the encryption result of field_1 is symmetrically encrypted with r, so only by decrypting the encryption result of field_1 with r can the correct value be obtained. Thus, the client can obtain the correct search results, that is, obtain the value of the corresponding field of interest.

[0301] Of course, in order to reduce the amount of computation, the client can use only the random number r to perform symmetric decryption on the encryption results corresponding to the fields of interest that are expected to be obtained from the four symmetric encryption results. That is, the client only uses r to decrypt the encryption result of field_1 to obtain the value of the corresponding field of field_1, without having to use r to perform symmetric decryption on the symmetric encryption results of field_2, field_3, and field_4, because the client can know that these encryption results were not symmetricly encrypted using r, and even if r is used for symmetric decryption, the correct result cannot be obtained.

[0302] The above steps S531 to S535 are merely an exemplary implementation. In another implementation, the construction and transmission of the oblivious set can be decoupled from the execution of the OT protocol, and the OT protocol is used to transmit the key. Specifically, on one hand, the client can send the oblivious set of size m to the server, and the client knows which position in the oblivious set of size m is the really desired interesting field; on the other hand, the server can generate m symmetric keys, and through 1-out-of-m OT, the client can obtain the specified symmetric key, that is, the client obtains the symmetric key corresponding to the really desired interesting field of the result. In this way, the server can encrypt the m fields in the client's oblivious set with the corresponding symmetric keys and then send them to the client, so that the client can decrypt the really desired result with the correct symmetric key to obtain the result. Wherein, the server can pre-generate m symmetric keys, so that the key preparation can be completed in batches before the OT interaction, without occupying the execution time of the OT protocol.

[0303] The above is the case where when the number of interesting fields of the matching record retrieved by the client in the query base is 1, the server transmits the values of m interesting fields specified in the oblivious set to the client through 1-out-of-m oblivious transfer. In addition, the number of matching results may be greater than 1, for example, k records (k>1), which can be implemented through k-out-of-m oblivious transfer. The core of k-out-of-m oblivious transfer is that the client constructs an oblivious set of size m and sends it to the server, where 1<m<n, and 1 of the m oblivious sets contains the k matching fields. For example, when m=4, k=2, and the matching identifiers are field_1 and field_3, the constructed oblivious set is, for example, {{field_1, field_3}, {field_2 and field_4}, {field_3 and field_4}, {field_2}}, and obviously the first one is the subset formed by the interesting fields; further, the server generates m symmetric keys, and enables the client to obtain the specified symmetric key through the 1-out-of-m OT protocol; the server encrypts the m subsets in the oblivious set respectively with m different symmetric keys to obtain m encrypted result subsets, and sends the m encrypted result subsets to the client; the client decrypts the subset formed by the interesting fields with the obtained symmetric key, thereby obtaining the correct decryption result. The specific implementation is similar to the above process of decoupling the construction and transmission of the oblivious set from the execution of the OT protocol and using the OT protocol to transmit the key, and thus will not be elaborated further.

[0304] The processes of the above S210-S230 and S310-S330 respectively provide the oblivious transfer mode for matching IDs and the oblivious transfer mode combined with an oblivious set, and the process of the above S410-S430 provides an oblivious transfer mode for interesting fields. The two modes can be superimposed, for example, Figure 4 As shown, the process is as follows:

[0305] S610: The client sends a sensitive field encrypted by itself to the server, and obtains the same sensitive field encrypted by the server through interaction with the server.

[0306] S620: The client retrieves a matching identifier from the query base based on the sensitive fields encrypted by the server.

[0307] S630: The server uses a double unintentional transmission method to return the value of the field of interest in the corresponding record of the predetermined size identifier set, including the matching identifier, in the database to the client; the double unintentional transmission method is a combination of unintentional transmission of the predetermined size identifier set and unintentional transmission of the field of interest.

[0308] For example, if the predefined size identifier set is all identifiers, the number of matching identifiers is 1, and the number of fields of interest is also 1, then the first layer of unintentional transmission may include:

[0309] The server sends each public key from the generated row asymmetric key pairs to the client. For example, there are n rows (one record per row) and n asymmetric key pairs (called row asymmetric key pairs). The client uses each public key to encrypt a first random number generated by the client and returns the encrypted data to the server. A second layer of unintentional transmission can include: the server sending each public key from the generated column asymmetric key pairs to the client. For example, there are m columns (one field per column) and m asymmetric key pairs (called column asymmetric key pairs). The client uses each public key to encrypt a second random number generated by the client and returns the encrypted data to the server.

[0310] The server uses the private key in each row of the symmetric key pair to encrypt the first random number corresponding to the public key, and decrypts it to obtain a first decryption result equal to the number of rows, which corresponds to each row. Then, it uses the private key in each column of the asymmetric key pair to encrypt the second random number corresponding to the public key, and decrypts it to obtain a second decryption result equal to the number of columns, which corresponds to each column.

[0311] The server uses each first decryption result to symmetrically encrypt the value of the corresponding row in each column, and then uses each second decryption result to symmetrically encrypt the symmetrical encryption result in each row. The server then returns the result after both symmetrical encryptions to the client. Alternatively, the server uses each second decryption result to symmetrically encrypt the value of the corresponding column in each row, and then uses each first decryption result to symmetrically encrypt the symmetrical encryption result in each row. The server then returns the result after both symmetrical encryptions to the client.

[0312] The client uses the matching identifier's corresponding row symmetric key and the field of interest's corresponding symmetric key to symmetricly decrypt the corresponding row and column's two symmetric encryption results in sequence, thus obtaining the value. The order of the two symmetric decryptions corresponds to the order of the two symmetric encryptions.

[0313] The generation of the asymmetric key, using a random number as the symmetric key, and the processes of symmetric and asymmetric encryption can be found in the relevant embodiments described above, and will not be repeated here. It is evident that the above superposition process is equivalent to the superposition of two n-choose-1 OTs. Similarly, it can be the superposition of the aforementioned n-choose-k rows and n-choose-k columns.

[0314] Similarly, the m-select-1OT process of the confusion set n introduced in the row can be superimposed on the n-select-1OT process of the column, which will affect the pre-defined size representation set in S630, as described above. Here, m is the size of the confusion set of the row (n is the number of rows).

[0315] The processes S210–S230 and S310–S330 above respectively illustrate the unintentional transmission method for matching IDs and the unintentional transmission method combined with a confusion set. The processes S510–S530 above illustrate the unintentional transmission method for fields of interest using a confusion set. The two methods can also be combined. The unintentional transmission method using a confusion set for fields of interest can be one of the following: n-select-1 OT, n-select-k OT, or n-select-m k OT, where m is the size of the confusion set excluding the ID column (n is the number of columns excluding the ID). For example, for the following search statement:

[0316] select{field_1,field_2,field_3,field_4}where ID={{id_1,id_3},{id_2 and id_4},{id_3 and id_4},{id_2}}

[0317] In the former's obfuscation set {field_1, field_2, field_3, field_4}, the client is interested in field_1, for example. In the latter's obfuscation set {{id_1, id_3}, {id_2 and id_4}, {id_3 and id_4}, {id_2}}, the matching identifier actually corresponds to {id_1, id_3}. Therefore, obfuscation sets can be used, and the values ​​of field_1 for id_1 and id_3 can be transmitted via dual OT (Over-The-Air) communication. Simultaneously, the server cannot determine which ID in the latter obfuscation set the matching ID belongs to, nor can it determine which field in the former obfuscation set the client is interested in. The client, besides obtaining the values ​​of field_1 from the two records id_1 and id_3, will not receive any further information. The specific process can be obtained by referring to the above embodiments and combining them.

[0318] The following describes a system for retrieving privacy information according to one embodiment of this specification, including a server and a client. The client and server perform encryption / decryption on the same target using encryption / decryption algorithms with interchangeable order, and:

[0319] The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client.

[0320] During a search process:

[0321] The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server;

[0322] The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server;

[0323] The server and the client transmit the value of the field of interest in the record corresponding to the matching identifier in the database to the client through an unintentional transmission method.

[0324] The following describes a server-side implementation for privacy information retrieval in one embodiment of this specification. The server and client perform encryption / decryption on the same target using interchangeable encryption / decryption algorithms, and:

[0325] The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client.

[0326] During a search process:

[0327] The server receives sensitive fields sent by the client, which it has encrypted, and then encrypts them again before returning them to the client. The server also transmits the values ​​of the fields of interest in the records corresponding to the matching identifiers in the database to the client via unintentional transmission.

[0328] The following describes a client for retrieving privacy information according to one embodiment of this specification. This client and server perform encryption / decryption on the same target using interchangeable encryption / decryption algorithms, and:

[0329] The client is configured with a query base, which is obtained by the server after encrypting the database.

[0330] During a search process:

[0331] The client sends a sensitive field encrypted by itself to the server, and obtains the same sensitive field encrypted by the server through interaction with the server; the client also retrieves the identifier of the matching record in the query base based on the sensitive field encrypted by the server; the client also obtains the value of the field of interest in the record corresponding to the matching identifier in the database through unintentional transmission between the client and the server.

[0332] The following describes a system for retrieving privacy information according to one embodiment of this specification, including a server and a client. The client and server perform encryption / decryption on the same target using encryption / decryption algorithms with interchangeable order, and:

[0333] The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client.

[0334] During a search process:

[0335] The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server;

[0336] The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server, and generates a confusion set of size m containing the fields of interest.

[0337] The server and the client transmit the value of the field indicated by the obfuscation set of size m in the matching record in the database to the client through an unintentional transmission method.

[0338] The following describes a system for retrieving privacy information according to one embodiment of this specification, including a server and a client. The client and server perform encryption / decryption on the same target using encryption / decryption algorithms with interchangeable order, and:

[0339] The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client.

[0340] During a search process:

[0341] The client sends its own encrypted sensitive field to the server and obtains the same encrypted sensitive field from the server through interaction with the server.

[0342] The client retrieves a matching identifier from the query base based on the sensitive fields encrypted by the server.

[0343] The server uses a double unintentional transmission method to return the value of the field of interest in the corresponding record of the predetermined size identifier set, including the matching identifier, in the database to the client; the double unintentional transmission method is a combination of unintentional transmission of the predetermined size identifier set and unintentional transmission of the field of interest.

[0344] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0345] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0346] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this specification does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0347] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0348] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0349] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0350] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0351] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0352] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0353] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0354] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0355] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may 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.

[0356] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0357] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0358] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for implementing private information retrieval, wherein a server encrypts a database to obtain a query basis, and sends the query basis to a client; the encryption or decryption performed by the client and the server on the same target adopts an encryption or decryption algorithm with exchangeable order; In one retrieval process, the method comprises: the client sends a sensitive field encrypted by the client itself to the server, and obtains the same sensitive field encrypted by the server through interaction with the server; the client retrieves in the query basis according to the sensitive field encrypted by the server to obtain an identifier of a matching record; a value of an interesting field in a record corresponding to the identifier of the matching record in the database is transmitted to the client between the server and the client through an oblivious transfer method; wherein the step of the client obtaining the same sensitive field encrypted by the server through interaction with the server comprises: the server re-encrypts the sensitive field encrypted by the client with its own private key and then sends the re-encrypted sensitive field to the client, and the client decrypts the twice-encrypted sensitive field with its own private key to obtain the sensitive field encrypted by the server.

2. The method according to claim 1, wherein when the total number of fields excluding IDs in the database is n and the number of interesting fields is 1, the step of transmitting the value of the interesting field in the record corresponding to the identifier of the matching record in the database to the client between the server and the client through an oblivious transfer method comprises: the value of the interesting field in the record corresponding to the identifier of the matching record in the database is transmitted to the client between the server and the client through a 1-out-of-n oblivious transfer method.

3. The method according to claim 2, wherein the step of transmitting the value of the interesting field in the record corresponding to the identifier of the matching record in the database to the client between the server and the client through a 1-out-of-n oblivious transfer method comprises: the server encrypts values of n fields in the corresponding matching record in the database respectively with n different keys to obtain n encryption results, and sends the n encryption results to the client; the client decrypts a corresponding one of the n encryption results sent by the server by using a key corresponding to the interesting field.

4. The method according to claim 1, wherein when the total number of fields excluding IDs in the database is n, the number of interesting fields is k, and 1<k<n, the step of transmitting the value of the interesting field in the record corresponding to the identifier of the matching record in the database to the client between the server and the client through an oblivious transfer method comprises: The server uses Each of the k fields in the matching record is encrypted using a different key to obtain... The encrypted result is sent. The server sends an encrypted result to the client; the client then uses the key corresponding to the identifier in the matching record to decrypt the message sent by the server. One encrypted result that matches the identifier of the record in each encrypted result.

5. The method according to claim 1, wherein when the total number of fields excluding IDs in the database is n and the number of interesting fields is 1, the step of transmitting the value of the interesting field in the record corresponding to the identifier of the matching record in the database to the client between the server and the client through an oblivious transfer method comprises: the client constructs an obfuscation set comprising m fields and sends the obfuscation set to the server, 1<m<n, and the m obfuscation fields comprise the interesting field; Between the server and the client, values of m fields indicated by the obfuscation set in the record corresponding to the identifier of the matching record in the database are transmitted to the client through 1-out-of-m oblivious transfer.

6. The method according to claim 5, wherein transmitting, between the server and the client through 1-out-of-m oblivious transfer, values of m records corresponding to identifiers or values of fields of interest in the corresponding records indicated by the obfuscation set in the record corresponding to the identifier of the matching record in the database to the client comprises: the server encrypts values of m fields indicated by the obfuscation set in the record corresponding to the identifier of the matching record in the database respectively with m different keys to obtain m encrypted results, and sends the m encrypted results to the client; the client decrypts a corresponding one of the m encrypted results sent by the server by using a key corresponding to a field of interest.

7. The method according to claim 1, wherein when a total number of fields excluding IDs in the database is n and a number of fields of interest is k, transmitting, between the server and the client through oblivious transfer, values of fields of interest in the record corresponding to the identifier of the matching record in the database to the client comprises: the client constructs an obfuscation set of size m and sends the obfuscation set to the server, wherein 1<m<n, and one subset in the m obfuscation elements comprises the k matched fields of interest; the server generates m keys, enables the client to obtain a specified key through a 1-out-of-m oblivious transmission protocol; the server encrypts m subsets in the obfuscation set respectively by using m different keys to obtain m encrypted result subsets, and sends the m encrypted result subsets to the client; the client decrypts the subset formed by the k obtained fields of interest by using the obtained key, so as to obtain a correct decryption result.

8. A method for implementing private information retrieval, wherein a server obtains a query base after encrypting a database, and sends the query base to a client; encryption or decryption performed by the client and the server on a same target adopts an encryption or decryption algorithm with exchangeable order; in a retrieval process, the method comprises: the client sends a self-encrypted sensitive field to the server, and obtains the same sensitive field encrypted by the server through interaction with the server; the client retrieves in the query base according to the sensitive field encrypted by the server to obtain an identifier of a matching record, and generates an obfuscation set of size m comprising fields of interest; between the server and the client, values of fields indicated by the obfuscation set of size m in the matching record in the database are transmitted to the client through oblivious transfer; wherein obtaining, by the client, the same sensitive field encrypted by the server through interaction with the server comprises: the server re-encrypts the sensitive field encrypted by the client with its own key and then sends the re-encrypted sensitive field to the client, and the client decrypts the twice-encrypted sensitive field with its own key to obtain the sensitive field encrypted by the server.

9. The method according to claim 8, when the total number of fields excluding ID in the database is n, the number of said fields of interest is 1, and m<n, transmitting, by means of oblivious transfer between said server and said client, values of said fields of interest in matching records in said database to said client comprises: transmitting, by 1-out-of-m oblivious transfer between said server and said client, values of m fields indicated by a confusion set in said database to said client.

10. The method according to claim 9, transmitting, by 1-out-of-m oblivious transfer between said server and said client, values of m fields indicated by a confusion set in said database comprises: said server encrypts values of m fields indicated by said confusion set in said database respectively with m different keys to obtain m encrypted results, and transmits said m encrypted results to the client; said client decrypts the encrypted result of 1 field of interest among said m fields transmitted by said server by using a key corresponding to an identifier of the matching record.

11. The method according to claim 8, when the total number of records in the database is n, and the number of matching records retrieved by said client in a query base is k, 1<k<m<n, 1 sub-set of the confusion set with size m generated by said client that comprises expected IDs to be obtained includes identifiers of said k matching records; transmitting, by means of oblivious transfer between said server and said client, values of records corresponding to said confusion set or fields of interest in corresponding records to said client comprises: the server generates m keys, enables the client to obtain the key specified thereby through a 1-out-of-m oblivious transfer protocol; the server encrypts m sub-sets in said confusion set respectively with m different keys to obtain m encrypted result sub-sets, and transmits said m encrypted result sub-sets to the client; the client decrypts the sub-set constituted by identifiers of k matching records by using the obtained key, thereby obtaining a correct decryption result.

12. A method for implementing private information retrieval, wherein a server encrypts a database to obtain a query base, and transmits the query base to a client; encryption or decryption performed by the client and the server for the same target adopts an encryption or decryption algorithm with an exchangeable order; in one retrieval process, the method comprises: the client transmits a self-encrypted sensitive field to the server, and obtains the same sensitive field encrypted by the server through interaction with the server; the client retrieves in the query base according to said sensitive field encrypted by the server to obtain an identifier of a matching record; the server returns, by means of double oblivious transfer, values of fields of interest in records corresponding to an identifier set with a predetermined size that includes the identifier of said matching record in said database to the client; said double oblivious transfer is a combination of oblivious transfer for the identifier set with a predetermined size and oblivious transfer for fields of interest; wherein said client obtaining the same sensitive field encrypted by the server through interaction with the server comprises: The server uses its own key to re-encrypt the sensitive field encrypted by the client and sends it to the client. The client uses its own key to decrypt the sensitive field after the two encryptions to obtain the sensitive field encrypted by the server.

13. The method of claim 12, wherein the unintentional transmission of the predetermined size identifier set includes n-choose-1 unintentional transmission, n-choose-k unintentional transmission, and m-choose-1 unintentional transmission of n, where n is the size of the row and m is the size of the row's confusion set.

14. The method of claim 12, wherein the unintentional transmission of the field of interest includes n-select-1 unintentional transmission, n-select-k unintentional transmission, and m-select-1 unintentional transmission of n, wherein n is the size of the column excluding ID, and m is the size of the obfuscation set of the column excluding ID.

15. A system for retrieving privacy information, comprising a server and a client, wherein the client and server perform encryption or decryption on the same target using an encryption or decryption algorithm with interchangeable order, and: The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client. During a search process: The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server; The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server; The server and the client transmit the value of the field of interest in the record corresponding to the identifier of the matching record in the database to the client via an unintentional transmission method; wherein... The client obtains the same sensitive field encrypted by the server through interaction with the server, including: The server uses its own key to re-encrypt the sensitive field encrypted by the client and sends it to the client. The client uses its own key to decrypt the sensitive field after the two encryptions to obtain the sensitive field encrypted by the server.

16. A server for retrieving privacy information, wherein the server and client perform encryption or decryption on the same target using an encryption or decryption algorithm with interchangeable order, and: The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client. During a search process: The server receives a sensitive field sent by the client, which it has encrypted, and then encrypts it again before returning it to the client. This allows the client to decrypt the twice-encrypted sensitive field using its own key to obtain the sensitive field encrypted by the server. The client then searches the query base based on the sensitive field encrypted by the server to obtain the identifier of the matching record. The server also transmits the value of the field of interest in the record corresponding to the identifier of the matching record in the database to the client via an unintentional transmission method.

17. A system for retrieving privacy information, comprising a server and a client, wherein the client and server perform encryption or decryption on the same target using an encryption or decryption algorithm with interchangeable order, and: The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client. During a search process: The client sends a sensitive field that it has encrypted to the server, and obtains the same sensitive field encrypted by the server through interaction with the server; The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server, and generates a confusion set of size m containing the fields of interest. The server and the client transmit the value of the field indicated by the obfuscation set of size m in the matching record in the database to the client through an unintentional transmission method; in, The client obtains the same sensitive field encrypted by the server through interaction with the server, including: The server uses its own key to re-encrypt the sensitive field encrypted by the client and sends it to the client. The client uses its own key to decrypt the sensitive field after the two encryptions to obtain the sensitive field encrypted by the server.

18. A system for retrieving privacy information, comprising a server and a client, wherein the client and server perform encryption or decryption on the same target using an encryption or decryption algorithm with interchangeable order, and: The server is configured with a database, and after encrypting the database, a query base is obtained and sent to the client. During a search process: The client sends its own encrypted sensitive field to the server and obtains the same encrypted sensitive field from the server through interaction with the server. The client retrieves the identifier of the matching record from the query base based on the sensitive fields encrypted by the server. The server uses a double unintentional transmission method to return the value of the field of interest in the corresponding record of a predetermined size set of identifiers, including the identifier of the matching record, to the client; the double unintentional transmission method is a combination of unintentional transmission of the predetermined size set of identifiers and unintentional transmission of the field of interest. The client obtains the same sensitive field encrypted by the server through interaction with the server, including: The server uses its own key to re-encrypt the sensitive field encrypted by the client and sends it to the client. The client uses its own key to decrypt the sensitive field after the two encryptions to obtain the sensitive field encrypted by the server.

Images