Privacy information intersection method and computing device

Abstract

The embodiment of the invention provides a privacy information intersection method and computing equipment, in the process that two participants safely carry out privacy information intersection, one party executes cuckoo hash bucket dividing, one bucket corresponds to a single piece of data at most, the other party executes simple hash, each hash value corresponding to one piece of data participates in bucket dividing, and the privacy information intersection efficiency is improved. A simple hash party constructs a data pair by utilizing bucket information formed by each hash value, the bucket identifier and the data fragment, and then the other party performs interpolation query based on the OPPRF protocol by utilizing the hash value of the cuckoo hash so as to obtain the bucket information formed by the bucket identifier and the data fragment. Therefore, the data can be transmitted under the condition that one simple hash party does not acquire any intersection so as to perform joint data processing, and an effective solution is provided for privacy information intersection with conditions or data processing in a secure computing scene of the two parties.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of secure computing technology, and more particularly, to a method and computing device for intersecting private information. Background Art

[0002] Secure multi-party computation, also known as multi-party secure computation, involves multiple parties jointly computing the result of a function without disclosing the input data of the parties involved. The result is publicly available to one or more of the parties involved. For example, a typical application of secure multi-party computation is the secure processing of intersection data. Securely determining intersection data is known as private set intersection (PSI), also known as database collision, and can be understood as determining the intersection of data between multiple parties while preserving privacy. Private set intersection can be used for collaborative multi-party training of machine learning algorithms, data analysis, querying, and other services. The core concept of private set intersection is that at the end of the protocol interaction, one or more parties obtain the correct intersection and do not obtain any other data from other parties' data sets outside the intersection.

[0003] Conventional private information intersection usually determines the intersection of identical data identifiers separately, and then performs other data processing based on the intersection results. However, in practice, there are often some private information intersections with attached conditions, and the attached conditions involve multi-party data. For example, to determine the population whose average monthly expenditure S1 is less than the monthly income S2, the average monthly expenditure S1 is held by the first financial institution, and S2 is held by the second financial institution. The result is obtained by the second financial institution and is not disclosed to the first financial institution. In this case, if a private information intersection is first performed to determine the user intersection, and then the average monthly expenditure S1 and the monthly income S2 are compared, it is difficult to achieve the goal of not disclosing the user intersection to the first financial institution. Therefore, how to perform private information intersection with attached conditions or attached data processing is an important technical issue worthy of study in the multi-party secure computing scenario. Summary of the Invention

[0004] One or more embodiments of this specification describe a method and a computing device for intersecting private information to solve one or more problems mentioned in the background technology.

[0005] According to a first aspect, a method for intersecting privacy information is provided, comprising: a first party bucketing n first hash values ​​corresponding to n first data identifiers into B buckets based on multiple hash functions according to a cuckoo hashing bucketing algorithm, wherein the n first data identifiers correspond to n local first data respectively, B is greater than n, and a single bucket corresponds to at most a single first hash value; a second party bucketing t second data identifiers corresponding to t second data based on a simple hashing method using the multiple hash functions, and dividing multiple second hash values ​​corresponding to the t second data identifiers into B buckets, wherein a single second data identifier corresponds to each second hash value determined based on each hash function; the second party constructs data pairs based on the second bucket information corresponding to each second hash value, wherein the second bucket information includes a bucket identifier. The first shard of the second data corresponding to the identification and the corresponding second hash value is retained by the second party, and the second data with the same bucket identifier have the same second shard; the first party and the second party execute a programmable pseudo-random function protocol based on the first hash values ​​of the first party and the data of the second party, so that the first party obtains the first bucket information corresponding to the first hash value, wherein, 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; the first party and the second party determine the intersection of the n first data and the t second data based on the first bucket information of the first party, the second bucket information of the second party, and the second shard of each second data.

[0006] According to a second aspect, a privacy information intersection method is provided, which is used for a first party and a second party to jointly perform privacy intersection. The method is executed by the first party, including: bucketing the n first data identifiers corresponding to the n first data based on a cuckoo hash method through multiple hash functions, and dividing the n first hash values ​​corresponding to the n first data identifiers into B buckets, B is greater than n, and a single bucket corresponds to at most a single first hash value; based on each first hash value and the second party, a programmable pseudo-random function protocol is executed, and based on each data pair constructed by the second party, the first bucket information corresponding to each first hash value is obtained, wherein each data pair corresponds to each second hash value and the corresponding second bucket identifier, and the second bucket identifier corresponding to the single second hash value is obtained by the second party through the multiple The hash function buckets the t second data identifiers corresponding to the t second data into B buckets based on a simple hash method. A single second hash value is determined by hashing the single second data identifier during the bucketing process. The second bucket information includes the bucket identifier and the first shard of the second data corresponding to the corresponding second hash value. The second shards of each second data are retained by the second party. The second data with the same bucket identifier have the same second shard. When the 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 the first bucket information, a secure calculation is performed with the second party to determine the intersection of the n first data and the t second data.

[0007] According to a third aspect, a privacy information intersection method is provided, which is used for a first party and a second party to jointly perform privacy intersection, and the method is executed by the second party, comprising: bucketing t second data identifiers corresponding to t second data based on a simple hash method using the multiple hash functions, and dividing the multiple second hash values ​​corresponding to the t second data identifiers into B buckets, wherein a single second data identifier corresponds to each 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 shard of the second data corresponding to the corresponding second hash value, and the second shard of each second data is retained by the second party, and second data with the same bucket identifier have the same second shard; based on Each data pair executes a programmable pseudo-random function protocol with the first party, so that the first party obtains first bucket information corresponding to each first hash value, wherein each first hash value is determined by the first party through a hash calculation in the process of bucketing n first data identifiers corresponding to n first data into B buckets based on a cuckoo hash method through multiple hash functions, B is greater than n, a single bucket corresponds to at most a single first hash value, and 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; based on each second bucket information and the second shard of each second data, a secure calculation is performed with the first party to determine the intersection of the n first data and the t second data.

[0008] According to a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method of the second aspect or the third aspect.

[0009] According to the fifth aspect, a computing device is provided, comprising a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, the method of the second aspect or the third aspect is implemented.

[0010] Through the methods and computing devices provided in the embodiments of this specification, during the intersection of private information, the first and second parties perform additional business processing based on the intersection data, and the intersection information is not disclosed to the second party. Assuming that the first party holds multiple pieces of first data and the second party holds multiple pieces of second data, the first party performs cuckoo hashing, and a single bucket corresponds to at most a first hash value of the data identifier corresponding to one piece of first data. The second party performs simple hashing (or ordinary hashing) and maps the data to the corresponding bucket. A single bucket can correspond to the second hash values ​​of the data identifiers of multiple pieces of second data. In this way, if the first data corresponding to a single bucket of the first party is intersection data, its corresponding first hash value will inevitably be hit by a second hash value corresponding to the corresponding bucket of the second party. On this basis, the second party constructs a data pair using the second bucket information corresponding to each second hash value. The second bucket information includes a bucket identifier and the first shard of the corresponding second data. The locally stored second shards of the second data corresponding to a single bucket are identical. 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 first communication can identify the corresponding bucket identifier and the second data shard (distinguished from the first and second shards of the second data). Therefore, regardless of which second hash value of the second party's bucket identifier matches the first hash value corresponding to a single bucket on the first party, the first shard of the corresponding second data (i.e., the identified second data shard) is identified. The second party can provide the second shard of the corresponding second data without knowing which second data was matched. Furthermore, the first and second parties can perform data intersection processing, such as conditional processing or fusion processing.

[0011] This allows the intersection result to be obtained by the party serving as the resultant (e.g., the first party) without leaking any intersection information to the other party, effectively resolving the issue of intersectioning private information with accompanying data processing. Furthermore, even if both parties serve as the resultant, the intersection and data processing processes can be combined, improving the efficiency of intersectioning private information with accompanying data processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0013] Figure 1 This is a schematic diagram of a specific implementation scenario for private information intersection; Figure 2 A time sequence diagram showing the interaction between two parties requesting the exchange of private information under the technical concept of this specification; Figure 3 This is a schematic diagram of bucketing two-party data and constructing index ciphertext based on a specific example; Figure 4 A flowchart showing a method for private information intersection performed by a party that can obtain intersection information during the private information intersection process according to an embodiment of this specification; Figure 5 A flowchart of a method for private information intersection performed by a party that is unable to obtain intersection information during the private information intersection process according to an embodiment of this specification is shown; Figure 6 The following is an interaction sequence diagram showing a specific example of two rooms performing private information intersection. DETAILED DESCRIPTION

[0014] First, let’s clarify some professional terms that may be used in this manual:

[0015] Cuckoo hashing is a method for resolving hash collisions. Its purpose is to use a simple hash function to improve hash table utilization while maintaining O(1) query efficiency. The basic idea is to use multiple (e.g., two) hash functions to handle collisions, so that each value can be mapped to multiple (e.g., two) possible positions.

[0016] For example, let's use two hash functions, denoted h1 and h2, corresponding to hash buckets T1 and T2, respectively. When inserting element x, two hash values, h1(x) and h2(x), are calculated. The corresponding position of h1(x) in hash bucket T1 is denoted T1[h1(x)], and the corresponding position of h2(x) in hash bucket T2 is denoted T2[h2(x)]. If either position T1[h1(x)] or T2[h2(x)] is empty, the corresponding hash value is inserted into that empty position. If both positions are empty, a random hash value is inserted. If both positions T1[h1(x)] and T2[h2(x)] are full (other hash values ​​have already been inserted), a random hash value (e.g., the position corresponding to element y) is selected and removed, and the hash value of x is inserted. Repeat the above process to insert the hash value of element y. If the inserted data is kicked out too many times, the hash bucket is considered full, and the hash value can be inserted again through further processing such as expansion and rehashing.

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

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

[0019] The Goldreich-Micali-Wigderson (GMW) multi-party secure computation protocol is a semi-honest multi-party secure computation protocol that can use a Boolean circuit secret sharing protocol, using additive secret sharing. In a two-party secure computation scenario, assume two parties, denoted as P1 and P2, each holding a 1-bit secret x and y. A function F(x, y) to be computed corresponds to a Boolean circuit 𝐶. Party P1 randomly selects a 1-bit value, such as r1, and calculates x⊕r1, where ⊕ represents an exclusive-or (XOR) operation. It then sends r1 to party P2. P2 performs a similar operation, selecting a random bit mask r2 and performing an XOR operation on its own secret y. The result, y⊕r2, is used as the new secret. The selected random bit mask r2 is then sent to party P1. After this process, the two participants P1 and P2 have effectively shared their secrets. Only by obtaining both P1's secret share x⊕r1 and P1's secret share r1 can the secret bit x be recovered. Next, execute Boolean circuit C, evaluating each gate in the circuit until the entire circuit is complete.

[0020] The principles of multi-party secure computation for each gate are as follows. NOT gate computation: Since the NOT gate has a single input, no interaction is required between P1 and P2; therefore, the input can be directly negated. XOR gate computation: P1 computes w1 = (x⊕r1)⊕r2, and P2 computes w2 = (y⊕r2)⊕r1, thus yielding w1⊕w2=x⊕y. AND gate computation: A 4-choose-1 oblivious transfer (OT) protocol must be executed. The NOT and XOR gates can be executed locally, while the AND gate requires communication between the two parties.

[0021] The OT protocol is executed between a sender and a receiver. The sender has several tags (two or more tags), and the receiver selects from these tags. After the OT is executed, the receiver receives the tag it selected but not other tags. The sender is unaware of the tag selected by the receiver. To illustrate the different functions of the two parties involved in the OT protocol, the two parties executing the OT protocol are referred to as the sender and receiver, respectively. In actual business execution, either party can act as the sender or the receiver.

[0022] Pseudorandom Function: Pseudorandom Function, PRF. For n-bit bit string {0, 1} n Mapped to n-bit string {0, 1} n A random function f is a function selected by uniform random sampling in F, that is, f rnd ∈F. In this function family, a function is equivalent to giving a 2 n The size of the entire function family is This is an exponential computational scale, so even if there is an attacker with polynomial resources, it is impossible to model the mapping of a random function f in polynomial time. For a class of keyed functions F, there are F: {0, 1} ∗ ×{0, 1} ∗ →{0, 1} ∗ , i.e., y←F(k,x), where x is the input, k is the key, and y is the output. If F represents the PRF process, the following conditions must be met: Efficient computation: Given k and x, there exists an efficient polynomial-time algorithm that computes y = F(k,x); Indistinguishability: Given a randomly chosen key k, the pseudorandom function F(k,⋅) is indistinguishable from a random function f(⋅); Length preservation: The lengths of y, x, and k are all n.

[0023] Oblivious Pseudorandom Function: OPRF, Receiver has some inputs denoted as a set {x i}, Sender has a key key, under the OPRF protocol, allowing Receiver to input its own i Combined with the Sender's key, it is transformed into the corresponding number F(key, x i ) (such as F(key, x i ) as the key pair x iThe Receiver will not know the Sender's key, and the Sender will not know F(key, x i ). Every input x i Any number that can be calculated is different from any other input, and these numbers can be considered pseudo-random numbers.

[0024] Programmable pseudorandom function: Oblivious Programmable Pseudorandom Function, OPPRF, is a special extension of OPRF. In the OPPRF protocol, the sender can determine the output value of PRF (Pseudorandom Function). The receiver has n data X={x1, ..., x n}, Sender has m data pairs (denoted as Key-Value data pairs, abbreviated as KV, which can also be understood as two-dimensional coordinates). For example, the set of m data pairs is denoted as: KV = {(x1, y1), ..., (x m ,y m )}. Sender takes KV as input, Receiver takes x i As input, the two parties execute the OPPRF protocol. The Sender can fit a polynomial based on KV and provide the polynomial coefficients to the Receiver. The Receiver uses the polynomial interpolation to output x i The corresponding y i ' (also called valuation). If x i Exists in KV, then the y output is interpolated using polynomials i ' has corresponding y in m data pairs i , otherwise it is an invalid random number.

[0025] The solution provided in this specification is described below in conjunction with the accompanying drawings.

[0026] Figure 1 A specific scenario diagram of private information intersection is shown in FIG. Figure 1 In the illustrated scenario, two parties are involved: a data platform and a client. The client can be understood as a user that can interact with the data platform and receive data support from the data platform.

[0027] Such as Figure 1As shown, the client has several local data tables, one of which is a table of basic employee information, including multiple user IDs (such as identity numbers or mobile phone numbers), such as User 1, User 2, and User 3. Each user can correspond to multiple attribute items (or feature items), such as monthly income, length of employment, etc. Assume that the data platform has multiple data tables, one of which displays multiple user IDs (here assuming that the user IDs are described in the same way as the client, such as identity numbers or mobile phone numbers), and holds multiple user attribute information, such as deposit amount, length of service, and average monthly expenditure.

[0028] Figure 1 The client shown can query the data platform for users who meet the conditions, such as users whose time on the job is consistent with their length of service, and whose average monthly expenses are less than their monthly income. However, the client is unwilling to disclose the private information in the local data table to the data platform. The private information here includes, for example, the user ID and at least one of the various attribute items. In this way, the client needs to interact securely with the data platform to determine the intersection data that meets the conditions. For example, "the time on the job is consistent with the length of service, and the average monthly expenses are less than the monthly income", etc. Let the time on the job be t1, the length of service be t2, the average monthly expenses be S1, and the monthly income be S2, then the predetermined condition can be recorded as "t1=t2, and S1<S2". That is, filter out users who meet the predetermined condition of "t1=t2, and S1<S2". This is a conditional private information intersection scenario.

[0029] Based on business needs, intersection data that meets certain criteria can be obtained by the client, or it can be constructed and shared between the data platform and the client, without any restrictions here. In short, if the data platform cannot obtain the intersection results, it will be difficult to use the attached conditions to filter users for the intersection.

[0030] It is understandable that Figure 1 This is just one example. In practice, similar business scenarios are possible, as are the number of clients and data platforms. User identifiers can also be other data identifiers. The business being processed is not limited to filtering users who meet the intersection criteria. As another example, it is also possible to use client and data platform data to comprehensively score users or perform other data fusion operations, which will not be discussed here.

[0031] Alternatively, the two parties can have a general partnership, rather than a service relationship between client and data platform. For example, in scenarios like PSI tagging, one participant (e.g., client) holds a user ID (e.g., identification code, phone number, etc.) and multiple attributes R1, R2, and R3. The other participant (e.g., data platform) holds the user ID (e.g., identification code, phone number, etc.) and multiple attributes S1, S2, and S3. They need to obtain private information that satisfies predetermined conditions, such as R1 < S1 and R2 > S2, or R3 = S3, to achieve intersection.

[0032] In scenarios where intersection data is used for secure business processing, conventional techniques typically employ data identification for private intersection, with the resulting party receiving the intersection data information. However, if data is selected for joint data processing or conditional judgment based on intersection data information, this intersection information may be leaked to the other party. Therefore, how to securely perform intersection data processing, such as screening out intersection data that meets predetermined conditions, while minimizing computational and communication overhead, without leaking intersection information to the other party, remains a worthy technical challenge.

[0033] In view of this, this specification provides a technical solution for privacy information exchange, which can be used to provide data to one party (such as Figure 1 The data platform in the process can effectively process the intersection data safely (including data fusion) or filter (through conditional judgment) without knowing the intersection data. For details, please refer to Figure 2 shown.

[0034] Figure 2 The diagram shows an interaction sequence diagram of two parties executing a private information exchange process according to an embodiment of the present specification. Figure 2 In the example shown, the two parties are respectively recorded as the first party (e.g. Figure 1 The client in ) and the second party (such as Figure 1 In the data platform party, the data corresponding to the first party can be recorded as the first data, the data corresponding to the second party can be recorded as the second data, the data identifier corresponding to the first data can be recorded as the first data identifier, and the data identifier corresponding to the second data can be recorded as the second data identifier. Data identifiers are symbols, text, etc. used to identify data and are usually unique. The first and second parties can use the same data identifier. For example, the user identifier corresponding to user data can be an identity identification number, mobile phone number, etc. The first party corresponds to n pieces of first data, such as D x ={d x1 , d x2 ...d xn}, the corresponding n first data identifiers are recorded as X={x1, x2...x n}, the second party has t pieces of second data, such as D y={d y1 , d y2 ...d yt}, the corresponding t second data identifiers are recorded as Y={y1, y2...y t}.

[0035] It is understood that a single data identifier may correspond to one or more data items, which together constitute a single piece of data. For example, a single piece of data d xi d yi This includes the concatenation of the values ​​of each data item. Intersection of private information can include various business processing operations on the intersection data of two parties, such as using the data from both parties to score the intersection users, filtering out users from the intersection who meet predetermined conditions, and so on. Taking filtering out users from the intersection who meet predetermined conditions as an example, the predetermined conditions can be conditions that describe the magnitude relationship between data items (attribute items) in the two data sets. This magnitude relationship can be determined by comparing the values ​​of the corresponding data items in the data.

[0036] In Figure 2 In the example shown, referring to the OPRF protocol, OPPRF protocol, etc., one of the first party and the second party can be recorded as the sender (Sender) and the other party as the receiver (Receiver). As an example, assuming that the second party is the sender, for example Figure 1 The data platform in the first party is the receiver, for example Figure 1 The client in the text is a client. It's worth noting that, because the technical concept of this specification is based on the OPPRF protocol, the sender provides a KV data pair. In a KV data pair, the first data is the index (Key, also known as the key value), 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.

[0037] Reference Figure 2 As shown, each step in the interactive process of securely processing intersection data between the first party and the second party is described in detail as follows.

[0038] In step 201, the first party divides n first hash values ​​corresponding to n first data identifiers into B buckets based on multiple hash functions using a cuckoo hashing bucketing algorithm, where the n first data identifiers correspond to the n first data respectively.

[0039] It is understandable that in order to determine the intersection, the first party and the second party may have agreed upon data identification items, such as the user's identity identification number, mobile phone number, etc. In order to determine the intersection while protecting data privacy, the hash value of the data identifier can be used and bucketed by the hash value. The first party uses the cuckoo hash method to bucket the data and ensures that the number of first data items corresponding to a single bucket is not greater than 1. In this way, the number of buckets B can be greater than or equal to the number of first data items n. In order not to disclose the number of first data items n and to ensure the smooth progress of bucketing, B is usually greater than n.

[0040] Bucketing by cuckoo hashing requires calculating a hash value for each first data identifier using a predetermined number of hash functions. The hash function here can be at least one of the following: MD2, MD4, MD5, SHA1, SHA224, SHA256, SHA384, SHA512, SHA3-224, SHA3, etc. Bucketing is usually performed according to the hash value. In a commonly used bucketing method, assuming the number of buckets is B, the hash value is used to modulo B, and the remainder obtained can correspond to the corresponding bucket. For example, the first bucket is identified as A1. If the remainder of the hash value of the data identifier modulo B is 1, it corresponds to the bucket identified as A1.

[0041] According to the principle of cuckoo hashing, the agreed number of hash functions is 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 the single data identifier. If all buckets are occupied, one is randomly kicked out for mapping, and 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 using one of the c hash values, ensuring that a single bucket corresponds to at most one piece of first data. The hash value used to map to the bucket can be recorded as the first hash value. In the case of extra buckets, the empty bucket can be filled with a random string to conceal the privacy of the data bucket. Optionally, B can be determined based on a predetermined multiple of n, such as B=1.2n, B=1.5n, etc.

[0042] In step 202 , the second party buckets the t second data identifiers corresponding to the t second data based on a simple hashing method using multiple hash functions, and divides the multiple second hash values ​​corresponding to the t second data identifiers into B buckets.

[0043] Here, the simple hash method, i.e., the bucketing method using simple hash calculation, refers to calculating hash values ​​using a hash function and bucketing according to the hash values. In the case of multiple hash functions, for a single second data identifier, the corresponding hash values ​​are calculated using multiple hash functions, and each hash value is mapped to B buckets, thereby bucketing each hash value.

[0044] The second party has the same number of buckets as the first party, both B. The second party uses c hash functions (the same hash functions used by the first party for cuckoo hashing) to hash each local data identifier and bucketize it according to the resulting hash values. Assuming the number of second data items on the second party is t, the second party can obtain c×t hash values, each of which can be recorded as the second hash value. A single piece of second data can correspond to c second hash values. These c×t second hash values ​​can be bucketed modulo B, that is, the corresponding second data item is assigned to the bucket corresponding to the remainder of the second hash value modulo B. The number of data items corresponding to a single bucket on the second party may be 0, 1, 2, and so on.

[0045] It can be understood 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 (c) of a single second data identifier bucket are more than the hash functions (1) of a first data identifier bucket, and the hash functions of a single second data identifier bucket include hash functions consistent with the first data identifier bucket, therefore, when a single piece of second data is intersection data with the first data, its corresponding bucket identifiers must hit the bucket identifier corresponding to the corresponding piece of first data on the first party. On the other hand, when the data corresponding to a single bucket of the first party is intersection data, the hash value of its data identifier must be one of the hash values ​​corresponding to the corresponding bucket identifier of the second party.

[0046] refer to Figure 3 As shown, it is assumed that the first party (receiver) holds n=4 data, and the corresponding first data identifiers are recorded as id0, id1, id2, and id3. The second party (sender) also holds t=4 data, and the corresponding second data identifiers are recorded as id0, id1, id4, and id5 respectively. The number of buckets is B=6, and each bucket is marked with bucket identifiers bin0 to bin5 respectively. The number of hash functions is c=3.

[0047] The first party performs a cuckoo hash calculation and assigns the four first data items to n=4 buckets (or understand it as assigning data identifiers to bucket identifiers). The other two buckets are empty. Each non-empty bucket corresponds to a first hash value. An empty bucket can be represented by a random string $ to represent a false first hash value, as shown in Table 301. The second party performs a simple hash calculation and assigns the c×t=12 second hash values ​​corresponding to the four data items to 6 buckets. Figure 3 In the example, it is assumed that two second hash values ​​of id5 are assigned to the same bucket. Therefore, among the six buckets, the second data identifier id5 corresponds to two buckets, and the other second data identifiers correspond to three buckets, as shown in table 302.

[0048] Taking id1 as an example, it is assigned to the bucket labeled "bin4" via cuckoo hashing on the first party, and to three buckets labeled "bin1," "bin3," and "bin4" on the second party via simple hashing. The hash value of id1 assigned to the bucket labeled "bin4" by both parties is consistent in its hash functions and hash values. This means that if the data identifier id1 corresponding to a single bucket on the first party is intersection data, the hash value of that data identifier must be one of the hash values ​​corresponding to the corresponding bucket identifier on the second party (corresponding to the same hash function). The bucket identifiers "bin1," "bin3," and "bin4" corresponding to the hash value of id1 on the second party must match the bucket identifier "bin4" corresponding to the hash value of id1 on the first party.

[0049] In step 203 , the second party constructs data pairs based on the second bucket information corresponding to each second hash value.

[0050] According to the principle of 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, the first hash value of the first party must be the same as the second hash value of the same bucket of the second party, that is, the bucket identifiers corresponding to the two must be the same, so the intersection can be determined based on the comparison of the bucket identifiers.

[0051] The bucket identifier used by the second party 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, which is not limited here. A single bucket identifier uniquely corresponds to a single bucket, and different buckets correspond to different strings. For example, the bucket identifier of the i-th bucket is a random string r bi Indicates.

[0052] Here, the purpose of the second party constructing the data pair is for the first and second parties to execute the OPPRF protocol, so that the second party provides an index (Key) based on the second hash value and a value (Value) containing a bucket identifier, and the first party constructs a query (query) through the first hash value to obtain each bucket identifier. Under the technical concept of this specification, it is desired to transmit data shards while transmitting the bucket identifier. Therefore, the data pair can be constructed using the second bucket information containing the bucket identifier. The second bucket information includes the bucket identifier and the first shard of the second data corresponding to the corresponding second hash value. The second shard of each second data is retained by the second party.

[0053] Specifically, the index item in the data pair can be determined based on the second hash value. It 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 the local key kb. In one embodiment, each bucket can correspond to the same second-party encryption key, such as kb, that is, the hash value corresponding to each bucket identifier is encrypted using the same encryption key. In another embodiment, in order to avoid the same encryption key from leaking data information, each bucket can correspond to a different second-party encryption key, such as kb1, kb2...kbB. In this way, the encryption key corresponding to a single bucket can be used to encrypt its corresponding second hash values ​​to form the ciphertext of the second hash value. Optionally, the encryption keys kb1, kb2...kbB can be random keys generated using the same key seed.

[0054] The Value constructed by the second party can be the second bucket information including the bucket identifier. For a single second hash value, the second bucket information can include the corresponding bucket identifier and a corresponding fragment of the second data, recorded as the first fragment of the second data. Another fragment of the second data, recorded as the second fragment, is split and retained by the second party. Considering that a single bucket can at most hit a single first hash value, the second data with the same bucket identifier can have the same second fragment. In this way, no matter which second hash value hits the corresponding first hash value, the second data fragment can be used for secure data calculation.

[0055] As an example, the value Split into two shards and ,in, Theoretically, the random numbers generated are or can be used as the first fragment of the second data disclosed to the first party. As the first shard of the data, each piece of second data is different from the second shard retained by the second party. If the data intersection is not announced, it will be detrimental to the scheduled 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, As the shared second slice of each second data corresponding to bucket b, it can be used as the second value corresponding to bucket b The second shard is kept locally, and the i-th data Another shard of Can be used as a numerical value The first shard is used to identify the bucket r b As a specific example, the b-th bucket corresponds to any data d bi In the data pair, Value can be, for example, r bi ||( ). “||” indicates splicing.

[0056] In this way, since the second data of the same bucket has the same data shard on the second side (Herein, the second shards are referred to as "second shards"). The second party retains a total of B second shards of the second data. Regardless of which second hash value corresponding to a single bucket of the second party hits 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 shard retained by the second party constitute a shared sum of the corresponding second data, and the second party cannot know which data hit the first party's data. In this way, secure business processing can be performed based on the data in the shared sum format, which not only reduces the amount of data processing but also effectively protects the privacy of the intersection data.

[0057] It's also worth noting that in some business processing scenarios, only some of the second data items may be used. For example, if the attached conditions are individual fields in a data table or individual information items in user information, then the first and second shards of the second data may only be shards of some of the data items. For ease of description, the partial data items required here can be referred to as valid information.

[0058] The valid information of the data can be various information that is meaningful in the process of the predetermined business processing. For example, the valid information of the data can include the values ​​of various attribute items, or other data information associated with the predetermined business processing (such as description information, feature information, etc.). Figure 1In the example shown, the scheduled business processing is the client security circle, that is, obtaining users who meet the predetermined conditions. Assuming that the predetermined 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 may include the values ​​of attribute items such as length of service and average monthly expenditure.

[0059] When a predetermined business transaction involves multiple information items from a single party (e.g., recorded as multiple valid information items), in one embodiment, to facilitate comparison, the valid information items can be concatenated and aligned according to agreed bit positions. For example, in a business transaction comparing the size of a first-party attribute item R1 with 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, if the single piece of first data is intersection data, the first party can obtain information describing attribute item S1 from bits 16 to 31 of the obtained random number.

[0060] In the case where the valid information of the data includes multiple valid information items, each valid information item can be split into shares and then spliced ​​together, or spliced ​​together and then split into shares, which is not limited here.

[0061] It is understandable that step 201 is a step performed by the first party, and steps 202 and 203 are steps performed by the second party, and the two parties perform them separately after agreeing on a number of hash functions. The execution processes of the two parties do not interfere with each other. Therefore, this specification does not limit the order of step 201 first, then step 202, and then step 203. Although Figure 2 In the example, step 201 comes first, but in fact, step 202 and step 203 may come first, or step 201, step 202 and step 203 may be executed in parallel.

[0062] In 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 first bucket information corresponding to each first hash value.

[0063] According to the execution principle of the OPPRF protocol, the specific process of the OPPRF protocol is as follows: the second party fits the polynomial of Value with respect to Key, and provides the polynomial coefficients to the first party. The first party can determine each pseudo-random number for each query through methods such as polynomial interpolation. Among them, in the polynomial, Key is the independent variable, and Value is the dependent variable, which is determined according to 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 is used as the independent variable to determine the value of the polynomial. When the query is consistent with the Key, the pseudo-random number obtained by the first party is the corresponding Value. Since the query corresponding to a single bucket of the first party is determined according to the corresponding hash value, and a single bucket corresponds to a single query, the obtained pseudo-random number can be used as the first bucket information.

[0064] Here, in the data pair of the second party, the Key may be the second hash value or its ciphertext. Correspondingly, when the Key is the second hash value, the query of the first party is the ciphertext of the first hash value.

[0065] The ciphertext of the first hash value is obtained by encryption based on an encryption key consistent with that of the second party. In order to determine the ciphertext of the first hash value, the first party and the second party may perform a secure calculation. In one implementation, the second party may send the local key kb to the first party, and the first party may complete the encryption locally. In another implementation, the two parties execute the OPRF protocol, and when the first party provides each first hash value and the second party provides the key kb, the encryption of each first hash value is securely completed through the OPRF protocol. After encryption, the first party obtains the ciphertext of each first hash value corresponding to each local first data, and the second party cannot obtain any of the first hash value or encryption results of the first party.

[0066] It is understandable that the encryption process of the first hash value may be performed before or during the execution of the OPPRF protocol, which is not limited here.

[0067] Figure 3This section shows a specific example of determining the first and second hash values ​​of ciphertext. As described above, assume that the first party (receiver) holds n = 4 pieces of data, with corresponding first data identifiers denoted as id0, id1, id2, and id3. The second party (sender) also holds t = 4 pieces of data, with corresponding second data identifiers denoted as id0, id1, id4, and id5. The number of buckets is B = 6, each labeled bin0 through bin5, and the number of hash functions is c = 3. The first party performs a cuckoo hash calculation to assign the four pieces of first data to n = 4 buckets (or, more accurately, to associate data identifiers with bucket identifiers). The second party performs a simple hash calculation to assign the c × t = 12 second hash values ​​corresponding to the four pieces of data to six buckets.

[0068] Then, the second party encrypts the second hash value corresponding to the corresponding bucket based on the keys k0 to k5 generated by the key seed kb. The encryption result, i.e., the index ciphertext, is represented by F. Figure 3 As shown in Table 304 in FIG, the second party encrypts the corresponding second hash value with the local key to obtain the local Key. k0 (id4) represents the result of encrypting the second hash value of the data identifier id4 mapped to the bin0 bucket using the key k0. On the other hand, the first party and the second party execute the OPRF protocol. When 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. The ciphertext can also be represented by F. Figure 3 As shown in Table 303, F k0 ($), F k1 (id3) and others are ciphertexts of the local first hash value obtained after executing the OPRF protocol using the second party's encryption key. Thus, for B buckets, a total of B first hash value ciphertexts are obtained.

[0069] In this way, 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 corresponding 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 will 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 the single first hash value is consistent with the second bucket information corresponding to any second hash value.

[0070] According to some implementations, in order to avoid leaking the amount of local data, each first hash value provided by the first party may include a false first hash value filled with an empty bucket, such as Figure 3 F in k0($), etc. Thus, for B buckets, the first party queries B times and obtains B first bucket information. In some implementations that do not require the privacy of the first party's data volume, 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.

[0071] The first bucket information may also correspond to a bucket identifier and a corresponding data fragment, such as the second data fragment. The second data fragment is different from the first fragment of the second data, because at this time it is suspected to be the first fragment of the second data, and it cannot be determined whether it is the first fragment of the second data. In order to complete conditional data comparison or data fusion without leaking privacy, the first party regards 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 with the second party, such as the first 16 bits identify the bucket identifier, and the last 64 bits identify the second data fragment, etc. The i-th bucket identifier identified by the first party is denoted as r ai .

[0072] In step 205 , the first party and the second party perform security calculation based on the first bucket information of the first party, the second bucket information of the second party, and the second shards of the second data to determine the intersection of the n first data and the t second data.

[0073] It can be understood that in the case where a single first data is the intersection data of the first party and the second party, the bucket identifier r of the corresponding bucket i of the first data identified by the first party from the first bucket information is ai , must be the same as the bucket identifier r of the second bucket i bi Therefore, the first party and the second party can determine the intersection information by securely comparing the bucket identifiers of the B buckets. In other words, the above security calculation can include a one-to-one comparison of the bucket identifiers of the B buckets by the first party and the second party. The first party's B bucket identifiers r a1 to r aB Can be combined with the second party's B bucket information r b1 to r bB The comparison is done one-to-one, and the number of safe comparisons can be B. There are B comparison results, for example, described by a B-dimensional vector or array, and each element in the comparison result of the vector or array corresponds to the comparison result of whether the buckets of the two parties are equal. The comparison results can be constructed and shared between the first party and the second party, such as the first party holds the intersection comparison result shard <hit>1. The second party holds the intersection comparison result shard <hit>2. The value r held by the first party ai and the value r held by the second party bi The safety comparison can be performed using various safety comparison methods in conventional technologies, such as modular safety comparison circuits, etc., which will not be described in detail here.

[0074] In some embodiments, the intersection result can be obtained by the first party, and the second party can <hit>2 is sent to the first party, which recovers the result of the intersection of the two parties based on the shared form, such as <hit> 1、 <hit>In the case of arithmetic slicing, add them together and <hit> 1、 <hit>In the case of Boolean sharding, an XOR operation is performed on it to obtain a vector of 0 and 1 as the intersection result, such as (0, 0, 1, 0, 1, 0), where 1 indicates that the data in the corresponding bucket is intersection data, and 0 indicates non-intersection data.

[0075] The above security comparison can be used as part of the security calculation performed by the first party and the second party to determine the intersection of the full amount of data. This specification also considers situations involving conditional data screening or intersection data fusion processing.

[0076] In this regard, the first party can also identify the second data shard from the first bucket information. Since the first bucket information is determined based on polynomial interpolation in the OPPRF protocol, the second data shard is not necessarily the real second data shard, that is, the first shard. In order to perform data processing without leaking privacy, each second data shard can be regarded as the corresponding first shard of the second data, combined with the local first data, and securely calculated with the second shard of the second data held by the second party to obtain the calculation result. Among them, the second party holds a one-to-one corresponding second data shard for each bucket, so that data calculation can be performed without leaking the intersection data.

[0077] Specifically, secure computations related to data processing may 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 data and the second data to obtain a business processing result. For example, in the business process of user scoring, the first and second parties may employ data fusion secure computations based on a scoring model, and obtain and share the scoring results between the first and second parties. For another example, in the case of screening users who meet predetermined conditions based on user attribute items, secure comparison computations may be employed, and the comparison results may be obtained and shared between the first and second parties.

[0078] In some optional implementations, assuming that the predetermined condition includes multiple parallel conditions that must be met simultaneously, the predetermined condition can be converted into a relationship test, such as greater than, less than, or equal to, between the corresponding attribute values. The relationship test results of each predetermined condition item can be represented by AND, OR, or NOT gate circuits. In this way, the corresponding data can be securely compared to determine whether the predetermined condition is met. The security comparison method can be implemented using conventional security comparison protocols, such as OT-based security comparison algorithms, which will not be detailed here.

[0079] The secure computing process here can be implemented based on the multi-party secure protocol GMW, which supports both Boolean Circuit and arithmetic circuit computations. 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 computation. When filtering users who meet the predetermined conditions based on user attribute items, the arithmetic circuit with a secure comparison strategy can be used for computation. 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 between the first party and the second party for data processing, 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 computations in the sum-sharing form.

[0080] 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 set intersection scenario, the data for which the intersection comparison result is equal and the predetermined conditions hold simultaneously is the final intersection data.

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

[0082] 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. Generally, 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 modulo 2 N of the sum-sharing form, or it can also be in the form of a boolean shard, which is not limited here. The comparison results of multiple condition items can also be represented by 0 or 1, and then the intersection comparison result and the comparison results of each condition item can be implemented through an AND gate circuit.

[0083] Referring to conventional techniques such as "CMSC 858T Secure Distributed Computation, February 4, 2021, Lecture 4", taking the "AND" circuit calculation as an example, assuming 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: .

[0084] 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 result of business preprocessing. 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.

[0085] According to some possible implementation manners, if the data identifier is regarded as an attribute item of the data, then the result of business preprocessing and the intersection comparison result can be fused through a secure AND operation to obtain the sum-sharing form of the result of business processing. The secure AND operation of the intersection comparison result and the result of business preprocessing is ( <hit> 1⊕ <hit>2 The security execution results are not described here. In one embodiment, when the second party provides the second shard of the business processing results to the first party, the first party can obtain the business result values ​​corresponding to each of the B buckets. A value of 0 can be understood as non-intersection data or data filtered out of the intersection. For example, in the SPI circle business scenario, a non-zero value represents a user who meets the criteria and is filtered out of the intersection.

[0086] According to some other possible implementations, the second party can share the fragments of the intersection comparison results it holds <hit>2 Provided to the first party and used by the first party <hit>1 and <hit>2. Determine the buckets corresponding to the intersection data, so as to determine the intersection data first, and decide whether the second party will shard the business preprocessing results according to business needs. Provided to the first party. This way, even if the first party needs to obtain the processing results of the intersection data, it can prevent the 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 may be the business processing result value.

[0087] In addition, if privacy requirements are not high enough, for example, if the intersection number between the first and second parties can be exposed to the second party, the second party can first provide the intersection comparison result to the first party, and the first and second parties will only perform predetermined business processing 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 to perform secure calculations with the second party.

[0088] According to some other possible implementations, the service preprocessing results and the intersection comparison results can be maintained and shared between the two parties, and the first party can obtain the plaintext information of at least one of them as needed, or use it for subsequent security calculations.

[0089] Figure 2 In the illustrated embodiment, based on the OPPRF protocol, data shards are transferred together during the intersection determination process based on bucket identifiers, thereby merging the intersection determination and data processing processes, effectively completing the conditional or data fusion-based intersection determination of private information. Specifically, the first party maps local data identifiers to buckets using cuckoo hashing, with each bucket corresponding to at most one data identifier. The first party performs simple hashing using a consistent hash function using cuckoo hashing, calculates multiple hash values ​​for each data identifier, and maps each hash value to a corresponding bucket. Therefore, if the data corresponding to a single bucket on the first party is intersection data, its corresponding hash value will inevitably be matched by a data identifier hash value corresponding to a corresponding bucket on the other party. Therefore, the second party can construct a data pair 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 based on the data identifier hash value. When both parties execute the OPPRF protocol, the first party can obtain the bucket identifier corresponding to each hash value. 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.

[0090] To perform data calculations, data slices can be passed along with bucket identifiers. The second party constructing the OPPRF protocol data pair (typically the party that cannot access the intersection result) buckets the data and then constructs a data pair using the bucket identifier and the concatenation of the common data slices for each bucket as the value. During the OPPRF protocol execution, the first party obtains both the bucket identifier and the data slices for the intersection data. This allows secure data intersection using bucket identifiers. Furthermore, without leaking the intersection to the second party, passing data slices facilitates secure data processing, such as conditional judgment or data fusion. This provides an effective means of performing intersection calculations with private information attached to judgment or data processing conditions.

[0091] Figure 2 The figure shows the process of exchanging private information between the first party and the second party. Figure 4 The flow of first-party execution to obtain the intersection result is shown, including the following steps:

[0092] Step 401: bucketing n first data identifiers corresponding to n first data using multiple hash functions based on a cuckoo hashing method, and dividing 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;

[0093] Step 402: Based on each first hash value, the OPPRF protocol is executed with the second party. Based on each data pair constructed by the second party, first bucket information corresponding to each first hash value is obtained, wherein each data pair corresponds to each second hash value and a corresponding second bucket identifier. The second bucket identifier corresponding to a single second hash value is determined by the second party bucketing t second data identifiers corresponding to t second data into B buckets based on a simple hash method using multiple hash functions. The single second hash value is determined by performing a hash calculation on the single second data identifier during the bucketing process. The second bucket information includes the bucket identifier and the first shard of the second data corresponding to the corresponding second hash value. The second shard of each second data is retained by the second party. Second data with the same bucket identifier have the same second shard. When the 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.

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

[0095] In one embodiment, in the security calculation, the second party provides each second bucket information and the second slice of each second data, and the first party provides the bucket identifier identified by the first bucket information, the second data slice, and each first data; the security calculation includes a security comparison of the bucket identifier, and at least one of the following: determining whether each first data and each second data meets a predetermined condition; performing fusion business processing on the first data and the second data in the intersection to obtain a business processing result.

[0096] Figure 5 The process performed by the second party that is inconvenient to obtain the intersection result is shown, including the following steps:

[0097] Step 501: bucketing t second data identifiers corresponding to t second data using multiple hash functions based on a simple hashing method, and dividing multiple second hash values ​​corresponding to the t second data identifiers into B buckets, where each second data identifier corresponds to a second hash value determined based on each hash function;

[0098] Step 502: 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 shard of the second data corresponding to the corresponding second hash value. The second shard of each second data is retained by the second party, and second data with the same bucket identifier have the same second shard.

[0099] Step 503: Based on each data pair, the OPPRF protocol is executed with the first party, so that the first party obtains first bucket information corresponding to each first hash value, wherein each first hash value is determined by hash calculation by the first party during a process of bucketing n first data identifiers corresponding to n first data into B buckets based on a cuckoo hashing method using multiple hash functions, where B is greater than n, a single bucket corresponds to at most a single first hash value, and when the 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 504: Based on the second bucket information and the second fragments of the second data, perform security calculation with the first party to determine the intersection of the n first data and the t second data.

[0101] In one embodiment, in the above-mentioned security calculation, the first party provides a bucket identifier, a second data shard, and each piece of first data identified by the first bucket information; the above-mentioned security calculation includes a security 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.

[0102] It is worth mentioning that Figure 4 、 Figure 5 The steps of private information intersection under the technical concept of this specification are described from the perspective of a single participant, which correspond to Figure 2 The first party and the second party are shown. Therefore, Figure 2 The description of the first party and the second party also applies to Figure 4 、 Figure 5 The participants will not be elaborated here.

[0103] In order to clarify the technical concept of this specification, Figure 6 The flowchart of executing the private information intersection request of a specific example under the technical concept of this specification is shown.

[0104] like Figure 6 As shown, the two parties are respectively recorded as the sender and the receiver. Among them, the sender can correspond to Figure 2 The second party in the Figure 2 The first party in the receiver corresponds to the data set X={x1..., x n }, which contains n data x1, x2...x n , the sender has a data set Y={y1……y t }, which contains t data y1, y2...y t .

[0105] In the first step, hash bucketing (Hash-to-Bin) is performed. The receiver performs cuckoo hashing and the bucketing results are in Figure 6 If it is denoted as X B =CuckooH k (X). The result of cuckoo hashing is: the data identifiers corresponding to n data are hashed under multiple hash functions, and according to the cuckoo hashing principle, a single data identifier takes a hash value and maps it to the corresponding bucket. In the privacy information intersection of this specification, a single bucket can correspond to a single hash value of a data at most. Buckets without corresponding hash values ​​can be inserted with random strings. The sender performs a simple hash, such as Y B =SimpleH k (Y). For the data identifier of a single piece of data, each hash value is calculated using the aforementioned multiple hash functions, and each hash value is mapped to a corresponding bucket.

[0106] The second step is to execute OPRF. The receiver provides the hash value or random string in each bucket, and the hash value or random string in the i-th bucket is recorded as a i , the sender provides the encryption key k b , the hash value corresponding to the i-th bucket is recorded as b i Among them, B buckets can correspond to B encryption keys. For example, the encryption key corresponding to the i-th bucket is recorded as k bi . Figure 6 In order to facilitate the diagram, k is used uniformly. b The result of OPRF execution is that the receiver obtains the hash value or random string in B buckets and the encryption key k corresponding to the corresponding bucket of the sender. b Encrypted ciphertext, such as: oprfa i =f(k b , a i ), i represents the bucket number. Correspondingly, the sender can execute the local encryption key k by itself b Perform encryption operations on the hash values ​​corresponding to the local B buckets to obtain the ciphertext of each hash value, such as prfb i =f(k b , b i ), b i Represents the hash values ​​in the i-th bucket.

[0107] In the third step, both parties execute OPPRF. The sender determines the bucket identifier for each bucket, denoted as r b , the same data shard, recorded as the second shard <d b > b Calculate the first fragment of the data corresponding to each hash value in the i-th bucket, denoted as d bi - <d b > b For each hash value in a single bucket, concatenate the bucket identifier with the first fragment of the data, and the result is: b ||d bi - <d b > b , corresponding to the second bucket of information in the previous text. The splicing result is used as the value, prfb i As the Key, construct the (Key, Value) data pair, recorded as (prfb i , r b ||d bi - <d b > b ), the number of data pairs constructed for the i-th bucket is the number of hash values. The sender provides each data pair, and the receiver provides the hash value or random string ciphertext oprfa corresponding to B buckets i The result of OPPRF execution is that the first bucket information is obtained at the receiver, which is recorded as r a ||d b - <d b > b Among them, the receiver obtains the single first bucket information for a single bucket.

[0108] The fourth step is data splitting. The receiver splits the first bucket of information received and obtains the bucket identifiers r corresponding to each of the B buckets. a and data shard d b - <d b > b .

[0109] The fifth step is data identification comparison (Id Compare). It can be understood that when the data identification corresponding to the i-th bucket of the receiver is the intersection of the two parties, the bucket identification r ai The bucket identifier r provided by the sender bi Therefore, compare the B bucket identifiers r obtained by the receiver a and the sender's B bucket identifier r b , the intersection comparison result can be determined. Bucket identifier comparison can be performed by a pre-set secure comparison calculation circuit "GMW Copare", and the execution result is formed and shared in a form including the first shard held by the receiver. <hit>1 and the second shard held by the sender <hit>2. The intersection comparison result hit can be a B-dimensional vector with each dimension being 0 or 1. 1 indicates that the corresponding bucket identifiers are consistent, and 0 indicates that the corresponding bucket identifiers are inconsistent.

[0110] Step 6: Execute the data calculation circuit (GMW Circuit). The data calculation circuit can be a pre-set condition judgment security calculation circuit or a data processing security calculation circuit. For each bucket, the receiver provides the data fragment d obtained by segmentation. b - <d b > b , the sender provides data fragmentation <d b > b The sender does not know which data shard the receiver provides for the corresponding bucket. The data calculation result is composed and shared in the form of the first shard held by the receiver.<res_d> 1 and the second fragment held by the sender <res_d> 2. In the case of conditional judgment, the data calculation result res_d can be a B-dimensional vector with each dimension being 0 or 1, where 1 indicates the condition is met and 0 indicates it is not met. In the case of data fusion processing, res_d is the data processing result, such as the classification result. If res_d is a binary classification result, it can also be a B-dimensional vector with each dimension being 0 or 1, where 1 indicates the first category and 0 indicates the second category.

[0111] Step 7: Execute result fusion. The receiver provides <hit>1 and<res_d> 1. Provided by the sender <hit>2 and<res_d> 2. The two parties jointly determine the fusion result of the intersection comparison result hit and the data calculation result res_d. In the case of conditional judgment, the two parties use the intersection data of the Boolean circuit condition to meet the requirements.

[0112] Recalling the above process, during the private information intersection between the two parties, the first party, as the result-finding party, uses cuckoo hashing to map each piece of local first data to B buckets, with each bucket corresponding to at most a single piece of data. The second party, as the non-result-finding party, uses simple hashing to map each piece of data to B buckets. Therefore, if the first data corresponding to a single bucket of the first party is an intersection piece of data, its corresponding first hash value will inevitably be matched by a second hash value corresponding to the corresponding bucket of the second party. Based on this, the second party constructs a data pair using the second bucket information corresponding to each second hash value. The second bucket information includes a bucket identifier and the first shard of the corresponding second data. The locally stored second shards of the second data corresponding to each bucket are identical. The first party uses the first hash values ​​to execute the OPPRT protocol with the second party. The first party can obtain the first bucket information corresponding to each first hash value. A single first message can identify the corresponding bucket identifier and the second data shard (distinguished from the first and second shards of the second data). Both parties securely compare the bucket identifiers to determine the intersection based on the comparison results.

[0113] Furthermore, regardless of which second hash value in the same bucket identifier of the second party matches the first hash value corresponding to the first party's individual bucket, the corresponding first shard of the second data (i.e., the identified second data shard) is identified, and the second party can provide the corresponding second shard of the second data without knowing which second data was matched. This ensures that the second party's data shard is effectively delivered to the first party, allowing the two parties to jointly conduct secure business processing without leaking the first party's data privacy to the second party. This provides an effective solution for intersection-based business processing in two-party secure computing scenarios.

[0114] According to another aspect of the embodiment, a device for securely processing intersection data that can be located at a single participant is also provided.

[0115] The device for requesting intersection of private information provided on a party that can obtain the intersection data information (e.g., referred to as the first party) includes, for example:

[0116] A bucketing unit is configured to bucket the n first data identifiers corresponding to the n first data based on a cuckoo hashing method using multiple hash functions, and 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;

[0117] A protocol execution unit is configured to execute the OPPRF protocol based on each first hash value and the second party, and obtain 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 the corresponding second bucket identifier, and the second bucket identifier corresponding to a single second hash value is determined by the second party bucketing t second data identifiers corresponding to t second data into B buckets based on a simple hash method through multiple hash functions, and the single second hash value is determined by performing a hash calculation on the single second data identifier in the bucketing process, and the second bucket information includes the bucket identifier and the first shard of the second data corresponding to the corresponding second hash value, and the second shard of each second data is retained by the second party, and the second data with the same bucket identifier has the same second shard, and when the 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;

[0118] The security calculation unit is configured to perform security calculation with the second party based on each first bucket of information to determine the intersection of the n first data and the t second data.

[0119] According to one embodiment, during a secure computation, the second party provides information about each second bucket and the second shard of each piece of second data, and the first party provides a bucket identifier identified by the first bucket information, the second data shard, and each piece of first data. The secure computation includes a secure comparison of the 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 processing on the first and second data in the intersection to obtain a processing result.

[0120] The device for obtaining private information intersection of a party that cannot obtain the intersection data information includes, for example:

[0121] a bucketing unit configured to bucket the t second data identifiers corresponding to the t second data based on a simple hashing method using multiple hash functions, and to divide the multiple second hash values ​​corresponding to the t second data identifiers into B buckets, wherein each second data identifier corresponds to a second hash value determined based on each hash function;

[0122] a data pair construction unit configured to respectively construct data pairs based on second bucket information corresponding to each second hash value, wherein the second bucket information includes a bucket identifier and a first shard of the second data corresponding to the corresponding second hash value, the second shard of each second data being retained by the second party, and second data with the same bucket identifier having the same second shard;

[0123] a protocol execution unit configured to execute the OPPRF protocol with the first party based on each data pair, so that the first party obtains first bucket information corresponding to each first hash value, wherein each first hash value is determined by hash calculation by the first party during a process of bucketing n first data identifiers corresponding to n first data into B buckets based on a cuckoo hashing method using multiple hash functions, where B is greater than n, a single bucket corresponds to at most a single first hash value, and when the 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 security calculation unit is configured to perform security calculation with the first party based on each second bucket information and the second fragment of each second data, and determine the intersection of n first data and t second data.

[0125] In one embodiment, in the above-mentioned security calculation, the first party provides a bucket identifier, a second data shard, and each piece of first data identified by the first bucket information; the above-mentioned security calculation includes a security 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.

[0126] It is worth noting that the above-described devices are respectively Figure 2 The operations performed by the first party and the second party in the illustrated method embodiment correspond to each other, therefore, Figure 2 The corresponding descriptions in the method embodiments are respectively applicable to the devices set on the first party and the second party, and will not be repeated here.

[0127] According to another embodiment, there is also provided a computer readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute a combination of Figure 2 the method described in relation to any party, or Figure 4 、 Figure 5 The method described.

[0128] According to another embodiment, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the system realizes the combination of Figure 2 the method described in relation to any party, or Figure 4 、 Figure 5 The method described.

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

[0130] The specific implementation methods described above further explain in detail the purpose, technical solutions and beneficial effects of the technical concept of this specification. It should be understood that the above is only the specific implementation method of the technical concept of this specification and is not intended to limit the scope of protection of the technical concept of this specification. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the embodiments of this specification should be included in the scope of protection of the technical concept of this specification.< / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit> < / hit>

Claims

1. A method for obtaining private information intersection, comprising: The first party divides n first hash values ​​corresponding to n first data identifiers into B buckets based on multiple hash functions using a cuckoo hashing bucketing algorithm, where the n first data identifiers correspond to n local first data respectively, B is greater than n, and a single bucket corresponds to at most a single first hash value; The second party buckets the t second data identifiers corresponding to the t second data using the multiple hash functions based on a simple hashing method, and divides the multiple second hash values ​​corresponding to the t second data identifiers into B buckets, where each second data identifier corresponds to a second hash value determined based on each hash function; The second party constructs 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 shard of the second data corresponding to the corresponding second hash value, and the second shard of each second data is retained by the second party, and the second data with the same bucket identifier have the same second shard; 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 first bucket information corresponding to each first hash value, wherein, 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; The first party and the second party perform security calculation based on the first bucket information of the first party, the second bucket information of the second party, and the second fragments of each second data to determine the intersection of the n first data and the t second data.

2. The method according to claim 1, wherein The data pair includes an index value and a numerical value. In the data pair corresponding to a single second hash value, the index value is a single second hash value or its ciphertext, and the corresponding numerical value is a concatenation value of the first fragment of the second data corresponding to the corresponding bucket identifier and the corresponding second hash value.

3. The method according to claim 2, wherein: In the case of a ciphertext whose index value in a single data pair is a single second hash value, the first party uses the ciphertext of the first hash value to execute a programmable pseudo-random function protocol with the second party, wherein the second hash value corresponding to the same bucket is encrypted by the second party using the same encryption key to obtain the corresponding ciphertext, and the ciphertext of the first hash value is the ciphertext encrypted by the encryption key corresponding to the corresponding bucket of the second party, and is obtained by the first party and the second party executing the oblivious pseudo-random function protocol.

4. The method according to claim 1, wherein The first party and the second party perform security calculation based on each first bucket information of the first party, each second bucket information of the second party, and the second shard of each second data, and determine that the intersection of the n first data and the t second data includes: The first party identifies the bucket identifier and the data shard from each first bucket information, and when a single first hash value is equal to any second hash value of the second party, the corresponding data shard is the first shard of the second data corresponding to the any second hash value; The first party and the second party perform security calculations according to the bucket identifier, based on the second data shards identified by the first party, each piece of first data, and the second shards of the second data retained by the second party, to determine the intersection of the n first data and the t second data.

5. The method according to claim 4, wherein: The security calculation includes a security 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 a predetermined condition; Perform fusion business processing on the first data and the second data in the intersection to obtain a business processing result.

6. A method for intersecting private information, for a first party and a second party to jointly intersect private information, the method being performed by the first party, comprising: Bucketing the n first data identifiers corresponding to the n first data using multiple hash functions based on a cuckoo hashing method, and dividing 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; Based on each first hash value and the second party, a programmable pseudo-random function protocol is executed, and based on each data pair constructed by the second party, first bucket information corresponding to each first hash value is obtained, wherein each data pair corresponds to each 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 by bucketing t second data identifiers corresponding to t second data into B buckets based on a simple hash method through the multiple hash functions, and the single second hash value is determined by performing a hash calculation on the single second data identifier during the bucketing process, and the second bucket information includes the bucket identifier and the first shard of the second data corresponding to the corresponding second hash value. The second shard of each second data is retained by the second party, and the second data with the same bucket identifier has the same second shard. When the 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 the information of each first bucket, a secure calculation is performed with the second party to determine the intersection of the n first data and the t second data.

7. The method according to claim 6, wherein: In the secure calculation, the second party provides each second bucket information and each second data second slice, and the first party provides the bucket identifier identified by the first bucket information, the second data slice, and each first data; The security calculation includes a security 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 a predetermined condition; Perform fusion business processing on the first data and the second data in the intersection to obtain a business processing result.

8. A method for intersecting private information, for a first party and a second party to jointly intersect private information, the method being performed by the second party, comprising: Bucketing t second data identifiers corresponding to the t second data using the multiple hash functions based on a simple hashing method, and dividing the multiple second hash values ​​corresponding to the t second data identifiers into B buckets, where each second data identifier corresponds 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, respectively, wherein the second bucket information includes a bucket identifier and a first shard of the second data corresponding to the corresponding second hash value, the second shard of each second data being retained by the second party, and second data with the same bucket identifier having the same second shard; Based on each data pair, executing a programmable pseudo-random function protocol with the first party, so that the first party obtains first bucket information corresponding to each first hash value, wherein each first hash value is determined by hash calculation by the first party during a process of bucketing n first data identifiers corresponding to n first data into B buckets based on a cuckoo hashing method through multiple hash functions, where B is greater than n, a single bucket corresponds to at most a single first hash value, and when the 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 the second bucket information and the second fragments of the second data, a security calculation is performed with the first party to determine the intersection of the n first data and the t second data.

9. The method of claim 8, wherein: In the secure calculation, the first party provides a bucket identifier identified by the first bucket information, the second data shard, and each piece of first data; The security calculation includes a security 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 a predetermined condition; Perform fusion business processing on 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, characterized in that: The memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 6 to 9 is implemented.

Images