A data query method and device

Abstract

The application discloses a data query method and device, comprising: a data party receiving a query request sent by a query party; wherein the query request comprises a query position of a user to be queried; a query table is constructed according to user identifiers in a data set; the value of each position in the query table is determined based on the position of the user identifier in the data set in the query table, and the value corresponding to the query position in the query table indicates whether the user identifier of the user to be queried is recorded in the query table; the query result indicates that the user to be queried corresponding to the query position exists or does not exist in the data set; and the data party sends the query result to the query party. Thus, data encryption operation is reduced, data calculation amount and calculation difficulty are reduced, and data query efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of financial technology (Fintech), and more particularly to a data query method and apparatus. Background Technology

[0002] With the development of computer technology, more and more technologies (such as blockchain, cloud computing or big data) are being applied in the financial field. The traditional financial industry is gradually transforming into financial technology, and big data technology is no exception. However, due to the security and real-time requirements of the financial and payment industries, higher demands are being placed on big data technology.

[0003] In existing data query methods, the querying party (the party seeking data) typically retrieves data from the data provider (the party owning the data). The querying party sends a query request to the data provider; the data provider then determines the query results based on the query request and returns the results to the querying party.

[0004] To ensure data anonymity, public-key cryptography is required, employing operations such as elliptic curve multiplication to encrypt parameters involved in data transmission. However, this high computational complexity leads to low data retrieval efficiency. Summary of the Invention

[0005] This invention provides a data query method and apparatus to reduce data encryption operations, decrease the amount and difficulty of data calculation, and improve data query efficiency.

[0006] In a first aspect, embodiments of the present invention provide a data query method, including:

[0007] The data provider receives a query request from the querying party; the query request includes the query location of the user to be queried.

[0008] The data provider retrieves the value corresponding to the query position from the query table to obtain the query result; the query table is constructed based on the user identifiers in the dataset; the value at each position in the query table is determined based on the position of the user identifier in the dataset in the query table, and the value corresponding to the query position in the query table indicates whether the query table records the user identifier of the user to be queried; the query result indicates whether the user to be queried corresponding to the query position exists or does not exist in the dataset;

[0009] The data provider sends the query results to the query provider.

[0010] In the above technical solution, when the querying party queries data from the data provider, it only sends the query location of the user to be queried to the data provider, without needing to send the user's identifier. Therefore, the anonymity and security of the user's information can be guaranteed. Furthermore, since the query location does not reveal the user's plaintext information, encryption of the query location is unnecessary; it can be transmitted directly through a secure channel, ensuring data accuracy. This reduces data encryption operations, lowering the computational load and complexity.

[0011] After receiving the query location, the data provider can directly query the query table based on the query location without needing to perform decryption operations on the query location. This reduces data processing, lowers the amount and difficulty of data calculation, and improves data query efficiency.

[0012] Furthermore, the query table is constructed by the data provider based on user identifiers in the dataset. The value at each position in the query table is determined by the position occupied by the user identifier within the table. The value corresponding to the query position in the query table indicates whether the query table records the user identifier of the user to be queried, and also indicates whether the user identifier of the user to be queried exists in the dataset. In other words, the existence of the user to be queried at the corresponding query position can be determined from the value corresponding to the query position in the query table. The values ​​at each position in the query table do not contain plaintext data, ensuring data anonymity and security. The corresponding query results will not reveal user identifiers, therefore, the query results do not need to be encrypted and can be directly transmitted through a secure channel to ensure data accuracy, thereby reducing data encryption operations and lowering the amount and difficulty of data computation.

[0013] Optionally, the data provider constructs the query table based on user identifiers in the dataset, including:

[0014] The data provider randomly generates a query key;

[0015] The data provider encrypts the user identifier using the query key to obtain ciphertext data;

[0016] The data provider calculates the data length of the query table based on the amount of encrypted data.

[0017] The data provider calculates the position of the encrypted data in the query table, sets a preset value for the position, and constructs the query table.

[0018] In the above technical solution, when the data provider constructs the query table, it encrypts the user identifier. This encryption operation is used to ensure the anonymity and security of the user identifier. No decryption operation is required, which reduces data encryption operations and lowers the amount and difficulty of data computation.

[0019] After obtaining the encrypted data, the data provider calculates the position of the encrypted data in the query table, and then sets a preset value for that position. This preset value indicates that the user identifier corresponding to the encrypted data is recorded in the dataset, thereby ensuring the concealment and security of the data. It also ensures that the corresponding query results will not reveal the user identifier information, reduces the encryption operation on the query results, and lowers the amount and difficulty of data computation.

[0020] Optionally, the data provider calculates the data length of the query table based on the amount of encrypted data, including:

[0021] The data provider selects the number of positions based on the quantity of the encrypted data; the number of positions represents the number of positions of any encrypted data in the lookup table; the number of positions is directly proportional to the quantity of encrypted data.

[0022] The data provider calculates the sum of the number of locations and a preset redundancy value;

[0023] The data provider uses the product of the number of encrypted data and the sum as the data length of the query table.

[0024] In the above technical solution, the number of positions is selected based on the amount of ciphertext data, and the number of positions is specified to be proportional to the amount of ciphertext data. The data length of the lookup table is calculated by using the number of positions, a preset redundancy value, and the amount of ciphertext data, thereby ensuring that the positions of each piece of ciphertext data are evenly distributed in the lookup table, preventing data conflicts, and improving lookup accuracy.

[0025] Optionally, the data provider calculates the position of the encrypted data in the query table, including:

[0026] For the ciphertext data at the i-th position in the query table, the data provider performs obfuscation calculations on the ciphertext data based on i to obtain obfuscation parameters;

[0027] The data provider performs a modulo operation between the value of the obfuscation parameter and the data length of the lookup table to obtain the i-th position of the ciphertext data in the lookup table.

[0028] Optionally, confusion calculations can be performed according to the following formula (1);

[0029] obs_Ri=hash(obs_(R-1)i|m|i) (1);

[0030] Where obs_Ri is the value of the obfuscation parameter; m is the ciphertext data; R is a positive integer, and 1≤R≤i; when R=1, obs_1i=hash(m|i).

[0031] In the above technical solution, when determining the position of the ciphertext data in the query table, the ciphertext data is obfuscated to further ensure the concealment and security of the data and prevent the ciphertext data from being deciphered.

[0032] Secondly, embodiments of the present invention provide a data query method, including:

[0033] The querying party generates the query location of the user to be queried based on the user identifier, query key, number of locations, and data length of the query table; the query key, the number of locations, and the data length of the query table are sent by the data party; the query table is constructed by the data party based on the user identifiers in the dataset, and the values ​​in the query table represent the user identifiers recorded in the dataset;

[0034] The querying party sends the query request to the data party using the query location of the user to be queried as a query request; the query request is used to instruct the data party to determine the value corresponding to the query location in the query table based on the query location, and obtain the query result;

[0035] The querying party receives the query results fed back by the data party based on the query request; the query results indicate whether the user to be queried exists in the dataset.

[0036] Optionally, the querying party generates the query location of the user to be queried based on the user identifier, query key, number of locations, and data length of the query table, including:

[0037] The querying party encrypts the user identifier of the user to be queried according to the query key to obtain the ciphertext identifier;

[0038] For the i-th query position of the ciphertext identifier, the querying party performs obfuscation calculation on the ciphertext identifier based on i to obtain an obfuscated identifier;

[0039] The querying party performs a modulo operation between the value of the obfuscation identifier and the data length of the query table to obtain the i-th query position of the user to be queried.

[0040] In the above technical solution, when the querying party queries data from the data provider, it first encrypts the user identifier of the user to be queried, obtaining a ciphertext identifier. Then, it calculates the query location based on the ciphertext identifier and uses the query location as the query request. Therefore, the anonymity and security of the user identifier of the user to be queried can be guaranteed. Furthermore, since the query location does not reveal the user identifier of the user to be queried, it is not necessary to encrypt the query location; it can be directly transmitted through a secure channel, ensuring data accuracy. This reduces data encryption operations, lowers the computational load, and reduces computational difficulty.

[0041] The query table does not contain plaintext data, ensuring data anonymity and security. The corresponding query results also do not reveal plaintext data, so encryption is not required; the results can be transmitted directly through a secure channel. Therefore, the querying party does not need to decrypt the results after receiving them, thus reducing data encryption operations and lowering the computational load and difficulty.

[0042] Optionally, after receiving the query results returned by the data provider based on the query request, the querying party further includes:

[0043] If the querying party determines that the values ​​corresponding to the query positions of the user to be queried in the query results are all preset values, then it determines that the user to be queried exists in the dataset;

[0044] If the querying party determines that the value corresponding to any query position of the user to be queried in the query results is not a preset value, then it determines that the user to be queried does not exist in the dataset.

[0045] In the above technical solution, each position in the query table has an initial value in its initial state. After the position of the encrypted data in the query table is determined, that position is set from the initial value to a preset value. Therefore, when the value corresponding to the query position is determined to be the preset value, it means that the user record corresponding to the query position is in the query table, and further indicates that the user identifier record corresponding to the user is in the dataset. This enables the determination of whether the user being queried exists in the dataset even in a data-hidden state.

[0046] Thirdly, embodiments of the present invention also provide a data query device, comprising:

[0047] A receiving module is used to receive a query request sent by the querying party; the query request includes the query location of the user to be queried;

[0048] The query module is used to retrieve the value corresponding to the query position from the query table and obtain the query result. The query table is constructed based on the user identifiers in the dataset. The value of each position in the query table is determined based on the position of the user identifier in the dataset in the query table. The value corresponding to the query position in the query table indicates whether the query table records the user identifier of the user to be queried. The query result indicates whether the user to be queried corresponding to the query position exists or does not exist in the dataset.

[0049] The sending module is used to send the query results to the querying party.

[0050] Optionally, the device further includes a construction module;

[0051] The building module is specifically used for:

[0052] Randomly generate query keys;

[0053] The user identifier is encrypted using the query key to obtain ciphertext data;

[0054] Calculate the data length of the query table based on the amount of encrypted data;

[0055] Calculate the position of the encrypted data in the query table, set a preset value for the position, and construct the query table.

[0056] Optionally, the building module is specifically used for:

[0057] The number of positions is selected based on the amount of encrypted data; the number of positions represents the number of positions of any encrypted data in the lookup table; the number of positions is directly proportional to the amount of encrypted data.

[0058] Calculate the sum of the number of positions and the preset redundancy value;

[0059] The product of the number of encrypted data and the sum is used as the data length of the query table.

[0060] Optionally, the building module is specifically used for:

[0061] For the ciphertext data at the i-th position in the query table, an obfuscation calculation is performed on the ciphertext data based on i to obtain obfuscation parameters;

[0062] The value of the obfuscation parameter is moduloed by the length of the data in the lookup table to obtain the i-th position of the ciphertext data in the lookup table.

[0063] Optionally, confusion calculations can be performed according to the following formula (1);

[0064] obs_Ri=hash(obs_(R-1)i|m|i) (1);

[0065] Where obs_Ri is the value of the obfuscation parameter; m is the ciphertext data; R is a positive integer, and 1≤R≤i; when R=1, obs_1i=hash(m|i).

[0066] Fourthly, embodiments of the present invention also provide a data query device, comprising:

[0067] The generation unit is used to generate the query location of the user to be queried based on the user identifier, query key, number of locations, and data length of the query table; the query key, the number of locations, and the data length of the query table are sent by the data provider; the query table is constructed based on the user identifiers in the dataset; the value of each location in the query table is determined based on the position of the user identifier in the dataset in the query table, and the value corresponding to the query location in the query table indicates whether the query table records the user identifier of the user to be queried;

[0068] The sending unit is used to send the query location of the user to be queried as a query request to the data provider; the query request is used to instruct the data provider to determine the value corresponding to the query location in the query table based on the query location, and obtain the query result;

[0069] The receiving unit is used to receive the query result fed back by the data provider based on the query request; the query result indicates whether the user to be queried corresponding to the query location exists in the dataset.

[0070] Optionally, the generation unit is specifically used for:

[0071] The user identifier of the user to be queried is encrypted using the query key to obtain the ciphertext identifier;

[0072] For the i-th query position of the ciphertext identifier, an obfuscation calculation is performed on the ciphertext identifier based on i to obtain an obfuscated identifier;

[0073] The i-th query position of the user to be queried is obtained by performing a modulo operation between the value of the obfuscation identifier and the data length of the query table.

[0074] Optionally, the device further includes a parsing unit;

[0075] The parsing unit is used for:

[0076] After receiving the query results fed back by the data provider based on the query request, if it is determined that the values ​​corresponding to the query position of the user to be queried in the query results are all preset values, then it is determined that the user to be queried exists in the dataset.

[0077] If it is determined that the value corresponding to any query position of the user to be queried in the query results is not a preset value, then it is determined that the user to be queried does not exist in the dataset.

[0078] Fifthly, embodiments of the present invention also provide a computer device, comprising:

[0079] Memory, used to store program instructions;

[0080] The processor is used to call the program instructions stored in the memory and execute the above data query method according to the obtained program.

[0081] Sixthly, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described data query method. Attached Figure Description

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

[0083] Figure 1 A schematic diagram of a system architecture provided for an embodiment of the present invention;

[0084] Figure 2 A flowchart illustrating a data query method provided in an embodiment of the present invention;

[0085] Figure 3 A schematic diagram of a lookup table provided in an embodiment of the present invention;

[0086] Figure 4 A flowchart illustrating a data query method provided in an embodiment of the present invention;

[0087] Figure 5 A flowchart illustrating a data query method provided in an embodiment of the present invention;

[0088] Figure 6 This is a schematic diagram of the structure of a data query device provided in an embodiment of the present invention;

[0089] Figure 7 This is a schematic diagram of the structure of a data query device provided in an embodiment of the present invention. Detailed Implementation

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

[0091] To better illustrate the technical solution of this application, the following explanations are provided for any terms that may appear.

[0092] A hash function is a method for creating a small numerical "fingerprint" from any type of data. Also called a hashing function, it compresses messages or data into a digest, reducing the data size and fixing the data format.

[0093] Anonymous querying, also known as privacy information retrieval, refers to the querying party concealing the keywords or identifying information of the queried object (i.e., the user being queried), such as their ID (Identity Document). The data provider provides matching query results but cannot know which specific queried object they correspond to. Data remains within the scope of the query and can be computed, eliminating the possibility of data caching, data leakage, and data selling.

[0094] Anonymous query methods generally involve two parties: the querying party possesses the user identifier of the user to be queried, such as user id; the data party possesses the dataset [id, y]. The querying party wants to obtain the data y corresponding to id from the data party, or to know whether id is in the data party's dataset, but does not want the data party to know the user identifier id of the user to be queried sent by the querying party.

[0095] Accidental transmission is a cryptographic protocol in which a message sender sends one message from a list of pending messages to a receiver, but afterwards remains oblivious to which message was sent. For example, sender Alice generates two pairs of public and private keys, puk0 and pri0, puk1 and pri1; she then sends the two public keys puk0 and puk1 to receiver Bob.

[0096] Bob generates a random number and encrypts it using one of the two public keys he received (the choice of public key depends on which data Bob wants to obtain. For example, if he wants data M0, he encrypts the random number using puk0; if he wants data M1, he encrypts the random number using puk1), resulting in the ciphertext of the random number. He then sends the ciphertext of the random number to Alice.

[0097] Alice uses her two private keys (pri0, pri1) to decrypt the received random number ciphertext, obtaining two decryption results k0 and k1. Then, she performs an XOR operation between the two decryption results and the two messages to be sent (e.g., k0 XOR M0, k1 XOR M1), obtaining two XOR results (e0, e1), and sends the two XOR results e0, e1 to Bob.

[0098] Bob performs an XOR operation between his real random number and the received e0 and e1 respectively. Of the two results, only one is the real data and the other is a random number.

[0099] In the above process, Alice cannot distinguish Bob's real random number from the results k0 and k1 obtained by decrypting with the two private keys, ensuring that Alice cannot know which data Bob will obtain.

[0100] In existing anonymous data query methods, the aforementioned inadvertent transmission method is generally used to achieve anonymity. As described above, to ensure data anonymity, public-key cryptography is required, employing operations such as elliptic curve multiplication and XOR operations to encrypt parameters involved in data transmission. Therefore, it can be concluded that existing anonymous data query methods involve high computational complexity, resulting in low data query efficiency.

[0101] Based on the aforementioned unintentional transmission method, in one feasible approach, the querying party can obfuscate the user identifier of the user being queried by forging multiple non-existent data. For example, k1 and k2 are forged data, while ks is real data; the data provider cannot retrieve results based on k1 and k2, but can retrieve results based on ks. Therefore, the data provider can infer that the data the querying party wants to retrieve is the data corresponding to ks.

[0102] For example, if the user to be queried is Zhang San, and the confused users are Li Si and Wang Wu, the data provider, knowing that Li Si and Wang Wu are not recorded in the dataset, can guess that the user to be queried in this query is Zhang San.

[0103] The above technical solutions pose a risk of information leakage, and their anonymity and security are relatively low during data querying.

[0104] Therefore, there is an urgent need for a data query method that, while satisfying the requirements of anonymous queries, reduces data encryption operations, lowers the amount and difficulty of data computation, and improves data query efficiency.

[0105] Figure 1 An exemplary system architecture applicable to an embodiment of the present invention is shown, the system architecture including a query party 110 and a data party 120.

[0106] In this process, the query party 110 is the party that needs to query data. The query party 110 encrypts the user identifier of the user to be queried using the query key to obtain a ciphertext identifier. Then, for the i-th query position of the ciphertext identifier, the query party performs an obfuscation calculation based on the value corresponding to i, obtaining an obfuscated identifier. Finally, the query party performs a modulo operation between the value of the obfuscated identifier and the data length of the query table to obtain the i-th query position of the user to be queried, and sends this query position as a query request to the data party 120.

[0107] Data Provider 120 is the party that owns the data. Data Provider 120 is used to generate a query key (e.g., generating a random number as the query key). Then, based on the query key, each user identifier in the dataset (e.g., user identifier id1 of user Zhang San) is encrypted to obtain the encrypted data.

[0108] Data Provider 120 selects the number of positions based on the quantity of ciphertext data. The number of positions represents the number of positions any given ciphertext data occupies in the lookup table, and this number is directly proportional to the quantity of ciphertext data. For example, if the quantity of ciphertext data is 900,000, and the selected number of positions k = 7, then any given ciphertext data occupies 7 positions in the lookup table.

[0109] Data Provider 120 calculates the sum of the number of locations and the preset redundancy value. For example, the preset redundancy value is 1, representing the amount of data redundancy. Data Provider 120 uses the product of the number of ciphertext data and the sum as the data length of the lookup table. For example, if the number of ciphertext data is 900,000, the number of locations k = 7, and the preset redundancy value s = 1, then the data length of the lookup table L = 900,000 × (7 + 1) = 7,200,000.

[0110] For any encrypted data at the i-th position in the lookup table (e.g., i=3), data provider 120 performs obfuscation calculations on the encrypted data based on the value of i to obtain obfuscation parameters. Then, the value of the obfuscation parameters is moduloed by the length of the lookup table to obtain the i-th position of the encrypted data in the lookup table. After obtaining the positions of the encrypted data in the lookup table, preset values ​​are set for each position, and the lookup table is constructed.

[0111] After constructing the query table, data provider 120 sends the data length, query key, and number of locations of the query table to query provider 110, so that query provider 110 can generate query locations based on the user identifier of the user to be queried.

[0112] After receiving the query positions sent by the querying party 110, the data party 120 determines the value corresponding to each query position in the query table. If the value corresponding to each query position is a preset value, it means that the user to be queried exists in the query table, and further indicates that the user to be queried is recorded in the dataset, thereby providing the query result.

[0113] It should be noted that the above Figure 1 The structure shown is merely an example, and the embodiments of the present invention are not limited thereto.

[0114] Based on the above description Figure 2 An exemplary flowchart of a data query method provided by an embodiment of the present invention is shown, which can be executed by a data query device.

[0115] like Figure 2 As shown, the process specifically includes:

[0116] Step 210: The data provider receives the query request sent by the query provider.

[0117] In this embodiment of the invention, the query request includes the query location of the user to be queried. There can be multiple users to be queried, such as three users: Zhang San, Li Si, and Wang Wu. For any given user, the number of query locations for that user is equal to the number of locations. The number of locations is selected by the data provider based on the amount of encrypted data, representing the number of locations of any encrypted data in the query table.

[0118] Step 220: The data provider determines the value corresponding to the query position in the query table and obtains the query result.

[0119] In this embodiment of the invention, the query table is constructed based on user identifiers in the dataset. The value at each position in the query table is determined based on the position of the user identifier in the dataset within the query table. The value corresponding to the query position in the query table indicates whether the query table records the user identifier of the user to be queried; that is, the value corresponding to the query position serves as the query result. The querying party determines whether the user to be queried exists in the dataset based on the query result. Therefore, the query result indicates whether the user to be queried at the query position exists or does not exist in the dataset.

[0120] For example, if the values ​​of the user identifier of a user to be queried are all preset values ​​in the query table, it means that the user identifier of the user to be queried is recorded in the dataset. Therefore, the query result indicates whether the user to be queried exists in the dataset.

[0121] Step 230: The data provider sends the query result to the query provider.

[0122] In step 220, the dataset is used to record information about each user. The dataset includes data attributes, which represent the attributes of each user recorded in the dataset. For example, if the data attribute is whitelist or blacklist, it means that each user recorded in the dataset is a whitelisted user or a blacklisted user.

[0123] In some embodiments, the dataset includes a user identifier and the data attributes of the user corresponding to the user identifier. For example, the user identifier may be a name, ID number, mobile phone number, etc.; the user's data attributes may include whether the user is on a blacklist or a whitelist.

[0124] For example, user identifiers include: Zhang San, Li Si, and Wang Wu. Among them, Zhang San is in the whitelist, Li Si is in the blacklist, and Wang Wu is in the whitelist.

[0125] In one feasible approach, the dataset is preprocessed to ensure that the data attributes of the users in the dataset are identical, and the preprocessed dataset is then used as the dataset to be queried. For example, all users in the dataset are either in a blacklist or a whitelist.

[0126] Based on the above description, the preprocessed dataset includes Zhang San and Wang Wu. Both Zhang San and Wang Wu are on the whitelist.

[0127] In this embodiment of the invention, the explanation focuses on datasets where users share the same data attributes. For example, each user in the dataset is represented as either a whitelist or a blacklist user. Before the querying party performs a data query, the data provider constructs a query table based on the dataset.

[0128] In one feasible approach, the data provider encrypts the identifiers of each user in the dataset to ensure the anonymity and security of the data.

[0129] Specifically, the data provider randomly generates a query key, and then encrypts the user identifier based on the query key to obtain ciphertext data.

[0130] For example, user identifiers include id_1, id_2, ..., id_n-1, id_n. The query key is a 256-character random string (i.e., a random number of 256 characters) randomly generated by the data provider. In this embodiment of the invention, for ease of description, the query key is referred to as "key".

[0131] After generating the query key, the data provider performs encrypted calculations on each user identifier (id_1, id_2, ..., id_n-1, id_n) in the dataset. For example, a hash function is used to perform a hash operation on the user identifier and the query key to obtain a hash value. Specifically, id` = hash(id|key); where id` represents the encrypted data, and hash(id|key) represents the hash operation on the user identifier and the query key.

[0132] Based on the above description, for example, id`_1 = hash(id_1|key), id`_2 = hash(id_2|key), ..., id`_n-1 = hash(id_n-1|key), id`_n = hash(id_n|key). Here, id`_1 represents the ciphertext data corresponding to user identifier id_1, and so on, id`_n represents the ciphertext data corresponding to user identifier id_n.

[0133] In this embodiment of the invention, other encryption algorithms can also be used to encrypt the user identifier, thereby obfuscating the user identifier and ensuring its anonymity and security.

[0134] After obtaining the encrypted data, the data provider calculates the data length of the query table based on the amount of encrypted data.

[0135] Specifically, the data provider selects the number of positions based on the amount of ciphertext data; the number of positions represents the number of positions any ciphertext data occupies in the lookup table; the number of positions is directly proportional to the amount of ciphertext data. For example, if the number of positions k = 7, it means that any ciphertext data occupies 7 positions in the lookup table.

[0136] After selecting the number of positions, the data provider calculates the sum of the number of positions and a preset redundancy value. This preset redundancy value can be an empirically predetermined value, such as 1 or 2. It is used to reduce the repetition rate of any two encrypted data items in the lookup table, i.e., to reduce the probability that any two encrypted data items are in the same position in the lookup table, thereby improving the accuracy of data retrieval.

[0137] Taking the above description as an example, if the preset redundancy value is 1 and the number of positions k = 7, then the sum of the number of positions and the preset redundancy value is 8.

[0138] The data provider uses the product of the number of encrypted data entries and the sum mentioned above as the data length of the lookup table. For example, assuming n equals 900,000, this means there are 900,000 encrypted data entries, corresponding to 900,000 user identifiers; and if the sum equals 8, the data length of the lookup table is 7.2 million.

[0139] After determining the length of the lookup table, the data provider calculates the position of each encrypted data item within the lookup table to generate the lookup table. Based on the above description, any encrypted data item has k positions in the lookup table; therefore, it is necessary to calculate the i-th position of any encrypted data item in the lookup table; where i is a positive integer, and 1 ≤ i ≤ k.

[0140] Specifically, the data provider performs obfuscation calculations on the ciphertext data based on the value of i to obtain obfuscation parameters; whereby the obfuscation calculations are performed according to the following formula (1);

[0141] obs_Ri=hash(obs_(R-1)i|m|i) (1);

[0142] Where, obs_Ri is the value of the obfuscation parameter; m is the ciphertext data; R is a positive integer, and 1≤R≤i; when R=1, obs_1i=hash(m|i). R represents the number of times the obfuscation calculation is performed on the ciphertext data. R can be a value preset based on experience, or it can be a random value, such as R=4.

[0143] Based on the above description, when i = 1, it means that the first position of the ciphertext data in the lookup table has been calculated. Assuming m = id`_1, i = 1, R = 4, then according to the above formula (1), obs_11 = hash(id`_1|1), obs_21 = hash(obs_11|id`_1|1), obs_31 = hash(obs_21|id`_1|1), obs_41 = hash(obs_31|id`_1|1). obs_41 is used as the obfuscation parameter.

[0144] After obtaining the obfuscation parameters, the data provider performs a modulo operation between the value of the obfuscation parameters and the length of the lookup table to obtain the i-th position of the ciphertext data in the lookup table. The modulo operation is shown in the following formula (2).

[0145] P_i = obs_Ri%L (2);

[0146] Where P_i is the i-th position of the ciphertext data in the lookup table, obs_Ri is the obfuscation parameter of the ciphertext data, and L is the data length of the lookup table.

[0147] Based on the above description, let's take an example: obs_41 is a hash value, a 256-bit number. Assuming L = 7.2 million and i = 1, P_1 = obs_41 % 7.2 million = 2, meaning the ciphertext data at position i in the lookup table is the second position in the lookup table. Similarly, the data provider will calculate the k positions of each ciphertext data item in the lookup table.

[0148] After obtaining the k positions of each encrypted data item in the lookup table, the data provider sets preset values ​​for the positions corresponding to the k positions of each encrypted data item in the lookup table, thereby constructing the lookup table. The preset values ​​can be preset identifier values, indicating that the user identifier record corresponding to the encrypted data set at that position is in the dataset.

[0149] Figure 3 This is a schematic diagram of a lookup table exemplarily shown in an embodiment of the present invention. The lookup table includes a plurality of consecutive positions. For example... Figure 3 As shown, the lookup table has n positions, from "0 to n-1". Each position corresponds to a value (initial value or preset value). The initial value is set in the lookup table before the data provider calculates the k positions of each encrypted data, such as 0. After the data provider calculates the k positions of each encrypted data, the initial value is changed to the preset value, such as 1.

[0150] Based on the above description, let's take an example. Suppose the encrypted data is at position i in the lookup table, which is also the second position in the lookup table. Then, we set the initial value "0" of the second position in the lookup table to the preset value "1". During a query, the constructed lookup table can be used to determine whether the user being queried is recorded in the lookup table, and thus whether the user's identifier is recorded in the dataset. It should be noted that there can be multiple users to be queried, meaning there can be multiple user identifiers for each user.

[0151] Based on the above description, let's take an example and assume that the users to be queried include d1, d2, and d3; where d1's query positions are d11, d12, ..., d17; d2's query positions are d21, d22, ..., d27; and d3's query positions are d31, d32, ..., d37. In other words, the query request includes a total of 21 query positions.

[0152] The data provider does not know the user corresponding to the query position, thus ensuring the anonymity and security of the user being queried. For example, if all 21 query positions mentioned above are preset values ​​in the query table, it means that users d1, d2, and d3 are recorded in the dataset. As another example, if query position d21 is an initial value in the query table, and the remaining query positions are preset values, it means that users d1 and d3 are recorded in the dataset, but user d2 is not.

[0153] In other words, the data provider will send the value corresponding to the query location as the query result to the querying party, who will then determine whether the user being queried is recorded in the dataset.

[0154] In some feasible methods, the data provider can determine the query result; if the values ​​at the query positions are all preset values, the query result is determined to be "existent", indicating that all users to be queried are recorded in the dataset; if the value at any query position is not a preset value, the query result is determined to be "non-existent", indicating that one or more users to be queried are not recorded in the dataset.

[0155] To better illustrate the above technical solution, Figure 4 This is a schematic flowchart illustrating a data query method executorly shown in an embodiment of the present invention. This process can be executed by a data query device.

[0156] like Figure 4 As shown, the process includes:

[0157] Step 410: The querying party generates the query location of the user to be queried based on the user identifier, query key, number of locations, and data length of the query table.

[0158] In this embodiment of the invention, the query key, the number of locations, and the data length of the query table are sent by the data provider. Specifically, the query key, the number of locations, and the data length of the query table are determined by the data provider when constructing the query table, and the specific determination process has been described above. Figure 2 The details are described in the text and will not be repeated here.

[0159] The query table is constructed based on user identifiers in the dataset. The value at each position in the query table is determined by the position of the user identifier in the dataset within the query table. The value corresponding to the query position in the query table indicates whether the query table records the user identifier of the user to be queried; that is, the value at each position in the query table indicates whether the user identifier corresponding to that position is recorded in the dataset. The specific construction process has been described above. Figure 2 The details are described in the text and will not be repeated here.

[0160] Step 420: The querying party sends the query request to the data party, taking the query location of the user to be queried as the query request.

[0161] In this embodiment of the invention, the query request is used to instruct the data provider to determine the value corresponding to the query position in the query table based on the query position, and obtain the query result. The query result is the value corresponding to the query position in the query table.

[0162] Step 430: The querying party receives the query results fed back by the data party based on the query request.

[0163] In this embodiment of the invention, the query result indicates whether the user to be queried exists in the dataset. That is, the querying party determines whether the user to be queried exists in the dataset based on the query result, while the data provider cannot determine this, thereby ensuring the anonymity and security of the data.

[0164] In step 410, after receiving the query key, number of locations, and data length of the query table sent by the data provider, the querying party first encrypts the user identifier of the user to be queried according to the query key to obtain the ciphertext identifier.

[0165] The querying party encrypts the user identifier of the user to be queried in the same way as the data party encrypts the user identifier, as described above. The hash value is obtained by performing a hash operation using a hash function, and the hash value is used as the ciphertext identifier.

[0166] For example, if the user identifier of the user to be queried is d1, the ciphertext identifier d`1 = hash(d1|key). Here, d`1 represents the ciphertext identifier of the user to be queried, and hash(d1|key) represents the hash operation performed on the user identifier and the query key key.

[0167] After obtaining the encrypted identifier of the user to be queried, the querying party determines the query position corresponding to that encrypted identifier based on the number of positions. Specifically, for the i-th query position of the encrypted identifier, the querying party performs obfuscation calculations on the encrypted identifier based on the value of i to obtain an obfuscated identifier.

[0168] The obfuscation calculation is performed according to formula (1) above. The method for calculating the obfuscation identifier is the same as the method for calculating the obfuscation parameters above, so it will not be repeated here.

[0169] After obtaining the obfuscation identifier of the user to be queried, the querying party performs a modulo operation between the value of the obfuscation identifier and the data length of the query table to obtain the i-th query position of the user to be queried.

[0170] The modulo operation is performed according to the above formula (2). The specific method for calculating the i-th query position is the same as the method for calculating the i-th position of the ciphertext data in the query table, so it will not be elaborated here.

[0171] In summary, for any user identifier of a user to be queried, the querying party can obtain a number of query locations, and sends each query location as a query request to the data party. The data party then retrieves the value corresponding to the query location from the query table.

[0172] In step 430, after receiving the query results from the data provider based on the query request, the querying party determines whether the user to be queried exists in the dataset based on the query results.

[0173] Specifically, if the querying party determines that the values ​​corresponding to the query positions of the user to be queried in the query results are all preset values, then it determines that the user to be queried exists in the dataset.

[0174] For example, the query positions for the user d1 include d11, d12, ..., d17. If the values ​​corresponding to d11, d12, ..., d17 in the query results are all preset values, it means that the user d1 exists in the dataset.

[0175] If the querying party determines that the value corresponding to any query position of the user to be queried in the query results is not a preset value, then it determines that the user to be queried does not exist in the dataset.

[0176] For example, if the values ​​corresponding to d11, d12, ..., and / or d17 in the query results are not the preset values, it means that the user d1 to be queried does not exist in the dataset.

[0177] To better explain the above technical solution, Figure 5 An exemplary flowchart of a data query method is shown, which can be executed by a data query device.

[0178] like Figure 5 As shown, the process includes:

[0179] Step 510: Preprocess the dataset.

[0180] The data provider has multiple authorized user lists, including users such as Zhao Yi, Qian Er, Zhang San, and Zheng Yibaiwan. Among them, (Zhao Yi is on the whitelist), (Qian Er is on the blacklist), (Zhang San is on the whitelist), (Li Si is on the blacklist), ..., (Zheng Yibaiwan is on the blacklist).

[0181] The data provider preprocesses the authorized list, filtering out users with authorized whitelists to obtain a dataset containing the authorized whitelist. Dataset M includes users such as Zhao Yi and Zhang San. Described by user identifiers, dataset M = [id_1, id_2, ..., id_n-1, id_n]. Here, id_n represents the user identifier of users such as Zhao Yi and Zhang San. In this embodiment of the invention, n = 900,000 is used as an example.

[0182] Step 520: Construct the query table.

[0183] The data provider generates a 256-bit random number as the query key. Each user identifier in the dataset is then encrypted using this query key. For example, for any user identifier, id_n = hash(id_n|key). This results in the encrypted dataset M_n = [id_1, id_2, ..., id_n-1, id_n].

[0184] The data provider selects the number of positions k based on the number of n in the encrypted dataset M'. For example, if 500,000 ≤ n ≤ 1,000,000, k = 7.

[0185] To reduce the probability that any two encrypted data items will be in the same position in the lookup table, the number of positions is added to a preset redundancy value. For example, if the preset redundancy value is 1, the number of positions k = 7, and the sum of the number of positions and the preset redundancy value is 8.

[0186] The data provider calculates the data length of the lookup table based on the sum and the number of n in the encrypted dataset M'. For example, if n equals 900,000 and the sum equals 8, then the data length L of the lookup table equals 7,200,000.

[0187] For any given ciphertext data, calculate the k positions of that ciphertext data in the lookup table. For example, for the i-th position of the ciphertext data id`_n, perform obfuscation calculations on the ciphertext data id`_n based on the value of i to obtain the obfuscation parameter obs_Ri.

[0188] For example, if i = 3 and R = 4, then based on the following calculation process, the i-th obfuscation parameter obs_Ri of the ciphertext data id`_n is obtained.

[0189] obs_13 = hash(id`_n|3);

[0190] obs_23=hash(obs_13|id`_n|3);

[0191] obs_33=hash(obs_23|id`_n|3);

[0192] obs_43=hash(obs_33|id`_n|3).

[0193] Here, obs_43 is the i-th obfuscation parameter of the ciphertext data id`_n. The i-th obfuscation parameter of the ciphertext data id`_n is used to calculate the i-th position of the ciphertext data id`_n.

[0194] The data provider performs a modulo operation between the value of the i-th obfuscation parameter of the encrypted data id`_n and the data length L of the lookup table, obtaining P_ni = obs_43%L = 320,000; where P_ni is the number of bits at the i-th position of the encrypted data id`_n, obs_43 is the value of the i-th obfuscation parameter of id`_n, and L is the data length of the lookup table. This process is repeated for the (i+1)-th position of the encrypted data id`_n, for a total of k positions.

[0195] The data provider sets the values ​​at the k positions corresponding to the encrypted data id`_n in the query table to preset values. Based on the above... Figure 3 For example, let's modify the initial value of the 32nd bit in the lookup table to a preset value. If the 32nd bit in the lookup table is already a preset value, then no modification is needed, or you can add 1 to that preset value.

[0196] Similarly, the k positions of each encrypted data item are recorded in the lookup table to construct the lookup table.

[0197] Step 530: Send the query key, the number of locations, and the data length of the query table.

[0198] The data provider sends the query key, the number of locations, and the data length of the query table to the query provider so that the query provider can generate the query locations.

[0199] Step 540: Generate query location.

[0200] The querying party generates the query location for each user based on the user identifier of the user to be queried.

[0201] If the users to be queried include d1, d2, and d3; taking user d1 as an example, the querying party encrypts user d1 using the query key key. d1` = hash(d1`|key). This results in the query list D` = [d1`, d2`, d3`].

[0202] For any user to be queried, calculate the k query positions for that user. For example, for the i-th query position of the ciphertext identifier d1`, perform obfuscation calculation on the ciphertext identifier d1` based on the value of i to obtain the obfuscated identifier d_obs_Ri.

[0203] For example, if i = 2 and R = 4, then based on the following calculation process, the i-th obfuscated identifier d_obs_Ri of the ciphertext identifier d1` is obtained.

[0204] d_obs_12 = hash(d1`|2);

[0205] d_obs_22=hash(d_obs_13|d1`|2);

[0206] d_obs_32=hash(d_obs_23|d1`|2);

[0207] d_obs_42=hash(d_obs_33|d1`|2).

[0208] Where d_obs_42 is the i-th obfuscation parameter of the ciphertext identifier d1`. The i-th obfuscation parameter of the ciphertext identifier d1` is used to calculate the i-th query position of the ciphertext identifier d1`.

[0209] The querying party performs a modulo operation between the value of the i-th obfuscation parameter of the ciphertext identifier d1' and the data length L of the lookup table, obtaining d_P_i = d_obs_42 % L = 450,000; where d_P_i is the number of bits at the i-th query position of the ciphertext identifier d1', d_obs_42 is the value of the i-th obfuscation parameter of the ciphertext identifier d1', and L is the data length of the lookup table. This process is repeated for the (i+1)-th query position of the ciphertext identifier d1', resulting in a total of 7 query positions.

[0210] Then, the seven query positions of each ciphertext identifier (a total of 21 query positions) are used as query requests.

[0211] Step 550: Send a query request.

[0212] The querying party sends the query request to the value data party.

[0213] Step 560: Feedback on the query results.

[0214] After receiving the query request, the data provider iterates through the 21 query positions and retrieves the corresponding value from the query table. For example, the value corresponding to query position q1 is 1, the value corresponding to query position q2 is 0, ..., the value corresponding to query position q21 is 1, and so on.

[0215] The values ​​corresponding to each query position are used as query results and fed back to the querying party.

[0216] Step 570: Parse the query results.

[0217] After obtaining the query results, for any user to be queried, if the value at the query position corresponding to that user is a preset value, then it is determined that the user to be queried is recorded in the dataset. This allows for the differentiation of whether any one of multiple users to be queried is recorded in the dataset, improving the flexibility of data querying.

[0218] Based on the same technological concept Figure 6 An exemplary schematic diagram of a data query device provided in an embodiment of the present invention is shown, which can execute the flow of a data query method.

[0219] like Figure 6 As shown, the device specifically includes:

[0220] The receiving module 610 is used to receive a query request sent by the querying party; the query request includes the query location of the user to be queried;

[0221] The query module 620 is used to query the value corresponding to the query position in the query table to obtain the query result; the query table is constructed based on the user identifiers in the dataset; the value of each position in the query table is determined based on the position of the user identifier in the dataset in the query table, and the value corresponding to the query position in the query table indicates whether the query table records the user identifier of the user to be queried; the query result indicates whether the user to be queried corresponding to the query position exists or does not exist in the dataset;

[0222] The sending module 630 is used to send the query result to the querying party.

[0223] Optionally, the device further includes a construction module 640;

[0224] The construction module 640 is specifically used for:

[0225] Randomly generate query keys;

[0226] The user identifier is encrypted using the query key to obtain ciphertext data;

[0227] Calculate the data length of the query table based on the amount of encrypted data;

[0228] Calculate the position of the encrypted data in the query table, set a preset value for the position, and construct the query table.

[0229] Optionally, the building module 640 is specifically used for:

[0230] The number of positions is selected based on the amount of encrypted data; the number of positions represents the number of positions of any encrypted data in the lookup table; the number of positions is directly proportional to the amount of encrypted data.

[0231] Calculate the sum of the number of positions and the preset redundancy value;

[0232] The product of the number of encrypted data and the sum is used as the data length of the query table.

[0233] Optionally, the building module 640 is specifically used for:

[0234] For the ciphertext data at the i-th position in the query table, an obfuscation calculation is performed on the ciphertext data based on i to obtain obfuscation parameters;

[0235] The value of the obfuscation parameter is moduloed by the length of the data in the lookup table to obtain the i-th position of the ciphertext data in the lookup table.

[0236] Optionally, confusion calculations can be performed according to the following formula (1);

[0237] obs_Ri=hash(obs_(R-1)i|m|i) (1);

[0238] Where obs_Ri is the value of the obfuscation parameter; m is the ciphertext data; R is a positive integer, and 1≤R≤i; when R=1, obs_1i=hash(m|i).

[0239] Based on the same technological concept Figure 7 An exemplary schematic diagram of a data query device provided in an embodiment of the present invention is shown, which can execute the flow of a data query method.

[0240] like Figure 7 As shown, the device specifically includes:

[0241] The generation unit 710 is used to generate the query location of the user to be queried based on the user identifier, query key, number of locations, and data length of the query table; the query key, the number of locations, and the data length of the query table are sent by the data provider; the query table is constructed based on the user identifiers in the dataset; the value of each location in the query table is determined based on the position of the user identifier in the dataset in the query table, and the value corresponding to the query location in the query table indicates whether the query table records the user identifier of the user to be queried;

[0242] The sending unit 720 is used to send the query location of the user to be queried as a query request to the data provider; the query request is used to instruct the data provider to determine the value corresponding to the query location in the query table according to the query location, and obtain the query result;

[0243] The receiving unit 730 is used to receive the query result fed back by the data provider based on the query request; the query result indicates whether the user to be queried corresponding to the query position exists in the dataset.

[0244] Optionally, the generation unit 710 is specifically used for:

[0245] The user identifier of the user to be queried is encrypted using the query key to obtain the ciphertext identifier;

[0246] For the i-th query position of the ciphertext identifier, an obfuscation calculation is performed on the ciphertext identifier based on i to obtain an obfuscated identifier;

[0247] The i-th query position of the user to be queried is obtained by performing a modulo operation between the value of the obfuscation identifier and the data length of the query table.

[0248] Optionally, the device further includes a parsing unit 740;

[0249] The parsing unit 740 is used for:

[0250] After receiving the query results fed back by the data provider based on the query request, if it is determined that the values ​​corresponding to the query position of the user to be queried in the query results are all preset values, then it is determined that the user to be queried exists in the dataset.

[0251] If it is determined that the value corresponding to any query position of the user to be queried in the query results is not a preset value, then it is determined that the user to be queried does not exist in the dataset.

[0252] Based on the same technical concept, embodiments of the present invention also provide a computer device, including:

[0253] Memory, used to store program instructions;

[0254] The processor is used to call the program instructions stored in the memory and execute the above data query method according to the obtained program.

[0255] Based on the same technical concept, embodiments of the present invention also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described data query method.

[0256] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied 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.

[0257] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should 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, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0258] 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.

[0259] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus 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.

[0260] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A data query method, characterized in that, include: The data provider receives query requests sent by the querying party; The query request includes the query location of the user to be queried; The data provider retrieves the value corresponding to the query position from the query table to obtain the query result. The query table is constructed based on the user identifiers in the dataset; the value at each position in the query table is determined based on the position of the user identifier in the dataset in the query table, and the value corresponding to the query position in the query table indicates whether the query table records the user identifier of the user to be queried; The query result indicates whether the user to be queried corresponding to the query location exists or does not exist in the dataset; The data provider sends the query results to the query provider; The data provider constructs the query table based on user identifiers in the dataset, including: The data provider randomly generates a query key; The data provider encrypts the user identifier using the query key to obtain ciphertext data; The data provider calculates the data length of the query table based on the amount of encrypted data. The data provider calculates the position of the encrypted data in the query table, sets a preset value for the position, and constructs the query table. The data provider calculates the data length of the query table based on the amount of encrypted data, including: The data provider selects the number of positions based on the quantity of the encrypted data; the number of positions represents the number of positions of any encrypted data in the lookup table; the number of positions is directly proportional to the quantity of encrypted data. The data provider calculates the sum of the number of locations and a preset redundancy value; The data provider uses the product of the number of encrypted data and the sum as the data length of the query table.

2. The method as described in claim 1, characterized in that, The data provider calculates the position of the encrypted data in the query table, including: For the ciphertext data at the i-th position in the query table, the data provider performs obfuscation calculations on the ciphertext data based on i to obtain obfuscation parameters; The data provider performs a modulo operation between the value of the obfuscation parameter and the data length of the lookup table to obtain the i-th position of the ciphertext data in the lookup table.

3. The method as described in claim 2, characterized in that, The confusion calculation is performed according to the following formula (1); （1）； in, Let m be the value of the obfuscation parameter; m be the ciphertext data; R be a positive integer, and 1 ≤ R ≤ i; when R = 1, R represents the number of times the ciphertext data is obfuscated.

4. A data query method, characterized in that, include: The querying party generates the query location of the user to be queried based on the user identifier, query key, number of locations, and data length of the query table; The query key, the number of locations, and the data length of the query table are sent by the data provider; the value of each location in the query table is determined based on the position of the user identifier in the dataset within the query table, and the value corresponding to the query location in the query table indicates whether the query table records the user identifier of the user to be queried; the query table is constructed by the data provider based on the user identifiers in the dataset, and the value in the query table represents the user identifier recorded in the dataset; the query table is generated by the data provider using a randomly generated query key. The user identifier is encrypted using the query key to obtain ciphertext data; the number of positions is selected based on the quantity of the ciphertext data; the number of positions represents the number of positions of any ciphertext data in the query table. The number of positions is proportional to the number of ciphertext data; calculate the sum of the number of positions and a preset redundancy value; use the product of the number of ciphertext data and the sum as the data length of the lookup table to calculate the position of the ciphertext data in the lookup table, and set a preset value for the position to construct the lookup table; The querying party uses the query location of the user to be queried as a query request and sends the query request to the data party; The query request is used to instruct the data provider to determine the value corresponding to the query position in the query table based on the query position, and to obtain the query result; The querying party receives the query results returned by the data party based on the query request; The query result indicates whether the user to be queried corresponding to the query location exists in the dataset.

5. The method as described in claim 4, characterized in that, The querying party generates the query location of the user to be queried based on the user identifier, query key, number of locations, and data length of the query table, including: The querying party encrypts the user identifier of the user to be queried according to the query key to obtain the ciphertext identifier; For the i-th query position of the ciphertext identifier, the querying party performs obfuscation calculation on the ciphertext identifier based on i to obtain an obfuscated identifier; The querying party performs a modulo operation between the value of the obfuscation identifier and the data length of the query table to obtain the i-th query position of the user to be queried.

6. The method as described in claim 4, characterized in that, After the querying party receives the query results returned by the data party based on the query request, it also includes: If the querying party determines that the values ​​corresponding to the query positions of the user to be queried in the query results are all preset values, then it determines that the user to be queried exists in the dataset; If the querying party determines that the value corresponding to any query position of the user to be queried in the query results is not a preset value, then it determines that the user to be queried does not exist in the dataset.

7. A data query device, characterized in that, include: The receiving module is used to receive query requests sent by the querying party; The query request includes the query location of the user to be queried; The query module is used to retrieve the value corresponding to the query position from the query table and obtain the query result; The query table is constructed by the data provider based on the user identifiers in the dataset. The value at each position in the query table is determined by the data provider based on the position of the user identifier in the dataset in the query table. The value corresponding to the query position in the query table indicates whether the query table records the user identifier of the user to be queried. The query result indicates whether the user to be queried corresponding to the query location exists or does not exist in the dataset; The sending module is used to send the query results to the querying party; The query module is specifically used to randomly generate query keys; The user identifier is encrypted using the query key to obtain ciphertext data; the data length of the query table is calculated based on the amount of ciphertext data. Calculate the position of the encrypted data in the query table, set a preset value for the position, and construct the query table; The query module is specifically used to select the number of positions based on the number of encrypted data; the number of positions represents the number of positions of any encrypted data in the query table; the number of positions is proportional to the number of encrypted data; calculate the sum of the number of positions and a preset redundancy value; and use the product of the number of encrypted data and the sum as the data length of the query table.

8. A data query device, characterized in that, include: The generation unit is used to generate the query location of the user to be queried based on the user identifier, query key, number of locations and data length of the query table of the user to be queried; The query key, the number of locations, and the data length of the query table are sent by the data provider; the value of each location in the query table is determined by the data provider based on the location of the user identifier in the dataset within the query table, and the value corresponding to the query location in the query table indicates whether the query table records the user identifier of the user to be queried; the query table is constructed by the data provider based on the user identifiers in the dataset, and the value in the query table represents the user identifier recorded in the dataset; the query table is generated by the data provider using a randomly generated query key. The user identifier is encrypted using the query key to obtain ciphertext data; the number of positions is selected based on the quantity of the ciphertext data; the number of positions represents the number of positions of any ciphertext data in the query table. The number of positions is proportional to the number of ciphertext data; calculate the sum of the number of positions and a preset redundancy value; use the product of the number of ciphertext data and the sum as the data length of the lookup table to calculate the position of the ciphertext data in the lookup table, and set a preset value for the position to construct the lookup table; The sending unit is used to send the query request, which is the query location of the user to be queried, to the data provider. The query request is used to instruct the data provider to determine the value corresponding to the query position in the query table based on the query position, and to obtain the query result; A receiving unit is configured to receive the query results returned by the data provider based on the query request; The query result indicates whether the user to be queried corresponding to the query location exists in the dataset.

Images