Privacy information intersection method and computing device

Abstract

The embodiment of the present specification provides a method and a computing device for privacy information intersection. In the process of privacy information intersection between two participants, one party performs cuckoo hashing bucketing, and one bucket corresponds to at most one piece of data. The other party performs simple hashing, and each hash value corresponding to one piece of data participates in the bucketing. The party with simple hashing constructs a data pair by using each hash value, a bucket identifier and data fragments to form bucket information. Then, the other party performs interpolation query based on the OPPRF protocol by using the hash value of the cuckoo hashing, so as to obtain the bucket information formed by the bucket identifier and the data fragments. In this way, the party with simple hashing can deliver data for joint data processing without obtaining any intersection. The privacy information intersection with conditional or incidental data processing in the two-party secure computing scenario provides an effective solution.

Description

Technical Field

[0001] This specification relates to the field of secure computing technology, and more particularly to a method and computing device for intersecting privacy information. Background Technology

[0002] Secure multi-party computation, also known as secure multi-party computation, involves multiple parties collaboratively computing the result of a function without revealing their input data. The result is disclosed to one or more parties. A typical application of secure multi-party computation is securely processing intersection data. Securely determining the intersection data, also known as Private Set Intersection (PSI) or credential stuffing, can be understood as determining the intersection of data between multiple parties while protecting privacy. PSI can be used for multi-party collaborative training of machine learning algorithms, data analysis, querying, and other business applications. The core idea of ​​PSI is that at the end of the protocol interaction, one or more parties obtain the correct intersection without obtaining any other data from the other parties' data sets outside the intersection.

[0003] Conventional privacy-preserving intersection methods typically determine the intersection of identical data identifiers separately, and then perform further data processing based on the intersection result. However, in practice, privacy-preserving intersection methods often involve conditions, and these conditions often involve data from multiple parties. For example, to determine a group of people whose average monthly expenditure S1 is less than their monthly income S2, where S1 is held by a first financial institution and S2 by a second financial institution, and the result is obtained by the second financial institution without being disclosed to the first financial institution. In this case, performing a privacy-preserving intersection method first to determine the user intersection, and then comparing the average monthly expenditure S1 and monthly income S2, makes it difficult to achieve the goal of not disclosing the user intersection to the first financial institution. Therefore, how to perform privacy-preserving intersection methods with conditions or additional data processing is an important technical problem worthy of research in multi-party secure computation scenarios. Summary of the Invention

[0004] This specification describes one or more embodiments of a method and computing device for finding intersections of privacy information, in order to solve one or more problems mentioned in the background art.

[0005] According to the first aspect, a privacy information intersection method is provided, comprising: a first party using a cuckoo hashing bucketing algorithm to distribute n first data identifiers corresponding to n first hash values ​​into B buckets based on multiple hash functions, wherein the n first data identifiers correspond to n local first data, B is greater than n, and a single bucket corresponds to at most a single first hash value; a second party using the multiple hash functions to bucket t second data identifiers corresponding to t second data based on a simple hashing method, distributing the multiple second hash values ​​corresponding to the t second data identifiers into B buckets, wherein a single second data identifier corresponds to a second hash value determined based on each hash function; and the second party constructing data pairs based on the second bucket information corresponding to each second hash value, wherein the second bucket information includes a bucket label. The first party identifies the first fragment of the second data corresponding to the corresponding second hash value, and the second fragment of each second data is retained by the second party. Second data with the same bucket identifier have the same second fragment. The first party and the second party execute a programmable pseudo-random function protocol based on each first hash value of the first party and each data pair of the second party, so that the first party obtains the first bucket information corresponding to each first hash value. In the case that a single first hash value is equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value is consistent with the second bucket information corresponding to the any second hash value. The first party and the second party determine the intersection of the n first data and the t second data based on the first party's first bucket information, the second party's second bucket information, and the second fragment of each second data.

[0006] According to the second aspect, a privacy information intersection method is provided for joint privacy intersection by a first party and a second party. The method is executed by the first party and includes: bucketing n first data identifiers corresponding to n first data using multiple hash functions based on a cuckoo hashing method; distributing the n first hash values ​​corresponding to the n first data identifiers into B buckets, where B is greater than n, and a single bucket corresponds to at most a single first hash value; executing a programmable pseudo-random function protocol based on each first hash value and the second party; and obtaining the first bucket information corresponding to each first hash value based on each data pair constructed by the second party. Each data pair corresponds to a second hash value and a corresponding second bucket identifier, and the second bucket identifier corresponding to a single second hash value is determined by the second party using the multiple hash functions. The hash function determines the t second data identifiers corresponding to t second data items by dividing them into B buckets based on a simple hash method. A single second hash value is determined by hashing a single second data identifier during the bucketing process. The second bucket information includes the bucket identifier and the first fragment of the second data item corresponding to the corresponding second hash value. The second fragments of each second data item are retained by the second party. Second data items with the same bucket identifier have the same second fragment. If a single first hash value is equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value is consistent with the second bucket information corresponding to any second hash value. Based on each first bucket information, a secure calculation is performed with the second party to determine the intersection of the n first data items and the t second data items.

[0007] According to a third aspect, a privacy information intersection method is provided for joint privacy intersection by a first party and a second party. The method is executed by the second party and includes: bucketing t second data corresponding to t second data using the plurality of hash functions based on a simple hashing method; distributing the plurality of second hash values ​​corresponding to the t second data identifiers into B buckets; each second data identifier corresponding to a second hash value determined based on each hash function; constructing data pairs based on the second bucket information corresponding to each second hash value, wherein the second bucket information includes a bucket identifier and a first fragment of the second data corresponding to the corresponding second hash value; the second fragments of each second data are retained by the second party; second data with the same bucket identifier have the same second fragment; based on... Each data pair, together with the first party, executes a programmable pseudo-random function protocol, enabling the first party to obtain the first bucket information corresponding to each first hash value. Each first hash value is determined by the first party through hash calculations using multiple hash functions to divide the n first data identifiers corresponding to the n first data into B buckets based on the cuckoo hash method, where B is greater than n. A single bucket corresponds to at most a single first hash value. If a single first hash value is equal to any second hash value from the second party, the first bucket information corresponding to that single first hash value is consistent with the second bucket information corresponding to that second hash value. Based on the second bucket information and the second fragments of each second data item, a secure calculation is performed with the first party to determine the intersection of the n first data items and the t second data items.

[0008] According to a fourth aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of the second or third aspect.

[0009] According to a fifth aspect, a computing device is provided, including a memory and a processor, characterized in that the memory stores executable code, and when the processor executes the executable code, it implements the method of the second or third aspect.

[0010] Using the method and computing device provided in the embodiments of this specification, during the intersection process of privacy information, the first party and the second party perform additional business processing based on the intersection data, and the intersection information is not disclosed to the second party. Assuming the first party holds multiple pieces of first data and the second party holds multiple pieces of second data, the first party performs a cuckoo hash, where a single bucket corresponds to at most one first hash value of the data identifier corresponding to one piece of first data. The second party performs a simple hash (or ordinary hash) and maps the data to the corresponding buckets, where a single bucket can correspond to the second hash values ​​of the data identifiers of several pieces of second data. Thus, when the first data corresponding to a single bucket of the first party is intersection data, its corresponding first hash value will necessarily be matched by a second hash value corresponding to the corresponding bucket of the second party. Based on this, the second party constructs data pairs using the second bucket information corresponding to each second hash value. The second bucket information includes a bucket identifier and the first fragment of the corresponding second data. The second fragments of the second data corresponding to a single bucket are stored locally in the same manner. The first party uses the first hash value to execute a programmable pseudo-random protocol with the second party, allowing the first party to fit the first bucket information corresponding to each first hash value. A single piece of first bucket information can identify the corresponding bucket identifier and the second data fragment (distinguished from the first and second fragments of the second data). Therefore, regardless of which second hash value in the same bucket identifier of the second party is matched by the first party's first hash value for a single bucket, the first fragment of the corresponding second data (i.e., the identified second data fragment) is identified. Furthermore, the second party can provide the second fragment of the corresponding second data even if it does not know which second data is matched. Subsequently, the first and second parties can perform data processing on their intersection, such as conditional processing and fusion processing.

[0011] In this way, the intersection result can be obtained by the party acting as the result (such as the first party) without disclosing any intersection information to the other party, effectively solving the problem of intersection of privacy information in the context of data processing. Furthermore, even if both parties are result parties, the intersection and data processing processes can be combined to improve the efficiency of intersection of privacy information in the context of data processing. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the 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.

[0013] Figure 1 This is a schematic diagram illustrating a specific implementation scenario for requesting intersections of private information.

[0014] Figure 2 This diagram illustrates the two-way interaction sequence of privacy information intersection under the technical concept of this specification.

[0015] Figure 3 This is a diagram illustrating the bucketing of two-way data and the construction of indexed ciphertext based on a specific example;

[0016] Figure 4 A flowchart illustrating a method for obtaining intersection information by one party in the privacy information intersection process according to an embodiment of this specification is provided.

[0017] Figure 5 A flowchart is shown illustrating a method for finding intersection of privacy information performed by a party that is unable to obtain intersection information during the privacy information intersection process according to an embodiment of this specification.

[0018] Figure 6 The diagram shows the interaction sequence of two rooms performing privacy information intersection in a specific example. Detailed Implementation

[0019] First, let's clarify some technical terms that may be used in this instruction manual:

[0020] Cuckoo hash is a method for resolving hash collisions. Its purpose is to improve the utilization of hash tables using simple hash functions while ensuring a lookup efficiency of O(1). The basic idea is to use multiple (e.g., 2) hash functions to handle collisions, so that each value can correspond to multiple (e.g., 2) possible positions.

[0021] Taking the use of two hash functions as an example, let's denote the two hash functions as h1 and h2, and their corresponding hash buckets as T1 and T2, respectively. When inserting element x, calculate two hash values ​​h1(x) and h2(x). The position of h1(x) in hash bucket T1 is denoted as T1[h1(x)], and the position of h2(x) in hash bucket T2 is denoted as T2[h2(x)]. If either position T1[h1(x)] or T2[h2(x)] is empty, insert the corresponding hash value into that empty position; if both positions are empty, arbitrarily choose one to insert. If both T1[h1(x)] and T2[h2(x)] are full (already containing hash values ​​of other values), arbitrarily choose one (e.g., the position corresponding to element y), remove it, and insert the hash value of x. Repeat the above process to insert the hash value of element y. If too many data insertions are ejected, the hash bucket is considered full. Further processing, such as resizing or rehashing, can be used to insert hash values ​​again.

[0022] When querying element x, you can read the hash values ​​at positions T1[h1(x)] and T2[h2(x)] and compare them with the corresponding hash values ​​of x.

[0023] A Boolean circuit is a set of logic gates connected by wires that can perform function calculations on a set of inputs and output the result. Logic gates include AND gates, XOR gates, NOT gates, etc., which implement Boolean functions. Typically, a function can be compiled into a set of AND gates, XOR gates, and NOT gates to perform the calculation.

[0024] The Goldreich-Micali-Wigderson (GMW) secure multi-party computation protocol is a semi-honest protocol that employs a Boolean circuit-based secret-sharing mechanism, specifically additive secret sharing. In a two-party secure computation scenario, assuming two participants are P1 and P2, each holding 1 bit of secret x and y. A function F(x, y) to be computed corresponds to a Boolean circuit 𝐶. Participant P1 randomly selects a bit, such as r1, and calculates x⊕ r1, where ⊕ represents an XOR operation. Then, r1 is sent to participant P2. Similarly, P2 performs a similar operation, selecting a random bitmask r2, XORing it with its own secret y, and using the result y⊕ r2 as the new secret. Simultaneously, the selected random bitmask r2 is sent to participant P1. After the above process, the two participants, P1 and P2, have essentially shared a secret with each other. Only by simultaneously obtaining both participant P1's secret share x⊕r1 and participant P1's own secret share r1 can the secret bit x be recovered. Next, the Boolean circuit C is executed, evaluating each gate in the Boolean circuit until the calculation of the entire circuit is completed.

[0025] The principles of multi-party secure computation for each gate are as follows: NOT gate computation: Since the NOT gate has a single input, P1 and P2 do not need to interact; therefore, the input can be directly inverted. XOR gate computation: P1 calculates w1 = (x⊕r1)⊕r2, P2 calculates w2 = (y⊕r2)⊕r1, then w1⊕w2=x⊕y. AND gate computation: Requires a 4-to-1 oblivious transfer (OT) protocol. The NOT and XOR gates can be executed locally, while the AND gate requires communication between the two participating parties.

[0026] OT (Operational Technology) protocol: This protocol operates between the Sender and the Receiver. The Sender has several tags (two or more). The Receiver selects from these tags. After OT execution, the Receiver receives its selected tag but not the others. The Sender does not know the Receiver's selected tag. To illustrate the difference in function between the two parties during OT protocol execution, we will refer to them as the Sender and the Receiver. In actual business execution, either party can act as either the Sender or the Receiver.

[0027] Pseudorandom Function (PRF): For an n-bit bit string {0, 1}... n Mapped to an n-bit string {0, 1} n A random function f is a function selected from F by uniform random sampling, consisting of all functions in the family F. rnd ∈F. In this family of functions, a function is equivalent to giving a 2 n The size of the entire family of functions is the permutation of n-bit strings. This is an exponentially large computational scale, so even an attacker with polynomial-level resources could not model the mapping of a random function f in polynomial time. For a class of keyed functions F, we have F:{0,1} ∗ ×{0, 1} ∗ →{0,1} ∗ That is, y←F(k,x), where x is the input, k is the key, and y is the output. If F represents the PRF process, then the following conditions must be met: efficient computation: given k and x, there exists an efficient polynomial-time algorithm that can compute y=F(k,x); indistinguishable: with a randomly selected key k, the pseudo-random function F(k,⋅) and a random function f(⋅) are indistinguishable; length preserved: the lengths of y, x, and k are all n.

[0028] Unintentional Pseudorandom Function (OPRF): The receiver has some inputs denoted as a set {x}. i The sender has a key, and under the OPRF protocol, the receiver can send one of its inputs x. i The key of the sender is combined with a series of secure operations to transform it into the corresponding number F(key, x). i (e.g., F(key, x)) i ) as a key to x iThe encrypted result (F(key, x)) is obtained by the Receiver. The Receiver does not know the Sender's key, and the Sender does not know F(key, x) i Each input x i Each of these can calculate a number that is different from the other inputs; these numbers can be considered pseudo-random numbers.

[0029] Programmable pseudo-random function: Oblivious Programmable Pseudorandom Function (OPPRF) is a special extension of OPRF. In the OPPRF protocol, the sender can determine the output value of the PRF (Pseudorandom Function). The receiver has n data X = {x1, ..., x...} n The sender has m data pairs (denoted as key-value pairs, or KV for short, which can also be understood as two-dimensional coordinates). The set of m data pairs can be denoted as: KV = {(x1, y1), ..., (x...} m y m The Sender takes key-value pairs as input, and the Receiver takes x... i As input, both parties execute the OPPRF protocol. The sender can fit a polynomial based on the key-value pair and provide the polynomial coefficients to the receiver. The receiver then uses the polynomial interpolation to output x. i Corresponding y i '(Also known as valuation). If x i If it exists in a KV (key-value pair), then y is output using polynomial interpolation. i 'There are m data pairs with corresponding y' i Otherwise, it is an invalid random number.

[0030] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0031] Figure 1 This diagram illustrates a specific scenario involving the intersection of privacy-preserving information. Figure 1 The scenario shown involves two parties: a data platform and a client. The client can be understood as a user who can interact with the data platform and receive data support from it.

[0032] like Figure 1As shown, the client has several local data tables, one of which is an employee basic information data table, including multiple user IDs (such as identity identification numbers or mobile phone numbers) such as User 1, User 2, and User 3. Each user can correspond to multiple attribute items (or characteristic items), such as monthly income, length of service, etc. Assume the data platform has multiple data tables, one of which displays multiple user IDs (here, it is assumed that its user IDs are described in the same way as the client's user IDs, such as identity identification numbers or mobile phone numbers), and holds multiple attribute items for each user, such as savings amount, length of service, average monthly expenditure, etc.

[0033] Figure 1 The client shown can query the data platform for users who meet certain conditions, such as those whose length of service and seniority are the same, and whose average monthly expenditure is less than their monthly income. However, the client is unwilling to disclose private information from its local data tables to the data platform. This private information includes, for example, the user ID and at least one of the various attribute items. Therefore, the client needs to securely interact with the data platform to determine the intersection of conditions, such as "length of service and seniority are the same, and average monthly expenditure is less than monthly income." Let the length of service be t1, seniority be t2, average monthly expenditure be S1, and monthly income be S2. The predetermined condition can be denoted as "t1=t2, and S1<S2". That is, filtering for users who meet the predetermined condition "t1=t2, and S1<S2". This is a scenario of finding the intersection of conditional private information.

[0034] Depending on business needs, the intersection data that meets the conditions can be obtained by the client, or it can be constructed and shared between the data platform and the client; no specific limitation is made here. In short, when the data platform cannot obtain the intersection results, it becomes difficult to use the attached conditions for intersecting user selection.

[0035] Understandable Figure 1 This is just one example; in practice, there are many other similar business scenarios, varying in the number of clients and data platforms, and user identifiers can be other data identifiers. The business processes are not limited to filtering users who meet certain criteria. As another example, it could involve using client and data platform data to perform user scoring or other data fusion operations, which will not be elaborated upon here.

[0036] Alternatively, the two parties may not have a service relationship between a client and a data platform, but rather a normal cooperative relationship. For example, in scenarios such as PSI-based user segmentation, one participant (such as a client) holds user IDs (such as identity codes, phone numbers, etc.) and multiple attributes R1, R2, and R3, while another participant (such as a data platform) holds user IDs (similarly, such as identity codes, phone numbers, etc.) and multiple attributes S1, S2, and S3. The platform needs to obtain privacy information that satisfies predetermined conditions such as R1 < S1 and R2 > S2, or R3 = S3, and perform intersection queries, etc.

[0037] In scenarios involving secure business processing using intersection data, conventional technologies typically employ data identifiers for privacy-preserving intersection calculations, with the result party obtaining the intersection data information. However, selecting data for joint data processing or conditional judgment based on the intersection data information may leak the intersection information to the other party. Therefore, how to securely process intersection data with minimal computation and communication overhead, such as filtering intersection data that meets predetermined conditions, without disclosing intersection information to the other party, is a technical problem worthy of research.

[0038] In view of this, this specification provides a technical solution for privacy information intersection, which can be used by one party providing data (such as...) Figure 1 This refers to the ability of data platforms to effectively and securely process (including data fusion) or filter (through conditional judgment) overlapping data even when the data platform is unaware of the overlapping data. For details, please refer to [link / reference]. Figure 2 As shown.

[0039] Figure 2 This document illustrates an interaction timing diagram of a two-party privacy information intersection process according to an embodiment of this specification. Figure 2 In the example shown, the two parties are respectively denoted as the first party (e.g., Figure 1 (client in) and second-party (such as) Figure 1 In a data platform context, the data corresponding to the first party can be denoted as "first data," and the data corresponding to the second party can be denoted as "second data." The data identifier corresponding to the first data can be denoted as "first data identifier," and the data identifier corresponding to the second data can be denoted as "second data identifier." A data identifier is a symbol, text, etc., used to identify data and is usually unique. The first party and the second party can use the same data identifier; for example, the user identifier corresponding to user data could be an identity verification number, mobile phone number, etc. If the first party corresponds to n pieces of first data, denoted as D... x ={d x1 d x2 ...d xn The corresponding n first data identifiers are denoted as X = {x1, x2, ..., xn}. n The second party corresponds to t second data items, denoted as D. y={d y1 d y2 ...d yt The corresponding t second data identifiers are denoted as Y = {y1, y2, ..., y3}. t}

[0040] It is understandable that a single data identifier can correspond to one or more data items, and these data items together constitute a single data entry. For example, a single data entry d... xi d yi This involves concatenating the numerical values ​​of various data items. Privacy information intersection can encompass various business processes performed on the intersection data of two parties, such as using the data to rate users in the intersection, or filtering users from the intersection who meet predetermined conditions. Taking filtering users from the intersection who meet predetermined conditions as an example, these conditions could be, for instance, conditions describing the size relationship between data items (attribute items) in the two sets of data. This size relationship can be determined by comparing the numerical values ​​of the corresponding data items.

[0041] exist Figure 2 In the example shown, referring to protocols such as OPRF and OPPRF, one of the first and second parties can be designated as the sender, and the other as the receiver. As an example, assume the second party is the sender, for example... Figure 1 In the data platform, the first party is the receiver, for example, the data platform provider. Figure 1 The client side in this specification. It's worth noting that, since the technical concept in this specification is based on the OPPRF protocol, the sender provides key-value (KV) data pairs. In each KV data pair, the first data is the index (Key, also known as the key-value pair), and the second data is the value (Value). Under the technical concept of this specification, the index is constructed using the hash value of the data identifier.

[0042] refer to Figure 2 As shown, the steps in the interactive process of securely processing the intersection data between the first and second parties are described in detail below.

[0043] In step 201, the first party uses the Cuckoo Hash Bucket Algorithm to distribute the n first hash values ​​corresponding to the n first data identifiers into B buckets based on multiple hash functions, with the n first data identifiers corresponding to the n first data respectively.

[0044] Understandably, to determine the intersection, both the first and second parties can have agreed-upon data identifiers, such as user identification numbers, mobile phone numbers, etc. To determine the intersection while protecting data privacy, hash values ​​of the data identifiers can be used, and data can be bucketed based on these hash values. The first party uses a cuckoo hashing method for data bucketing, ensuring that the number of first data entries corresponding to a single bucket is no greater than 1. Thus, the number of buckets B can be greater than or equal to the number of first data entries n. To avoid revealing the number of first data entries n and to ensure the smooth operation of bucketing, B is typically greater than n.

[0045] Bucketing using the Cuckoo Hash method requires calculating hash values ​​for each first data identifier using multiple predefined hash functions. These hash functions can be at least one of the following: MD2, MD4, MD5, SHA1, SHA224, SHA256, SHA384, SHA512, SHA3-224, SHA3, etc. Bucketing is typically performed based on hash values. In a common bucketing method, assuming the number of buckets is B, the remainder obtained by taking the hash value modulo B corresponds to the appropriate bucket. For example, if the first bucket is identified as A1, then if the remainder of the hash value of the data identifier modulo B is 1, it corresponds to the bucket with identifier A1.

[0046] According to the principle of Cuckoo Hash, the number of hash functions is defined as c, such as h1, h2, ..., hc. For a single first data identifier, c hash values ​​can be calculated, and each of the c hash values ​​is mapped to B buckets. If at least one of the mapped buckets is empty, the first data identifier is mapped to one of the empty buckets, and the corresponding hash value is recorded as the first hash value of that single data identifier. If all buckets are occupied, one is randomly kicked out for mapping. The kicked-out first data identifier can be mapped to other buckets using other hash functions. Ultimately, each first data identifier is mapped to a bucket through one of the c hash values, ensuring that a single bucket corresponds to at most one first data identifier. The hash value used for mapping to the bucket can be recorded as the first hash value. In the case of redundant buckets, empty buckets can be filled with random strings to mask the privacy of data bucketing. Optionally, B can be determined according to a predetermined multiple of n, such as B=1.2n, B=1.5n, etc.

[0047] Step 202: The second party uses multiple hash functions based on a simple hash method to bucket the t second data corresponding to the t second data, and then distributes the multiple second hash values ​​corresponding to the t second data to B buckets.

[0048] Here, the simple hashing method refers to the bucketing method that uses simple hash calculation. It means calculating hash values ​​using hash functions and then bucketing the data according to these hash values. When there are multiple hash functions, for a single second data identifier, multiple hash functions are used to calculate the corresponding hash values, and each hash value is mapped to one of B buckets, thus bucketing the hash values.

[0049] The second party has the same number of buckets as the first party, both being B. The second party uses c hash functions (the same hash functions used in the first party for the Cuckoo Hash algorithm) to hash each local data identifier and then buckets the data according to the resulting hash values. Assuming the number of second data entries in the second party is denoted as t, the second party can obtain c×t hash values, all of which can be called second hash values. A single second data entry can correspond to c second hash values. These c×t second hash values ​​can be bucketed using a modulo-B method, meaning the corresponding second data entry corresponds to the bucket corresponding to the remainder of the second hash value modulo B. The number of data entries corresponding to a single bucket in the second party could be 0, 1, 2, etc.

[0050] It is understandable that after bucketing, a single piece of second data in the second party can be mapped to at most c buckets (multiple hash values ​​of the same data identifier may also correspond to the same bucket, so the number of buckets mapped may be less than c). Since the hash functions of a single second data identifier bucket (c) are more than the hash function of the first data identifier bucket (1), and the hash function of a single second data identifier bucket includes the same hash function as the first data identifier bucket, when a single piece of second data is the intersection of data with the first data, its corresponding bucket identifiers will necessarily match the bucket identifiers corresponding to the corresponding first data in the first party. On the other hand, when the data corresponding to a single bucket in the first party is the intersection of data, the hash value of its data identifier will necessarily be one of the hash values ​​corresponding to the bucket identifier in the second party.

[0051] refer to Figure 3 As shown, assume the first party (Receiver) holds n=4 data items, with the corresponding first data identifiers denoted as id0, id1, id2, and id3. The second party (Sender) also holds t=4 data items, with the corresponding second data identifiers denoted as id0, id1, id4, and id5. The number of buckets is B=6, and each bucket is labeled with bucket identifiers bin0 to bin5. The number of hash functions is c=3.

[0052] The first party performs a Cuckoo Hash calculation, assigning the four first data entries to n=4 buckets (or mapping data identifiers to bucket identifiers). The other two buckets are empty. Each non-empty bucket corresponds to a first hash value. Empty buckets can be represented by a random string "$", as shown in Table 301. The second party performs a simple hash calculation, assigning c×t=12 second hash values ​​corresponding to the four data entries to 6 buckets. Figure 3 In the example, it is assumed that id5 has two second hash values ​​that are assigned to the same bucket. Therefore, among the 6 buckets, the second data identifier id5 corresponds to 2 buckets, and the other second data identifiers correspond to 3 buckets, as shown in Table 302.

[0053] Taking id1 as an example, in the first party, it is assigned to the bucket labeled "bin4" using the Cuckoo Hash algorithm. In the second party, it is assigned to three buckets labeled "bin1", "bin3", and "bin4" using the Simple Hash algorithm. Both parties assign the hash value of id1 to the bucket labeled "bin4" using the same hash function, resulting in identical hash values. In other words, if the data identifier id1 corresponding to a single bucket in the first party is an intersection of data, its hash value must be one of the hash values ​​corresponding to the corresponding bucket identifiers in the second party (corresponding to the same hash function). Therefore, the bucket identifiers "bin1", "bin3", and "bin4" corresponding to the hash value of id1 in the second party must match the bucket identifier "bin4" corresponding to the hash value of id1 in the first party.

[0054] Step 203: The second party constructs data pairs based on the second bucket information corresponding to each second hash value.

[0055] Based on the technical concept of this specification, when the bucket identifier is used as the Value in the OPPRF protocol, if the data identifiers of the two parties are the same, then the first hash value of the first party must be the same as a second hash value of the same bucket of the second party, that is, the bucket identifiers corresponding to the two parties must be the same, so the intersection can be determined by comparing the bucket identifiers.

[0056] In this context, the bucket identifier used to construct the data pair can be a string that uniquely identifies one of the m buckets. It can be generated randomly or according to a predetermined rule; no restriction is placed here. Each bucket identifier uniquely corresponds to a single bucket, and different buckets correspond to different strings. For example, the bucket identifier for the i-th bucket might be a random string r. bi express.

[0057] Here, the purpose of the second party constructing the data pair is for the first and second parties to execute the OPPRF protocol. The second party provides an index (Key) based on a second hash value and a value containing bucket identifiers. The first party constructs a query using the first hash value to obtain the respective bucket identifiers. Under the technical concept of this specification, it is desirable to transmit data fragments along with the bucket identifiers. Therefore, data pairs can be constructed using second bucket information containing bucket identifiers. The second bucket information includes the bucket identifier and the first fragment of the second data corresponding to the corresponding second hash value. The second fragment of each piece of second data is retained by the second party.

[0058] Specifically, the index item in the data pair can be determined based on the second hash value. This can be the second hash value itself or the ciphertext of the second hash value. The second party can encrypt the second hash value using a local key kb. In one embodiment, each bucket can correspond to the same second-party encryption key, such as kb, meaning the hash value corresponding to each bucket identifier is encrypted using the same encryption key. In another embodiment, to prevent the same encryption key from leaking data information, each bucket can correspond to different second-party encryption keys, such as kb1, kb2, ..., kbB. Thus, the corresponding second hash values ​​can be encrypted using the encryption key corresponding to a single bucket, forming the ciphertext of the second hash value. Optionally, the encryption keys kb1, kb2, ..., kbB can be random keys generated using the same key seed.

[0059] The Value constructed by the second party can be second bucket information containing bucket identifiers. For a single second hash value, the second bucket information can include the corresponding bucket identifier and a fragment of the corresponding second data, denoted as the first fragment of the second data. The other fragment of the second data, denoted as the second fragment, is split and retained by the second party. Considering that a single bucket can hit at most a single first hash value, second data with the same bucket identifier can have the same second fragment. Thus, regardless of which second hash value hits the corresponding first hash value, the second data fragment can be used for secure computation of the data.

[0060] As an example, the numerical value Split into two shards and ,in, Theoretically, for the generated random numbers, or All of these can be used as the first fragment of the second data disclosed to the first party. However, considering the various... As the first shard of the data, each piece of second data has a different second shard retained by the second party. Without disclosing the data intersection, this is detrimental to pre-defined business processing. Therefore, in some optional implementations, the second party can set each piece of second data corresponding to the same bucket to have the same random number shard, for example, using... As a shared second shard for all the second data corresponding to bucket b, it can be used as the second value corresponding to bucket b. The second fragment is stored locally, and the i-th data... Another fragment Can be used as a numerical value The first segment is used for the bucket identifier. b Construct data pairs together. As a concrete example, the b-th bucket corresponds to any data d. bi In a data pair, the value could be, for example, r. bi ||( ). "||" indicates splicing.

[0061] Thus, since the second data in the same bucket has the same data shards in the second party. (This instruction refers to the second shard.) The second party retains B second shards of the second data. Regardless of which second hash value corresponding to a single bucket of the second party matches the first hash value corresponding to the corresponding bucket of the first party, a valid first shard of the second data can be obtained from the pseudo-random number obtained by the first party via the OPPRF protocol. This valid data shard and the second shards retained by the second party constitute a shared form of the corresponding second data, and the second party cannot know which data match the first party's data. In this way, secure business processing can be performed based on the shared data, which reduces the amount of data processing and effectively protects the privacy of the intersection data.

[0062] Additionally, it's worth noting that in some business processing scenarios, only a portion of the data items in the second data set may be used. For example, if the condition is a specific field in the data table or a specific information item in the user information, then the first and second shards of the second data set can only be shards of a subset of data items. For ease of description, the subset of data items used here can be referred to as valid information.

[0063] The valid information in the data can be any information that is meaningful in the predetermined business process. For example, the valid information can include numerical values ​​in various attribute items, or other data information (such as descriptive information, feature information, etc.) related to the predetermined business process. Figure 1In the example shown, the reservation business process is client-side security screening, that is, obtaining users who meet the reservation conditions. Assuming that the reservation conditions are that the length of employment is consistent with the length of service and the average monthly expenditure is less than the monthly income, the valid information of the second-party (corresponding data platform) data can include the values ​​of attribute items such as length of service and average monthly expenditure.

[0064] In cases where a predetermined business process involves multiple information items (referred to as multiple valid information items) from a single participant, to facilitate comparison, in one embodiment, the valid information items can be concatenated and aligned according to a pre-agreed bit order. For example, in a business process comparing the size of a first-party attribute item R1 and a second-party attribute item S1, the second party describes attribute item S1 using bits 16 to 31 of the Value in the data pair. Thus, when a single first data item is intersecting data, the first party can obtain information describing attribute item S1 from bits 16 to 31 of the obtained random number.

[0065] When the valid information in the data includes multiple valid information items, each valid information item can be split, shared, and then concatenated together, or they can be concatenated together and then split and shared. There is no limitation here.

[0066] It is understandable that step 201 is executed by the first party, while steps 202 and 203 are executed by the second party. Both parties execute their steps independently after agreeing on multiple hash functions, and their execution processes do not interfere with each other. Therefore, this specification does not restrict the order of steps 201 followed by steps 202 and 203. Figure 2 In the example, step 201 comes first, but in reality, steps 202 and 203 can also come first, or steps 201 can be executed in parallel with steps 202 and 203.

[0067] Step 204: The first party and the second party execute the OPPRF protocol based on each first hash value of the first party and each data pair of the second party, so that the first party obtains the first bucket information corresponding to each first hash value.

[0068] According to the execution principle of the OPPRF protocol, the specific process is as follows: The second party fits a polynomial of Value with respect to the Key and provides the polynomial coefficients to the first party. The first party can determine each pseudo-random number for each query using methods such as polynomial interpolation. In the polynomial, the Key is the independent variable, and the Value is the dependent variable, determined based on the Key. The pseudo-random number here is the polynomial result calculated with the query as the independent variable. During the execution of the OPPRF protocol, the query, as the independent variable, determines the value of the polynomial. When the query matches the Key, the pseudo-random number obtained by the first party is the corresponding Value. Since the query corresponding to a single bucket is determined by the corresponding hash value, and a single bucket corresponds to a single query, the obtained pseudo-random number can be used to clarify the information of the first bucket.

[0069] Here, in the second-party data pair, the Key can be the second hash value or its ciphertext. Correspondingly, if the Key is the second hash value, the first-party query is the ciphertext of the first hash value.

[0070] The ciphertext of the first hash value is obtained by encryption using the same encryption key as the second party. To determine the ciphertext of the first hash value, both the first and second parties can perform secure computations. In one implementation, the second party can send its local key (kb) to the first party, which then performs the encryption locally. In another implementation, both parties execute the OPRF protocol, securely encrypting each first hash value using the OPRF protocol, provided the first party provides the first hash values ​​and the second party provides the key (kb). After encryption, the first party obtains the ciphertext of each first data entry locally, corresponding to its respective first hash value. The second party cannot obtain either the first party's first hash value or its encryption result.

[0071] It is understandable that the encryption process for the first hash value can be performed before or during the execution of the OPPRF protocol, and this is not limited to this.

[0072] Figure 3This example illustrates a specific instance of ciphertext used to determine the first and second hash values. As described earlier, assume the first party (Receiver) holds n=4 data items, with corresponding first data identifiers denoted as id0, id1, id2, and id3. The second party (Sender) also holds t=4 data items, with corresponding second data identifiers denoted as id0, id1, id4, and id5. The number of buckets is B=6, and each bucket is labeled with bucket identifiers bin0 to bin5. The number of hash functions is c=3. The first party performs a Cuckoo Hash calculation, distributing the 4 first data items into n=4 buckets (or, in other words, mapping data identifiers to bucket identifiers). The second party performs a simple hash calculation, distributing the c×t=12 second hash values ​​corresponding to the 4 data items into 6 buckets.

[0073] Then, the second party encrypts the second hash value corresponding to the corresponding bucket using the keys k0 to k5 generated using the key seed kb. The encryption result, i.e., the indexed ciphertext, is represented by F, which can be found in the reference. Figure 3 As shown in Table 304, the second party encrypts the corresponding second hash value using a local key to obtain the local key. For example, F... k0 (id4) represents the result of mapping the data identifier id4 to the second hash value of bucket bin0 using key k0. On the other hand, by executing the OPRF protocol, where the first party provides the first hash value corresponding to a single bucket and the second party provides the corresponding encryption key, the first party obtains the ciphertext of the first hash value encrypted with the corresponding encryption key as the query. This ciphertext can also be represented by F, see reference [link to relevant documentation]. Figure 3 As shown in Table 303, F k0 ($), F k1 (id3) is the ciphertext of the local first hash value obtained after executing the OPRF protocol and encrypted with the second party's encryption key. Thus, for B buckets, a total of B first hash value ciphertexts are obtained.

[0074] Thus, when the second party provides a data pair and the first party provides the corresponding first hash value or ciphertext of the first hash value, a pseudo-random number (string) can be obtained through interpolation. The first party can use this pseudo-random number as the corresponding first bucket information. It can be understood that if a single first hash value is equal to any second hash value in the corresponding bucket of the second party, the first bucket information corresponding to that single first hash value is consistent with the second bucket information corresponding to that second hash value.

[0075] Depending on the implementation, to avoid leaking local data, the first hash values ​​provided by the first party may include spurious first hash values ​​filled with empty buckets, such as... Figure 3 F in k0($), etc. Thus, for B buckets, the first party queries B times to obtain B bucket information. In some implementations that do not require protection of the first party's data privacy, in the OPPRF protocol, since the first party knows the valid bucket corresponding to the first data locally, it can query only the first hash value corresponding to the first data to obtain the corresponding pseudo-random number.

[0076] The first bucket of information can also correspond to a bucket identifier and a corresponding data fragment, such as the second data fragment. This second data fragment is different from the first fragment of the second data because it is currently a suspected first fragment of the second data, and it cannot yet be determined whether it is indeed the first fragment of the second data. In order to complete conditional data comparison or data fusion without disclosing privacy, the first party uses it as the first fragment of the second data. The bucket identifier and the corresponding data fragment can be identified according to the number of bits agreed upon with the second party, such as the first 16 bits identifying the bucket identifier and the last 64 bits identifying the second data fragment, etc. The i-th bucket identifier identified by the first party is denoted as r. ai .

[0077] Step 205: The first party and the second party perform security calculations based on the first party's first bucket information, the second party's second bucket information, and the second fragments of each second data to determine the intersection of n first data and t second data.

[0078] It is understandable that, when a single piece of first data is the intersection of data from the first party and the second party, the bucket identifier r of the corresponding bucket i identified by the first party from the information in the first bucket is... ai It must be related to the bucket identifier r of the second-party bucket i. bi The results are consistent. Therefore, the first and second parties can determine the intersection information by securely comparing the bucket identifiers of the B buckets. In other words, the above secure calculation can include a one-to-one comparison of the bucket identifiers of the B buckets between the first and second parties. The first party's B bucket identifiers r a1 to r aB It can be combined with the B bucket information from the second party. b1 to r bB A one-to-one comparison is performed, and the number of safe comparisons can be B. There are B comparison results, for example, described by a B-dimensional vector or array. Each element in the comparison result corresponds to one of the two bucket identifiers indicating whether they are equal. The comparison results can be constructed and shared by the first and second parties, such as the first party holding a fragment of the intersection comparison results. <hit>1. The second party holds the intersection comparison result fragments. <hit>2. The value r held by the first party ai The value r held by the second party bi Safety comparisons can be performed using various conventional safety comparison methods, such as modular safety comparison circuits, which will not be elaborated here.

[0079] In some embodiments, the intersection result can be obtained by the first party, then the second party can divide the fragments. <hit>2. The data is sent to the first party, who then reconstructs the intersection of the two results based on the shared format, such as in... <hit> 1、 <hit>In the case of arithmetic partitioning, sum them up. <hit> 1、 <hit>In the case of Boolean partitioning, XOR operation is performed to obtain a vector consisting of 0s and 1s, such as (0, 0, 1, 0, 1, 0). 1 indicates that the data in the corresponding bucket is intersecting data, and 0 indicates non-intersecting data.

[0080] The above security comparisons can be used as part of the security computations performed by the first and second parties to determine the intersection of all data. This specification also considers scenarios involving conditional data filtering or intersection data fusion processing.

[0081] In response, the first party can also identify the second data fragment from the first bucket of information. Since the first bucket of information is determined using polynomial interpolation in the OPPRF protocol, this second data fragment is not necessarily a true fragment of the second data, i.e., the first fragment. To perform data processing without revealing privacy, each second data fragment can be treated as the first fragment of the corresponding second data. Combined with the local first data and the second fragment of the second data held by the second party, a secure computation is performed to obtain the result. Specifically, the second party holds a one-to-one corresponding second data fragment for each bucket, thus performing data computation without revealing the intersection data.

[0082] Specifically, secure computation for data processing can include at least one of the following: determining whether each piece of first data and each piece of second data meets predetermined conditions; and performing fusion processing on the intersection of the first and second data to obtain a processing result. For example, in the process of rating users, the first and second parties can use secure computation based on a rating model to obtain and share the rating result. As another example, in the case of filtering users who meet predetermined conditions based on user attribute items, secure comparison computation can be used, and comparison results can be obtained and shared between the first and second parties.

[0083] Some optional implementations assume that the predetermined conditions include multiple parallel conditions that need to be met simultaneously. These predetermined conditions can be converted into relationship checks such as greater than, less than, or equal to the corresponding attribute values. The relationship checks of each predetermined condition can be represented using AND, OR, or NOT gates. In this way, a secure comparison can be performed on the corresponding data to determine whether the predetermined conditions are met. The secure comparison method can be implemented using conventional secure comparison protocols, such as OT-based secure comparison algorithms, which will not be elaborated upon here.

[0084] The secure computing process here can be implemented based on the multi-party secure protocol GMW, which supports both Boolean Circuit and arithmetic circuit calculations. For example, in the business process of rating users, the first party and the second party can use GMW based on the rating model for calculation. When filtering users who meet the predetermined conditions based on user attribute items, the arithmetic circuit of the secure comparison strategy can be used for calculation. When the predetermined conditions include multiple parallel condition items that need to be satisfied simultaneously, each condition item can obtain a processing result, and then the AND gate in the Boolean Circuit can be used to securely fuse the results of multiple parallel condition items as the business processing result. It can be understood that in the process of secure interaction and data processing between the first party and the second party, in some embodiments, based on the requirements of the secure computing circuit, the first party can split the local first data into a sum-sharing form, retain one shard, and share the other shard with the second party to perform relevant secure calculations in the sum-sharing form.

[0085] According to some possible designs, considering that before distinguishing whether the data is intersection data, business processing is performed on the data corresponding to each bucket, and some business processing results are untrue business processing results. At this time, the business processing results without distinguishing whether it is intersection data can be recorded as business preprocessing results. The business preprocessing results can be distributed in a sum-sharing form between the first party and the second party, such as being respectively recorded as the shard held by the first party and the shard held by the second party . and can be sum-sharing shards or Boolean shards, which are not limited here. The final business processing result can be jointly determined by the intersection comparison result and the business preprocessing result. In the conditional private intersection scenario, the data for which the intersection comparison result is equal and the predetermined conditions are simultaneously satisfied is the final intersection data.

[0086] In practice, the computing circuit of the secure comparison protocol can use conventional circuit modules. For example, whether M > N holds, whether M < N holds, and whether M = N holds respectively correspond to 3 circuit modules. The first party and the second party can respectively call the corresponding circuit modules to obtain the sum-sharing form of the corresponding comparison results. In an optional embodiment, these circuit modules can be pre-cured, encapsulated, and can be hardware or software modules installed or configured on the devices for secure interaction.

[0087] According to the calculation rules in the multi-party security mode, the sharding based on the comparison results between various predetermined conditions can securely determine the fusion result of the comparison results of the predetermined condition items. Usually, the comparison result of the secure comparison is whether a certain size relationship holds, such as whether M > N holds, whether M < N holds, whether M = N holds, etc., and the comparison result usually exists in a sum-sharing form, that is, a single participant holds a single shard of the comparison result. The comparison result is usually represented by 0 or 1. For example, 1 represents holding and 0 represents not holding. A single shard of the comparison result is a sum-sharing form modulo 2 N or a boolean shard form, which is not limited here. The comparison results of multiple condition items can also be represented by 0 or 1, and the intersection comparison result and the comparison results of each condition item can be implemented through an AND gate circuit.

[0088] Referring to conventional techniques such as "CMSC 858T Secure Distributed Computation, February 4, 2021, Lecture 4", taking the "AND" circuit calculation as an example, assume that two comparison results x and y are distributed among n participants in a boolean sharing form (which can be mutually converted between the arithmetic sharing form modulo 2 N ), then the secure AND calculation of z = x ∧ y (∧ represents AND) can be expressed as:

[0089] .

[0090] In this way, the comparison results between various predetermined condition items can be fused to obtain a fused comparison result, which is used to describe whether the predetermined condition is satisfied. This fused comparison result can be used as the service preprocessing result. The fused comparison result can be distributed in a sum-sharing form between the first party and the second party, such as the shard held by the first party and the shard held by the second party . It can also correspond to a B-dimensional vector composed of two element values 0 and 1.

[0091] According to some possible implementation manners, if the data identifier is regarded as an attribute item of the data, the service preprocessing result and the intersection comparison result can be fused through a secure AND operation to obtain a sum-sharing form of the service processing result. The secure AND operation of the intersection comparison result and the service preprocessing result is ( <hit> 1⊕ <hit>2 The secure execution results are not elaborated here. In one embodiment, when the second party provides the first party with the second fragment of the business processing result, the first party can obtain the business result values ​​corresponding to the B buckets respectively. The 0 value can be understood as non-intersecting data or data filtered out from the intersection. For example, in the SPI user segmentation business scenario, a non-zero value represents users who meet the conditions and are selected from the intersection.

[0092] According to some other possible implementations, the second party can fragment the intersection comparison results it holds. <hit>2. Provided to the first party for use by the first party. <hit>1 and <hit>2. Determine the buckets corresponding to the intersection data to first identify the intersection data, and then decide whether the second party should shard the business preprocessing results based on business needs. This is provided to the first party. In this way, even if the first party needs to obtain the processing results of the intersecting data, it can prevent relevant data from being mistakenly filtered out when the business processing result is 0. For example, in business scenarios such as determining user ratings, classifying data subjects (such as users), and calculating probabilities, 0 might be the business processing result value.

[0093] Furthermore, in situations where privacy requirements are not sufficiently stringent, such as when the amount of intersection between the first and second parties can be exposed to the second party, the second party can first provide the intersection comparison results to the first party, and then the first and second parties can perform predetermined business processing only on the intersection data. In an optional embodiment, the first party can also add a small amount of non-intersection data or random data to the intersection data for interference, and then perform secure computation with the second party.

[0094] Depending on some possible implementation methods, the business preprocessing results and the intersection comparison results can be distributed between the two parties in a shared form, and the first party can obtain plaintext information of at least one of them as needed, or use it for subsequent secure calculations.

[0095] Figure 2 In the illustrated embodiment, based on the OPPRF protocol, data fragments are transmitted together during the intersection determination process according to bucket identifiers, thereby merging the intersection calculation and data processing processes, effectively completing the intersection of privacy information with conditions or involving data fusion processing. Specifically, the first party maps local data identifiers to various buckets using a cuckoo hash, with one bucket corresponding to at most one data identifier. The first party uses a simple hash function consistent with cuckoo hash to calculate multiple hash values ​​for one data identifier and maps each hash value to its corresponding bucket. Thus, when the data corresponding to a single bucket of the first party is intersection data, its corresponding hash value will necessarily be matched by the hash value of a data identifier corresponding to the corresponding bucket of the other party. Therefore, the second party can construct data pairs based on the data identifier hash value and the bucket identifier, and the first party can obtain the bucket identifier corresponding to each hash value when both parties execute the OPPRF protocol. Since a single local hash value corresponds to a single bucket identifier, the intersection can be determined based on whether the bucket identifier is consistent with the local bucket identifier.

[0096] To perform data computation, data fragments can be transmitted along with bucket identifiers. The second party constructing the OPPRF protocol data pair (usually the party unaware of the intersection result) buckets the data and uses the concatenation of the bucket identifier and the common data fragments of individual buckets as the Value to construct the data pair. During the execution of the OPPRF protocol, for the intersection data, the first party can obtain not only the bucket identifier but also the data fragments. Thus, on the one hand, the bucket identifier is used to securely find the intersection of data; on the other hand, transmitting data fragments without disclosing the intersection to the second party facilitates secure data processing, such as conditional judgments or data fusion. This provides effective privacy information for intersection calculation with accompanying judgment conditions or data processing conditions.

[0097] Figure 2 This illustrates the process of intersecting privacy information between the first and second parties. Figure 4 The flow of first-party execution that can obtain the intersection result is shown, including the following steps:

[0098] Step 401: Using multiple hash functions, the n first data identifiers corresponding to the n first data are divided into buckets based on the cuckoo hash method, and the n first hash values ​​corresponding to the n first data identifiers are divided into B buckets, where B is greater than n, and a single bucket corresponds to at most a single first hash value.

[0099] Step 402: Based on each first hash value, the OPPRF protocol is executed by the second party. Based on each data pair constructed by the second party, the first bucket information corresponding to each first hash value is obtained. Each data pair corresponds to each second hash value and the corresponding second bucket identifier. The second bucket identifier corresponding to a single second hash value is determined by the second party through multiple hash functions based on a simple hash method to bucket t second data identifiers corresponding to t second data into B buckets. A single second hash value is determined by hash calculation of a single second data identifier during the bucketing process. The second bucket information includes the bucket identifier and the first fragment of the second data corresponding to the corresponding second hash value. The second fragment of each second data is retained by the second party. Second data with the same bucket identifier have the same second fragment. When a single first hash value is equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value is consistent with the second bucket information corresponding to any second hash value.

[0100] Step 403: Based on the information from each first bucket, perform a secure calculation with the second party to determine the intersection of n first data and t second data.

[0101] In one embodiment, in secure computation, the second party provides information on each second bucket and a second fragment of each second data item, while the first party provides a bucket identifier identified through the first bucket information, a second data fragment, and each first data item. Secure computation includes secure comparison of bucket identifiers and at least one of the following: determining whether each first data item and each second data item meets predetermined conditions; and performing fusion business processing on the first data and second data items in the intersection to obtain a business processing result.

[0102] Figure 5 The process of second-party execution, which is inconvenient for obtaining intersection results, is shown, including the following steps:

[0103] Step 501: Using multiple hash functions based on a simple hashing method, the t second data identifiers corresponding to the t second data are bucketed, and the multiple second hash values ​​corresponding to the t second data identifiers are distributed to B buckets. Each second data identifier corresponds to a second hash value determined by each hash function.

[0104] Step 502: Construct data pairs based on the second bucket information corresponding to each second hash value. The second bucket information includes the bucket identifier and the first fragment of the second data corresponding to the second hash value. The second fragment of each second data is retained by the second party. Second data with the same bucket identifier have the same second fragment.

[0105] Step 503: Based on each data pair, execute the OPPRF protocol with the first party to enable the first party to obtain the first bucket information corresponding to each first hash value. Each first hash value is determined by the first party through hash calculation of the n first data identifiers corresponding to n first data using multiple hash functions in the process of bucketing to B buckets using the cuckoo hash method. B is greater than n. A single bucket corresponds to at most a single first hash value. If a single first hash value is equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value is consistent with the second bucket information corresponding to any second hash value.

[0106] Step 504: Based on the information from each second bucket and the second fragment of each second data, perform a security calculation with the first party to determine the intersection of n first data and t second data.

[0107] In one embodiment, in the above-mentioned secure computation, the first party provides a bucket identifier identified by the first bucket information, a second data fragment, and each piece of first data; the above-mentioned secure computation includes a secure comparison of the bucket identifier, and at least one of the following: determining whether each piece of first data and each piece of second data meets a predetermined condition; performing fusion business processing on the intersection of the first data and the second data to obtain a business processing result.

[0108] It is worth noting that, Figure 4 , Figure 5 The steps for finding the intersection of privacy information under the technical concept described in this specification are described from the perspective of a single participant, and they correspond to... Figure 2 The first party and the second party are shown. Therefore, Figure 2 The descriptions of first-party and second-party in the text also apply. Figure 4 , Figure 5 The participants will not be elaborated here.

[0109] To clarify the technical concept of this specification, Figure 6 This document illustrates a specific example of the privacy information intersection execution flow based on the technical concept described herein.

[0110] like Figure 6 As shown, the two parties are denoted as the sender and the receiver, respectively. The sender can correspond to... Figure 2 The second party in the agreement, the recipient can correspond to Figure 2 The first party in the dataset. The receiver corresponds to a dataset X = {x1, ..., x...}. n }, which contains n data points x1, x2, ..., xn. n The sender has a corresponding dataset Y={y1……y} t }, which contains t data y1, y2...y t .

[0111] The first step involves hash-to-bining. The receiver performs a cuckoo hash, and the binning results are... Figure 6 If denoted as X B =CuckooH k (X). The execution result of the Cuckoo Hash is as follows: The hash values ​​of the data identifiers corresponding to n data points are calculated using multiple hash functions, and according to the Cuckoo Hash principle, a single data identifier is mapped to the corresponding bucket using a hash value. In the privacy information intersection in this specification, a single bucket can correspond to at most a single hash value of one data point; buckets without a corresponding hash value can be filled with random strings. The sender performs a simple hash, denoted as Y. B =SimpleH k (Y). For the data identifier of a single data item, each hash value is calculated using the aforementioned multiple hash functions, and each hash value is mapped to a corresponding bucket.

[0112] The second step is to execute OPRF. The receiver provides the hash value or random string from each bucket, denoted as a in the i-th bucket. i The sender provides the encryption key k b The hash value corresponding to the i-th bucket is denoted as b. i Here, B buckets can correspond to B encryption keys, such as the encryption key corresponding to the i-th bucket being denoted as k. bi . Figure 6 For ease of illustration, k is used consistently. b This represents the encryption key. The result of OPRF execution is that the receiver obtains the hash values ​​or random strings from the B buckets, along with the encryption key k corresponding to the sender's bucket. b The encrypted ciphertext is denoted as: oprfa i =f(k) b a i ), where i represents the bucket number. Correspondingly, the sender can execute the local encryption key k itself. b Encrypting the hash values ​​corresponding to the B local buckets yields the ciphertext of each hash value, denoted as prfb. i =f(k) b b i ), b i This represents the hash values ​​in the i-th bucket.

[0113] The third step involves both parties executing OPPRF. The sender assigns a bucket identifier to each bucket, denoted as r. b The same data shards are denoted as the second shard. <d b > b Calculate the first partition of the data corresponding to each hash value in the i-th bucket, denoted as d. bi - <d b > b For each hash value within a single bucket, the bucket identifier is concatenated with the first shard of the data, resulting in: r b ||d bi - <d b > b This corresponds to the second bucket of information mentioned earlier. The concatenated result is used as the Value, prfb i As the key, construct a (Key, Value) data pair, denoted as (prfb). i r b ||d bi - <d b > b The number of hash values ​​in the i-th bucket determines the number of data pairs constructed for that bucket. The sender provides each data pair, and the receiver provides the hash values ​​or random string ciphertext oprfa corresponding to the B buckets. i The execution result of OPPRF is that the receiver receives the first bucket of information, denoted as r. a ||d b - <d b > b In this process, each receiver receives a single bucket of information from the first bucket.

[0114] The fourth step is data splitting. The receiver splits the received first bucket of information into B buckets, each corresponding to a bucket identifier r. a and data sharding d b - <d b > b .

[0115] Step 5: Data ID Compare. This can be understood as follows: if the data ID corresponding to the i-th bucket of the receiver is the intersection of the two IDs, then the resulting bucket ID r... ai With the bucket identifier r provided by the sender bi Consistent. Therefore, compare the B bucket identifiers r obtained by the receiver. a The B bucket identifiers r of the sender b The intersection comparison result can be determined. Bucket identifier comparison can be performed through a pre-defined secure comparison calculation circuit "GMW Copare". The execution result is structured and shared in a specific form, including the first fragment held by the receiver. <hit>1 and the second fragment held by the sender <hit>2. The intersection comparison result hit can be a B-dimensional vector with each dimension being 0 or 1, where 1 indicates that the corresponding bucket labels are consistent and 0 indicates that the corresponding bucket labels are inconsistent.

[0116] Step 6: Execute the data computation circuit (GMW Circuit). The data computation circuit can be a pre-set conditional judgment secure computation circuit or a data processing secure computation circuit. For each bucket, the receiver provides the segmented data fragments d. b - <d b > b The sender provides data fragmentation. <d b > b In this context, the sender is unaware of which data fragment corresponding to the specified bucket the receiver is providing. The data computation results are structured and shared in a specific manner, including the first fragment held by the receiver.<res_d> 1. The second fragment <res_d> held by the sender. 2. In conditional judgment cases, the calculated data result res_d can be a B-dimensional vector with each dimension being 0 or 1, where 1 indicates the condition is true and 0 indicates the condition is false. In data fusion processing cases, res_d represents the data processing result, such as a classification result. When res_d is a binary classification result, it can also be a B-dimensional vector with each dimension being 0 or 1, where 1 represents the first category and 0 represents the second category.

[0117] Step 7: Result fusion. The recipient provides... <hit>1 and<res_d> 1. The sender provides <hit>2 and<res_d> 2. Both parties jointly determine the fusion result of the intersection comparison result (hit) and the data calculation result (res_d). For example, under conditional judgment, the intersection data is determined by the Boolean circuit condition.

[0118] Reviewing the above process, during the privacy information intersection process performed by the two participating parties, the first party, as the result party, maps each piece of local first data to B buckets using a cuckoo hash, with each bucket corresponding to at most a single piece of data. The second party, as the non-result party, uses a simple hash to map each piece of data to B buckets. Thus, if the first data corresponding to a single bucket of the first party is intersecting data, its corresponding first hash value will inevitably be matched by a second hash value corresponding to the second party's bucket. Based on this, the second party constructs data pairs using the second bucket information corresponding to each second hash value. The second bucket information includes the bucket identifier and the first fragment of the corresponding second data, and the second fragments stored locally for each bucket are identical. The first party uses the first hash value to execute the OPPRT protocol with the second party, allowing the first party to obtain the first bucket information corresponding to each first hash value. A single piece of first information can identify the corresponding bucket identifier and the second data fragment (distinguished from the first and second fragments of the second data). Both parties securely compare the bucket identifiers to determine the intersection based on the comparison result.

[0119] Furthermore, regardless of which second hash value in the same bucket identifier of the second party is matched by the first hash value corresponding to a single bucket of the first party, the first fragment of the corresponding second data (i.e., the identified second data fragment) is identified. Even if the second party does not know which second data is matched, it can provide the corresponding second data fragment. This ensures that the second party's data fragments are effectively transmitted to the first party, enabling secure business processing jointly by both parties without disclosing the first party's data privacy to the second party. This provides an effective solution for intersection-based business processing in secure two-party computing scenarios.

[0120] According to another embodiment, an apparatus is also provided that can securely perform intersection data processing on a single participant.

[0121] A device for finding the intersection of privacy information of the party that has access to the intersection data (e.g., denoted as the first party) includes, for example:

[0122] The bucketing unit is configured to use multiple hash functions to bucket the n first data identifiers corresponding to the n first data based on the cuckoo hash method, and to divide the n first hash values ​​corresponding to the n first data identifiers into B buckets, where B is greater than n, and a single bucket corresponds to at most a single first hash value.

[0123] The protocol execution unit is configured to execute the OPPRF protocol based on each first hash value and the second party. Based on each data pair constructed by the second party, it obtains the first bucket information corresponding to each first hash value. Each data pair corresponds to each second hash value and the corresponding second bucket identifier. The second bucket identifier corresponding to a single second hash value is determined by the second party through multiple hash functions based on a simple hash method to bucket t second data identifiers corresponding to t second data into B buckets. A single second hash value is determined by hash calculation of a single second data identifier during the bucketing process. The second bucket information includes the bucket identifier and the first fragment of the second data corresponding to the corresponding second hash value. The second fragment of each second data is retained by the second party. Second data with the same bucket identifier have the same second fragment. When a single first hash value is equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value is consistent with the second bucket information corresponding to any second hash value.

[0124] The secure computing unit is configured to perform secure computing with the second party based on the information from each first bucket, and to determine the intersection of n first data and t second data.

[0125] According to one embodiment, in secure computation, a second party provides information on each second bucket and a second fragment of each piece of second data, while a first party provides bucket identifiers identified through the first bucket information, second data fragments, and each piece of first data. Secure computation includes secure comparison of bucket identifiers, and at least one of the following: determining whether each piece of first data and each piece of second data meets predetermined conditions; and performing fusion business processing on the first and second data in the intersection to obtain a business processing result.

[0126] Devices for finding the intersection of privacy information of parties whose data cannot be obtained include, for example:

[0127] The bucketing unit is configured to bucket the t second data identifiers corresponding to t second data based on a simple hashing method using multiple hash functions, and to distribute the multiple second hash values ​​corresponding to the t second data identifiers into B buckets. Each second data identifier corresponds to a second hash value determined by each hash function.

[0128] The data pair construction unit is configured to construct data pairs based on the second bucket information corresponding to each second hash value. The second bucket information includes a bucket identifier and a first fragment of the second data corresponding to the second hash value. The second fragment of each second data is retained by a second party. Second data with the same bucket identifier have the same second fragment.

[0129] The protocol execution unit is configured to execute the OPPRF protocol with the first party based on each data pair, so that the first party obtains the first bucket information corresponding to each first hash value. Each first hash value is determined by the first party through hash calculation of the n first data identifiers corresponding to n first data using multiple hash functions in the process of bucketing to B buckets based on the cuckoo hash method. B is greater than n. A single bucket corresponds to at most a single first hash value. If a single first hash value is equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value is consistent with the second bucket information corresponding to any second hash value.

[0130] The secure computing unit is configured to perform secure computing with the first party based on the information from each second bucket and the second data segment of each second data, to determine the intersection of n first data and t second data.

[0131] In one embodiment, in the above-mentioned secure computation, the first party provides a bucket identifier identified by the first bucket information, a second data fragment, and each piece of first data; the above-mentioned secure computation includes a secure comparison of the bucket identifier, and at least one of the following: determining whether each piece of first data and each piece of second data meets a predetermined condition; performing fusion business processing on the intersection of the first data and the second data to obtain a business processing result.

[0132] It is worth noting that the devices described above are respectively related to Figure 2 In the illustrated method embodiment, the operations performed by the first party and the second party correspond; therefore... Figure 2 The corresponding descriptions in the method embodiments are applicable to the devices disposed in the first party and the second party, respectively, and will not be repeated here.

[0133] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 2 The method described in the text for either party, or Figure 4 , Figure 5 The method described.

[0134] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 2 The method described in the text for either party, or Figure 4 , Figure 5 The method described.

[0135] Those skilled in the art will recognize that the functions described in the embodiments of this specification in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0136] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the technical concept in this specification. It should be understood that the above descriptions are merely specific embodiments of the technical concept in this specification and are not intended to limit the scope of protection of the technical concept in this specification. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of the embodiments in this specification should be included within the scope of protection of the technical concept in this specification.< / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit>

Claims

1. A method for intersection of private information, comprising: a first party divides n first hash values corresponding to n first data identifiers into B buckets based on a plurality of hash functions according to a cuckoo hashing bucketing algorithm, the n first data identifiers respectively correspond to n first data locally, B is greater than n, and a single bucket corresponds to at most a single first hash value; a second party divides t second data identifiers corresponding to t second data into B buckets based on a plurality of hash functions according to a simple hashing algorithm, each second data identifier corresponds to a plurality of second hash values determined based on each hash function respectively; the second party respectively constructs a data pair based on second bucket information corresponding to each second hash value, wherein the second bucket information comprises a bucket identifier and a first fragment of the second data corresponding to the corresponding second hash value, a second fragment of each second data is reserved by the second party, and second data with the same bucket identifier have the same second fragment; the first party and the second party perform a programmable pseudo-random function protocol based on each first hash value of the first party and each data pair of the second party, so that the first party obtains first bucket information corresponding to each first hash value, wherein in the case that a single first hash value is equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value is consistent with the second bucket information corresponding to the any second hash value; the first party and the second party perform secure computation based on each first bucket information of the first party, each second bucket information of the second party, and the second fragment of each second data to determine the intersection of the n first data and the t second data.

2. The method of claim 1, wherein, The data pair comprises an index value and a numerical value, in the data pair corresponding to a single second hash value, the index value is the single second hash value or a ciphertext thereof, and the corresponding numerical value is a splicing value of the corresponding bucket identifier and the first fragment of the second data corresponding to the corresponding second hash value.

3. The method of claim 2, wherein, In the case that the index value in a single data pair is a ciphertext of a single second hash value, the first party performs a programmable pseudo-random function protocol with the second party using a ciphertext of a first hash value, wherein the second hash values corresponding to the same bucket are encrypted by the second party using the same encryption key to obtain the corresponding ciphertext, the ciphertext of the first hash value is a ciphertext encrypted by the encryption key corresponding to the second bucket of the second party, and the ciphertext is obtained by the first party and the second party performing an oblivious pseudo-random function protocol.

4. The method of claim 1, wherein, The first party and the second party perform secure computation based on each first bucket information of the first party, each second bucket information of the second party, and the second fragment of each second data to determine the intersection of the n first data and the t second data, comprising: the first party identifies a bucket identifier and a data fragment from each first bucket information, in the case that a single first hash value is equal to any second hash value of the second party, the corresponding data fragment is the first fragment of the second data corresponding to the any second hash value; the first party and the second party perform secure computation based on the second data fragment identified by the first party, each first data, and the second fragment of the second data reserved by the second party according to the bucket identifier to determine the intersection of the n first data and the t second data.

5. The method of claim 4, wherein, The security calculation includes a secure comparison of the bucket identifiers, and at least one of: determining whether each piece of first data and each piece of second data satisfies a predetermined condition; performing a fusion service processing on the first data and the second data in the intersection to obtain a service processing result. 6.A method for privacy intersection, used for a first party and a second party to jointly perform privacy intersection, the method being performed by the first party and comprising: bucketing, by a plurality of hash functions, n first data identifiers corresponding to n first data based on a cuckoo hash manner, and distributing n first hash values corresponding to the n first data identifiers into B buckets, B being greater than n, and a single bucket corresponding to at most a single first hash value; based on each first hash value and a programmable pseudo-random function protocol executed by the second party, obtaining first bucket information corresponding to each first hash value based on each data pair constructed by the second party, wherein each data pair corresponds to each second hash value and a corresponding second bucket identifier respectively, the second bucket identifier corresponding to a single second hash value being determined by the second party based on simple hash manner bucketing t second data identifiers corresponding to t second data into the B buckets by the plurality of hash functions, the single second hash value being determined by hash calculation on a single second data identifier in the bucketing process, the second bucket information including a first shard of the second data corresponding to the corresponding second hash value, a second shard of each second data being reserved by the second party, the second data with the same bucket identifier having the same second shard, and in a case where a single first hash value is equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value being consistent with the second bucket information corresponding to the any second hash value; based on each first bucket information, performing security calculation with the second party to determine an intersection of the n first data and the t second data.

7. The method of claim 6, wherein, In the security calculation, the second party provides each second bucket information and a second shard of each piece of second data, and the first party provides a bucket identifier identified by the first bucket information, a second data shard, and each piece of first data; The security calculation includes a secure comparison of the bucket identifiers, and at least one of: determining whether each piece of first data and each piece of second data satisfies a predetermined condition; performing a fusion service processing on the first data and the second data in the intersection to obtain a service processing result. 8.A method for privacy intersection, used for a first party and a second party to jointly perform privacy intersection, the method being performed by the second party and comprising: bucketing, by a plurality of hash functions, t second data identifiers corresponding to t second data based on a simple hash manner, and distributing a plurality of second hash values corresponding to the t second data identifiers into B buckets, a single second data identifier corresponding to each second hash value determined based on each hash function respectively; based on each second hash value, respectively constructing a data pair based on a second bucket information corresponding to the second hash value respectively, wherein the second bucket information includes a first shard of the second data corresponding to the corresponding second hash value, a second shard of each second data being reserved by the second party, and the second data with the same bucket identifier having the same second shard; and Based on each data pair, and the first party performs a programmable pseudo-random function protocol, so that the first party gets the first bucket information corresponding to each first hash value, wherein each first hash value is determined by the first party through hash calculation in the process of bucketing n first data identifiers corresponding to n first data pairs to B buckets based on the cuckoo hashing method by a plurality of hash functions, B is greater than n, a single bucket at most corresponds to a single first hash value, in the case of a single first hash value being equal to any second hash value of the second party, the first bucket information corresponding to the single first hash value is consistent with the second bucket information corresponding to the any second hash value; Based on each second bucket information, the second fragment of each second data, and the first party, the intersection of the n first data and the t second data is determined by secure calculation.

9. The method of claim 8, wherein, In the secure calculation, the first party provides the bucket identifier identified by the first bucket information, the second data fragment, and each first data; The secure calculation includes secure comparison of the bucket identifier, and at least one of the following: Determine whether each first data and each second data satisfy a predetermined condition; Fuse the intersection of the first data and the second data to obtain a business processing result.

10. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and the processor executes the executable code to implement the method of any one of claims 6-9.

Images