Method and apparatus for privacy intersection

Abstract

Embodiments of the present specification provide a method and device for privacy intersection, in the process of privacy intersection of multi-party secure calculation, two participants for privacy intersection can encrypt and communicate data in different batches, so that each batch forms a pipeline processing flow. In the process of privacy intersection, the balance between network transmission efficiency and CPU processing efficiency is achieved, so that a single participant can perform encryption calculation on other batches of data while communicating a batch of data in multiple communication cycles, so that CPU calculation and network transmission resources are fully utilized, and the hardware utilization rate and the efficiency of privacy intersection are improved.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to methods and apparatus for privacy-preserving intersection. Background Technology

[0002] Secure multi-party computation (MPC), also known as secure multi-party computation, involves multiple parties collaboratively computing a function without revealing their input data. The result is disclosed to one or more parties. This achieves the goal of "data usable but not visible," enabling the "flow of data value." A typical application of secure MPC is privacy-set intersection (PSI). PSI can be understood as determining the intersection of data among multiple parties while protecting privacy. PSI is often central to multi-party collaborative training of machine learning and other business processes. The core idea of ​​PSI is that at the end of the protocol interaction, one or more parties should obtain the correct intersection without receiving any data from other parties' data sets outside the intersection. During privacy-set intersection, the time cost of data processing and communication directly impacts the processing efficiency of the corresponding business. Summary of the Invention

[0003] This specification describes one or more embodiments of a privacy-preserving intersection method and apparatus to address one or more problems mentioned in the background art.

[0004] According to the first aspect, a privacy-preserving intersection method is provided for determining the intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; the method includes: the first party determining the first batch of first data P based on its local private key Ka. 11 The first party provides a ciphertext to the second party; the first party and the second party jointly perform the following batch-by-batch alternating encryption operation: the second party obtains the first data P of the i-th batch from the first party. i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext, and provided to the first party with P i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The second ciphertext, the first party receives P from the second party i2 Simultaneously with the ciphertext, determine the first data P(of the (i+1)th batch). i+1 A ciphertext of 1 is provided to the second party in the form of P( i+1 Simultaneously with ciphering 1, P is determined based on the local private key Ka. i2The first party provides the second party with the second ciphertext of all the first data after completing the second ciphertext calculation of all batches of the first data. The first party then compares the second ciphertext of each first data with the second ciphertext of each second data to determine the intersection of the first data and the second data. Alternatively, the first party provides the second party with the second ciphertext of all the second data after completing the second ciphertext calculation of all batches of the second data. The second party then compares the second ciphertext of each first data with the second ciphertext of each second data to determine the intersection of the first data and the second data.

[0005] In one embodiment, the method further includes: before encrypting the first data and the second data in batches, the first party and the second party each perform hash calculations on their local first data / second data, and take the modulo of each hash value obtained by the number of buckets n, thereby performing bucketing processing on the local first data / second data, wherein the number of buckets n is determined by negotiation between the two parties, and the same data in the first data and the second data are assigned to the corresponding buckets.

[0006] In a further embodiment, the number of buckets n satisfies the following condition: the time difference between encrypting a single batch of data and transmitting a single batch of data is less than a predetermined threshold.

[0007] In another further embodiment, the first / second data of a single batch includes k data entries from each of n buckets.

[0008] In a further embodiment, when the first party and the second party encrypt the first data / second data or its ciphertext for a single batch, they use n processes in parallel, with each process corresponding to a single bucket.

[0009] In yet another embodiment, the comparison of the secondary ciphertext of each first data and the secondary ciphertext of each second data by the first party or the second party includes: comparing the secondary ciphertext of each first data and the secondary ciphertext of each second data in the corresponding pairwise bins of the first party and the second party.

[0010] In one embodiment, the first party and the second party encrypt the first data / second data or its primary ciphertext for a single batch in the following manner: mapping the first data / second data or its primary ciphertext to points on an elliptic curve; the first party / second party performs a dot product of its private key Ka / private key Kb with the corresponding points on the elliptic curve to obtain the primary or secondary ciphertext of the first data / second data.

[0011] In one embodiment, when the second party provides the first party with the secondary ciphertext of all the first data, the first party encrypts the primary ciphertext of the last batch of second data at the same time as the second party provides the secondary ciphertext of all the first data to obtain the secondary ciphertext of the corresponding second data.

[0012] In one embodiment, the first party determines the first data P of the first batch based on its local private key Ka. 11 While the first party sends a ciphertext, the second party remains dormant.

[0013] According to the second aspect, a privacy-preserving intersection method is provided for determining the data intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; the method is executed by the first party and includes: determining the first batch of first data P based on a local private key Ka. 11 A ciphertext is provided to the second party; in conjunction with the second party, an alternating encryption operation is performed on a batch basis, wherein, upon receiving the second data P of the i-th batch from the second party... i2 Simultaneously with the ciphertext, determine the first data P(of the (i+1)th batch). i+1 A ciphertext of 1 is provided to the second party in the form of P( i+1 Simultaneously with ciphering 1, P is determined based on the local private key Ka. i2 The ciphertext is a natural number i. The ciphertext is obtained from the second party. All the ciphertexts of the first data are received from the second party. The ciphertexts of each first data are compared with the ciphertexts of each second data to determine the intersection of the first data and the second data. Alternatively, after the ciphertexts of all batches of the second data have been calculated, the ciphertexts of all the second data are provided to the second party so that the second party can determine the intersection of the first data and the second data based on the comparison of the ciphertexts of each first data and the ciphertexts of each second data.

[0014] In one embodiment, the method further includes: before encrypting the first data in batches, performing a hash calculation on the local first data / and taking the modulo of each hash value obtained by the number of buckets n, thereby performing bucketing processing on the local first data, wherein the number of buckets n is determined by negotiation between the two parties.

[0015] In a further embodiment, the first data / second data of a single batch includes k data entries from each of n buckets. When encrypting the first data of a single batch, n processes are used in parallel, with each process corresponding to a single bucket.

[0016] According to a third aspect, a privacy-preserving intersection method is provided for determining the data intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; the method is executed by the second party, including: responding to receiving a first batch of first data P determined by the first party based on its local private key Ka. 11 A ciphertext is obtained, and the following batch-based alternating encryption operation is performed jointly with the first party: Upon obtaining the first data P of the i-th batch from the first party... i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext is provided to the first party in connection with providing P to the first party. i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The method further includes: firstly, encrypting the second data in batches, where i is a natural number; secondly, encrypting all the first data in batches, and providing the first party with all the second data in batches, so that the first party can determine the intersection of the first data and the second data by comparing the second data in batches of the first data and the second data in batches of the second data; or, receiving all the second data in batches of the second data from the first party and determining the intersection of the first data and the second data in batches of the second data by comparing the second data in batches of the first data and the second data in batches of the second data. In one embodiment, the method further includes: before encrypting the second data in batches, performing a hash calculation on the local second data and taking the modulo of each hash value obtained by the number of buckets n, thereby performing bucketing on the local second data, wherein the number of buckets n is determined by negotiation between the two parties.

[0017] In a further embodiment, the second data of a single batch includes k data entries from each of n buckets. When encrypting the second data of a single batch, n processes are used in parallel, with each process corresponding to a single bucket.

[0018] According to the fourth aspect, a privacy intersection determination apparatus is provided for determining the data intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; the apparatus is disposed on the first party and includes a communication unit and an encryption unit, wherein:

[0019] The encryption unit is configured to determine the first data P of each batch based on the local private key Ka. 11 A ciphertext is provided to the second party via the communication unit; and

[0020] In conjunction with a second party, a batch-alternating encryption operation is performed, wherein, upon receiving the second data P of the i-th batch from the second party via the communication unit... i2 Simultaneously with the ciphertext, determine the first data P(of the (i+1)th batch).i+1 A ciphertext of 1 is provided to the second party via the communication unit. i+1 Simultaneously with ciphering 1, P is determined based on the local private key Ka. i2 The ciphertext is a quadratic ciphertext, where i is a natural number;

[0021] The communication unit is further configured to receive the secondary ciphertext of all the first data from the second party, or, after completing the secondary ciphertext calculation of all batches of the second data, provide the secondary ciphertext of all the second data to the second party.

[0022] When the communication unit is configured to receive the secondary ciphertext of all first data from a second party, the device further includes a comparison unit configured to compare the secondary ciphertext of each first data with the secondary ciphertext of each second data, thereby determining the intersection data of the first data and the second data.

[0023] According to the fifth aspect, a privacy intersection determination apparatus is provided for determining the data intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; the apparatus is disposed on the second party and includes a communication unit and an encryption unit, wherein:

[0024] The encryption unit is configured to respond to the communication unit receiving a first batch of first data P determined by the first party based on its local private key Ka. 11 The encrypted data is then jointly encrypted with the first party in batches, performing the following alternating encryption operation: upon receiving the first data P of the i-th batch from the first party via the communication unit... i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext is provided to the first party in one instance, and P is provided to the first party through the communication unit. i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The ciphertext is a quadratic ciphertext, where i is a natural number;

[0025] The communication unit is further configured to, after completing the secondary ciphertext calculation of all batches of first data, provide the secondary ciphertext of all first data to the first party, or receive the secondary ciphertext of all second data from the first party.

[0026] When the communication unit is configured to receive the secondary ciphertext of all the second data from the first party, the device further includes a comparison unit configured to compare the secondary ciphertext of each first data with the secondary ciphertext of each second data, thereby determining the intersection data of the first data and the second data.

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

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

[0029] The methods and apparatus provided in the embodiments of this specification enable privacy intersection in multi-party secure computation, where each participating party performs privacy intersection on its corresponding data in a multi-ciphertext form (secondary ciphertext) encrypted with two-party keys. Furthermore, since each batch of data requires double encryption with two-party keys, encryption processing and ciphertext exchange can be performed alternately. To this end, a reference value is set based on the data processing and communication capabilities of the two data-handling devices to determine the data size of a single batch. This allows either party to simultaneously perform encryption processing and ciphertext transmission during the intermediate stages of the privacy intersection process, fully utilizing computing and network transmission resources and improving hardware utilization.

[0030] In an optional implementation, the two data parties performing privacy intersection can take the modulo of the hash value of each piece of local data with a predetermined reference value, thereby dividing the data into buckets according to the modulo value. This allows the two data parties to perform parallel batch encryption processing of the data in each bucket in a secure manner, further improving data processing efficiency. Attached Figure Description

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

[0032] Figure 1 A schematic diagram illustrating a privacy-preserving intersection implementation architecture, representing a specific example of conventional techniques.

[0033] Figure 2 A sequence diagram illustrating a specific example of a privacy-seeking two-party interaction based on the technical concept described herein is provided.

[0034] Figure 3 A flowchart illustrating a privacy-preserving intersection method implemented by one party according to one embodiment is shown;

[0035] Figure 4 A flowchart illustrating a privacy-preserving intersection method implemented in another party according to one embodiment is shown;

[0036] Figure 5 A schematic block diagram of a privacy-seeking intersection device provided on one of the parties according to one embodiment is shown. Detailed Implementation

[0037] The technical solutions provided in this specification are described below with reference to the accompanying drawings.

[0038] First, let's describe a privacy intersection scenario involving two parties. The goal of privacy intersection is to allow at least one party to obtain the intersection of their business data—that is, identical or corresponding business data—without revealing the privacy of each other's local business data. For example, if the business data is bank credit data, two banks can be the two parties in the privacy intersection, and the determined data intersection can be the same user. Bank users can be identified, for example, by mobile phone numbers, identification codes, etc. Accordingly, the data intersection can be determined through secure matching of identifiers such as mobile phone numbers and identification codes. As a concrete example, suppose A and B are the two parties. Party A holds a set of data X, corresponding to data identifiers (such as user identification codes) X1 to X... n Party B holds a set of data Y, corresponding to data identifiers (such as user identification codes) Y1 to Y2. m Then, X1 to X are determined in a safe manner. n With Y1 to Y m The same elements in the intersection are disclosed to one or both of A and B, but neither party can know any other data outside the intersection of the other parties.

[0039] Figure 1 A schematic diagram of an implementation architecture for privacy-preserving intersection is shown. Figure 1As shown, assuming the first party holds multiple pieces of first data and the second party holds multiple pieces of second data, to determine the intersection of the first and second data, the first party can also hold a private key Ka, and the second party can hold a private key Kb. Let the first data be denoted as IDa and the second data as IDb. In the privacy intersection process, the first party can first encrypt its local first data, denoted as Ka(IDA). In practice, to further protect data privacy, the first data can also be anonymized, such as by performing hash calculations to obtain the corresponding hash values, denoted as H(IDA). The result of encrypting the local first data is then denoted as Ka(H(IDA)). The following description uses the encryption result of the first data, denoted as Ka(H(IDA)), as an example. This encryption result is encrypted using the key of either the first or second party, and is called the first ciphertext. Next, the first party can send the first ciphertext Ka(H(IDA)) of the first data to the second party. The second party receives the first ciphertext Ka(H(IDA)) of the first data and encrypts it a second time using its private key Kb, obtaining the second ciphertext KbKa(H(IDA)). On the other hand, the second party can also encrypt each piece of second data locally using its private key Kb to obtain the first ciphertext Kb(H(IDb)). Thus, the second party can provide the first party with the first ciphertext Kb(H(IDb)) of the second data and the second ciphertext KbKa(H(IDa)) of the first data. The first party can then encrypt the first ciphertext Kb(H(IDb)) of the second data using its private key Ka to obtain the second ciphertext KaKb(H(IDb)).

[0040] At this point, the first party holds the secondary ciphertext KbKa(H(IDa)) of the first data and the secondary ciphertext KaKb(H(IDb)) of the second data. To ensure that the same data identifier (such as IDa) is used... i and IDb i If the ciphertexts of (H(IDa)) and (H(IDb)) are identical, an elliptic curve cryptography algorithm can be used. IDa and IDb are mapped to points on an elliptic curve using ECC hashing, denoted as (H(IDa)) and (H(IDb)). The private keys Ka and Kb encrypt the points (H(IDa)) and (H(IDb)) on the elliptic curve using a dot product operation. In other words, the first ciphertext is encrypted by Ka / Kb dot product of (H(IDa)) or (H(IDb)), and the second ciphertext is encrypted by Ka / Kb dot product of the first and second ciphertexts. According to the principles of elliptic curve cryptography, the dot product result can still correspond to a point on the elliptic curve.

[0041] Thus, based on the properties of elliptic curve cryptography, the order of dot product is commutative; for example, for a point A on the elliptic curve, KaKb(A) = KbKa(A). Therefore, for the same data identifier (such as IDa), the product order is commutative. iThe ciphertext encrypted sequentially by Ka and Kb is identical to the ciphertext encrypted sequentially by Kb and Ka. Furthermore, by comparing the ciphertext KbKa(H(IDa)) of the first data with the ciphertext KaKb(H(IDb)) of the second data, the first party can determine the intersection of the ciphertext forms of each piece of first data and each piece of second data. For example, KbKa(H(IDa)) i )) and KaKb(H(IDb i Under the condition that they are consistent, IDa i and IDb i They are the same data identifier, and the corresponding first and second data belong to the intersection of the data.

[0042] Thus, the first party can obtain the intersection of the plaintexts based on the line number or other data identifier corresponding to the secondary ciphertext of the first data. Subsequently, depending on business needs, the first party may hold the intersection data alone, or provide the plaintext form of the intersection data to the second party; this specification does not impose any restrictions on this.

[0043] The above process involves significant CPU computation, disk reads, and network transmission (during data exchange between the two parties). With large data volumes, the time cost increases accordingly. To improve the efficiency of privacy-based intersection processing, this specification adopts the following technical concept: Data is segmented, dividing the massive dataset into multiple smaller batches; then, the datasets are processed in batches, implementing a pipelined approach for serial data processing; within each batch, data processing and transmission are synchronized through multiple processes, optimizing the data processing flow within the serial process, thereby achieving resource optimization throughout the entire pipeline. This saves time and improves the efficiency of privacy-based intersection.

[0044] Figure 2This document illustrates an implementation architecture for a specific example of the technical concept described herein. The architecture, presented sequentially, illustrates the interaction sequence of two data parties (referred to as Party 1 and Party 2) performing a privacy intersection. During the privacy intersection process, it is assumed that Party 1 holds N pieces of first data, and Party 2 holds M pieces of second data. This document does not limit the values ​​of the positive integers M and N, and the technical concept provided herein is particularly applicable when M and N are large integers (e.g., 1 billion). Here, the first and second data can be unique data identifiers or data fields describing relevant business data. For example, in a learning scenario involving splitting data, the first and second data can be data identifiers such as sample identifiers, like a user identification code or mobile phone number when one user corresponds to one sample. In a query scenario, the first and second data can be data fields corresponding to query conditions, such as data fields for purchasing school supplies like erasers, pencils, pens, notebooks, and exercise books. To encrypt the first and second data, Party 1 can generate a local private key Ka, and Party 2 can generate a local private key Kb. Based on this, the following section... Figure 2 The interactive flow shown in this specification describes the technical concept in detail.

[0045] like Figure 2 As shown, the two parties determine the encrypted data in batches. Specifically, this can be done by one party (such as...). Figure 2 The example shown is that the first party calculates the first batch of local data ciphertext and sends it to the other party. During the data communication between the two parties, the other party simultaneously calculates the ciphertext form of its local data and transmits it to the first party. During data transmission, both parties also perform encryption calculations simultaneously.

[0046] Specifically, the first party determines the first data P of the first batch based on its local private key Ka. 11 The first party provides a ciphertext to the second party; the first party and the second party jointly perform the following batch-by-batch alternating encryption operation: the second party obtains the first data P of the i-th batch from the first party. i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext, and provided to the first party with P i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The second ciphertext, the first party receives P from the second party i2 Simultaneously with the ciphertext, determine the first data P(of the (i+1)th batch). i+1 A ciphertext of 1 is provided to the second party in the form of P( i+1 Simultaneously with ciphering 1, P is determined based on the local private key Ka. i2The second party provides the first party with the second ciphertext of all the first data after completing the second ciphertext calculation of all batches of the first data. The first party compares the second ciphertext of each first data with the second ciphertext of each second data to determine the ciphertext intersection of the second ciphertext of the first data and the second data, and provides the second party with the first ciphertext of each second data corresponding to the ciphertext intersection. The second party obtains the plaintext intersection of the first data and the second data based on the first ciphertext of each second data corresponding to the ciphertext intersection.

[0047] In an optional implementation, before the two parties receive the encrypted local data in batches, the first and second parties can agree on the number of data buckets, n, and each divide their local data into n buckets. Thus, the first party distributes N pieces of first data into n buckets, and the second party distributes M pieces of second data into n buckets. During the bucketing process, to ensure a relatively even distribution of data across buckets, the local data can be hashed according to a predetermined hash calculation method, and the hash value can be modulo n. Data with the same modulo value correspond to the same bucket identifier, meaning they fall into the same bucket. Furthermore, since two slightly different pieces of data can yield significantly different results in hash calculations, modulo hashing helps to ensure a relatively even distribution of data across buckets. In an optional embodiment, to further ensure a more even distribution of data across buckets, the first and second parties can perform a second hash calculation on the hash value of the local data, such as ID. i The result of performing two hash calculations in sequence can be denoted as H1(H2(ID)). i The encryption computation is performed in a multi-process parallel manner.

[0048] Figure 2 The interaction sequence diagram shown is based on the data bucketing by both parties, therefore, for Figure 2 The description uses a bucketed scenario as an example. In practice, it is possible that bucketing is not necessary, and only batch-based encrypted interactions are performed.

[0049] by Figure 2 As shown in the example, the first party can first calculate the ciphertext of the first batch of data locally based on the private key Ka. In the case of data bucketing, a single data party can encrypt the data in each bucket in parallel. Therefore, the first batch of data can include a predetermined number (e.g., k) of data from each bucket. For n buckets, there are nk first data entries. The ciphertext of the first batch of data is denoted as Ka(H(IDa)). 1～k Among them, H(IDa) i ) is a single first data IDA i The result of ECC hashing (IDa) i The hash value is mapped to the point on the elliptic curve), Ka(H(IDa)1～k )) is composed of Ka and H(IDa) i The result obtained by performing a dot product on Ka(H(IDa)). 1～k A point can be located on an elliptic curve. ECC hashing is a standard technique and will not be elaborated upon here. The first party can use n processes to compute, in parallel, the ciphertext of the first k data items in n buckets based on the private key Ka (data encrypted once with the private key).

[0050] Afterwards, the first party can send the first batch of first data, encrypted with private key Ka, to the second party. During this communication, the first party is the sender and the second party is the receiver, both utilizing network communication resources. For computing devices, computing resources and network communication resources are usually independent. Therefore, computing resources can be fully utilized while communicating. For the first party, since it has not yet received the encrypted data related to the second batch of data, its computing resources are not limited during communication; for example, it can handle other tasks, remain idle (sleep), or process the first data of the second batch (such as the (k+1)th to 2kth data items in each bucket) to obtain its encrypted data. Figure 2 In the example shown, the first data of the second batch is not processed at this time. On the other hand, the second party can process the second data of the first batch (such as the first to k data in each bucket) in parallel using the private key Kb, to obtain the ciphertext of the second data of the first batch, denoted as Kb(H(IDb)). 1～k The encryption process for the second data is similar to that for the first data, and will not be described in detail here.

[0051] Next, the second party can provide the first party with the ciphertext of the first batch of second data. During the communication between the two parties, the first party can use its local computing resources to determine the ciphertext of the first batch of first data in parallel, based on its private key Ka. Meanwhile, the second party has already received the ciphertext of the first batch of first data. At this point, it can simultaneously use its local computing resources to determine the secondary ciphertext of the first batch of first data in parallel, based on its private key Kb, as denoted as KbKa(H(IDa)). 1～k )).

[0052] Upon completion of communication, the first party receives the first ciphertext of the second batch of data based on Kb, and simultaneously calculates the first ciphertext of the second batch of data based on Ka. Then, on one hand, while sending the first ciphertext of the second batch of data to the second party, the first party can use n processes to encrypt the first ciphertext of the second batch of data in n buckets using Ka, obtaining the second ciphertext of the second batch of data. On the other hand, the second party can simultaneously determine the first ciphertext of the second batch of data based on Kb while receiving the first ciphertext of the second batch of data. Upon completion of communication, the encryption process for both parties is finished.

[0053] Furthermore, the second party provides the first party with a second batch of second data, which is a first ciphertext based on Kb. Simultaneously, the first party uses n processes to determine the first batch of first data in n buckets, which is a first ciphertext based on Ka. Meanwhile, the second party simultaneously encrypts the first batch of first data in the second batch based on Ka using Kb, resulting in a second batch of first data based on Ka and Kb.

[0054] Similarly, assuming a single bucket's data can be divided into L batches, when the second party provides the first party with the first ciphertext of the second data in the Lth batch based on Kb, the first party can simultaneously determine the second ciphertext of the second data in the (L-1)th batch, and the second party can simultaneously determine the second ciphertext of the first data in the Lth batch. In practice, if one party has less data than the other, and when calculating a batch of data from the party with more data, the other party's data has already been fully calculated, then that party only performs the calculation of the sequential ciphertext of its local data, while the other party only performs communication and the second ciphertext calculation of the data from the party with more data, allowing for spare computing resources.

[0055] Understandably, in actual business needs, the intersection data can be obtained by either the first party or the second party. The party needing the intersection data can determine the intersection data by comparing the secondary ciphertext of the first data and the secondary ciphertext of the second data, and then determine the plaintext of the intersection based on data identifiers such as the row number corresponding to the secondary ciphertext of the local data.

[0056] Figure 2 An example is shown where the intersection data is obtained from the first party. For example... Figure 2As shown, after the second party has fully completed the secondary ciphertext calculation of the first data for each batch, it can send them to the first party. Simultaneously, the first party can determine the secondary ciphertext of the second data for the Lth batch. Since the second party needs to send the secondary ciphertext of all the first data in this communication cycle, its required communication time may be much longer than the first party's calculation time. Upon completion of communication, the first party holds the secondary ciphertext of the first data for each batch, as well as the secondary ciphertext of the second data for each batch. By comparing the secondary ciphertexts of the first and second data, the first party can determine the intersection data.

[0057] Similarly, if the intersection data is needed from the second party, the first party can send the second data to the second party after completing the secondary ciphertext calculation of each batch of second data. The second party can then compare the first data and the secondary ciphertext of the second data to determine the intersection data.

[0058] In the case of bucketing, since identical data has the same hash value and the same number of buckets, the same data from both parties is assigned to corresponding buckets (such as two buckets corresponding to the same modulus). Thus, the intersection of the ciphertexts can be determined by comparing the secondary ciphertexts of the first and second data in the corresponding buckets of both parties, thereby reducing the amount of data processing.

[0059] from Figure 2 It can be seen that, apart from the initial small batches and the subsequent secondary encrypted communication process, the first and second parties can communicate and calculate simultaneously during the calculation of other intermediate batches, which makes full use of the device's computing and communication resources and improves the efficiency of privacy intersection.

[0060] The key to implementing this pipeline format lies in determining the quantity of data in a single batch. To ensure consistency between communication duration and data processing duration, the quantity of data in a single batch can be determined based on CPU processing efficiency and network transmission efficiency (such as bandwidth). Assuming the data processing time for one batch is T1 and the data processing time for another batch is T2, under the condition that T1≈T2≈T (the time difference between encrypting a single batch of data and transmitting a single batch of data is less than a predetermined threshold), the resource utilization of both the first and second parties is maximized, resulting in the lowest time cost.

[0061] In one embodiment, assuming that the CPU efficiency of one device in processing data is s data points per second, the processing time for one data point is 1 / s second, the processing time for k data points is T1 = k / s second, the length of a single data point is p bits, and the network transmission efficiency is q bits per second, then the transmission time for k data points is T2 = kp / q. Thus, if the two participating devices satisfy s = q / p, k can be any reasonable data, such as a common divisor of N and M.

[0062] In another embodiment, a parallel processing approach can be used for a single batch of data. In this case, the number of parallel processes, *m*, is a crucial parameter for ensuring that T1≈T2≈T. Assuming that the processing time for one data item remains constant under parallel processing conditions, such as 1 / s, then the processing time for k data items is T1 = k / ms. To ensure T1 = T2, given *k / ms* = *kp / q*, we know that *m* = *q / ps* is required. That is, by setting the number of parallel processes *m* = *q / ps*, the pipeline optimization concept described in this specification can be achieved. In another example, when the data volume is large and bucketing is required, the number of processes *m* can be the same as the number of buckets, *n*. Assuming that a single batch of data includes k data items from each bucket (a total of *nk* data items), the processing time for k data items is T1 = k / s, the length of a single data item is *p* bits, and the network transmission efficiency is *q* bits per second. Therefore, the transmission time for *nk* data items is T2 = *nkp / q*. To ensure T1 = T2, the number of buckets *n* needs to satisfy: *nps* = *q*, i.e., *n* = *q* / ps.

[0063] refer to Figure 2 It can be seen that in the first cycle T of the privacy intersection, the first party can simultaneously determine the ciphertext of the first batch of data in the first batch of n buckets. In the second cycle 2T, it can send the ciphertext of the first batch of data to the second party. After that, for the first party, similar operations are performed every two adjacent cycles, to process the first data of the i-th batch and receive the ciphertext of the second data of the (i-1)-th batch in cycle (2i-1)T, and to process the second data of the (i-1)-th batch and send the ciphertext of the first data of the i-th batch in cycle 2iT, where i is a natural number greater than 1. In other words, when i is a natural number greater than 1 and less than L, there must exist at least two periods (2i-1)T and period 2iT: In period (2i-1)T, the first party receives the first ciphertext of the second data in the (i-1)th batch, and at the same time, determines the first ciphertext of the first data in the i-th batch in n buckets; In period 2iT, the first party sends the first ciphertext of the first data in the i-th batch to the second party, and at the same time, encrypts the first ciphertext of the second data in the (i-1)th batch in n buckets to obtain the second ciphertext.

[0064] In contrast, when j is a natural number greater than 1 and less than L, the second party must have at least two adjacent periods (2j-1)T and period 2jT. During period (2j-1)T, while receiving the ciphertext of the first data in the j-th batch, the second data in the first batch corresponding to n buckets is simultaneously determined. During period 2jT, while sending the ciphertext of the second data in the j-th batch to the first party, the second ciphertext of the first data in the j-th batch within the n buckets is simultaneously determined. Combined with... Figure 2It can be seen that the correspondence between i and j is i = j + 1, and the period (2i-1)T of the first party corresponds to the period 2jT of the second party. That is to say, the second party receives the first batch of data P from the first party. i1 Simultaneously with processing the encrypted data, the second data P of the i-th batch is processed locally. i2 Having obtained its first encrypted message, the second batch of data P is provided to the first party in the i-th batch. i2 At the same time as encrypting the ciphertext, the first data P of the i-th batch is also encrypted. i1 One encrypted message obtained P i1 The secondary ciphertext.

[0065] Thus, in such Figure 2 In the pipeline-style data processing flow shown, computing and communication resources are fully utilized in each cycle T, improving hardware utilization and thus increasing the efficiency of privacy-preserving intersection.

[0066] exist Figure 2 The illustrated embodiment describes the implementation process of a specific example under the implementation architecture of this specification based on the interaction between the first and second parties. For a single data party performing privacy intersection, such as Figure 2 The first or second party in the agreement can perform operations as follows: Figure 3 or Figure 4 As shown. Among them, Figure 2 The terms "First Party" and "Second Party" are used only to distinguish between the two data parties and do not substantially limit the technical solution. The operation of the First Party and the Second Party differs slightly, and the two parties need to cooperate to complete the technical concept of this specification.

[0067] For the sake of convenience, let's assume... Figure 3 The party performing the operation shown is the first party. Figure 4 The operation shown is performed by the second party.

[0068] but Figure 3 The process executed by the first party in the privacy-sensitive interaction process shown includes:

[0069] Step 301: Determine the first data P of the first batch based on the local private key Ka. 11 A ciphertext is provided to the second party;

[0070] Step 302: Jointly perform batch-based alternating encryption operations with the second party, wherein, upon receiving the second data P of the i-th batch from the second party... i2 Simultaneously with the ciphertext, determine the first data P(of the (i+1)th batch). i+1 A ciphertext of 1 is provided to the second party in the form of P( i+1 Simultaneously with ciphering 1, P is determined based on the local private key Ka. i2 The ciphertext is a quadratic ciphertext, where i is a natural number.

[0071] Subsequently, depending on the business requirements, whether to obtain the intersection data for the first party or the second party, the following steps 304 or 304 can be executed respectively.

[0072] If the first party obtains the intersection data, in step 303, after the second party has completed the secondary ciphertext calculation of all batches of the first data, the second party receives all the secondary ciphertexts of the first data from the second party, and compares the secondary ciphertexts of each first data with the secondary ciphertexts of each second data to determine the intersection data of the secondary ciphertexts of the first data and the second data.

[0073] If the second party obtains the intersection data, in step 304, after completing the secondary ciphertext calculation of all batches of the second data, the second party is provided with the secondary ciphertext of all the second data, so that the second party can determine the intersection data of the first data and the second data by comparing the secondary ciphertext of each first data and the secondary ciphertext of each second data.

[0074] Depending on an optional implementation, Figure 3 The illustrated process may also include: before encrypting the first data in batches, performing a hash calculation on the local first data / and taking the modulo of each hash value obtained by the number of buckets n, thereby performing bucketing processing on the local first data, wherein the number of buckets n is determined by negotiation between the two parties.

[0075] In one embodiment, the first / second data of a single batch includes k data entries from each of n buckets. When encrypting the first data of a single batch, n processes are used in parallel, with each process corresponding to a single bucket.

[0076] The operational procedures performed by the second party are the same as those of the first party, and will not be repeated here. For example... Figure 4 As shown, the process executed by the second party includes:

[0077] Step 401, in response to receiving the first batch of first data P determined by the first party based on its local private key Ka. 11 A ciphertext is obtained, and the following batch-based alternating encryption operation is performed jointly with the first party: Upon obtaining the first data P of the i-th batch from the first party... i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext is provided to the first party in connection with providing P to the first party. i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The ciphertext is a quadratic ciphertext, where i is a natural number;

[0078] Subsequently, depending on the business requirements, whether to obtain the intersection data for the first party or the second party, the following steps 402 or 403 can be executed respectively.

[0079] If the first party needs to obtain the intersection data, in step 402, after completing the secondary ciphertext calculation of all batches of the first data, the second ciphertext of all the first data is provided to the first party so that the first party can compare the secondary ciphertext of each first data with the secondary ciphertext of each second data to determine the intersection data.

[0080] On the other hand, if the second party needs to obtain the intersection data, it can receive the secondary ciphertext of all the second data from the first party through step 403, and determine the intersection data of the first data and the second data based on the comparison of the secondary ciphertext of each first data and the secondary ciphertext of each second data.

[0081] Based on a possible design, Figure 4 The illustrated process may also include:

[0082] Before encrypting the second data in batches, the local second data is hashed, and each hash value is modulo the number of buckets n to perform bucketing on the local second data. The number of buckets n is determined by negotiation between the two parties.

[0083] In one embodiment, the second data of a single batch includes k data entries from each of n buckets. When encrypting the second data of a single batch, n processes are used in parallel, with each process corresponding to a single bucket.

[0084] Understandable. Figure 2 This illustrates a privacy-preserving intersection process for two-party interactions in one embodiment of the implementation architecture described in this specification. Figure 3 The illustrated embodiments describe Figure 2 The first-party operation performed in the process Figure 4 The illustrated embodiments describe Figure 2 The operation performed by the second party in the process, therefore, for Figure 2 The description of the corresponding data source also applies. Figure 3 , Figure 4 The process shown will not be repeated here.

[0085] Based on the embodiments described above, the privacy intersection method provided in this specification allows each participating party to perform privacy intersection on their corresponding data in a multi-ciphertext form (secondary ciphertext) encrypted with two-party keys during the privacy intersection process of multi-party secure computation. Furthermore, since each batch of data requires double encryption with two-party keys, the encryption processing and ciphertext exchange processes can be performed alternately. Therefore, a reference value is set based on the data processing and communication capabilities of the two data-handling devices to determine the data volume of a single batch, enabling either party to simultaneously perform encryption processing and ciphertext transmission during the intermediate period of the privacy intersection process, fully utilizing computing and network transmission resources and improving hardware utilization.

[0086] According to another embodiment, a privacy intersection apparatus is also provided. This apparatus is used for two data parties to perform a privacy intersection during a multi-party secure computation process. The privacy intersection apparatus can be located on one of the two data parties performing the privacy intersection (e.g., ...). Figure 2 (The first or second party in the process). The two data parties performing privacy intersection can also be viewed as a system performing privacy intersection. Figure 5 A privacy-based intersection apparatus 500 according to one embodiment is shown. Figure 5 As shown, the device 500 includes a communication unit 501 and an encryption unit 502.

[0087] Among them, device 500 is located in Figure 2 In the case of the first-party device shown:

[0088] Encryption unit 502 is configured to determine the first data P of each batch based on the local private key Ka. 11 A ciphertext is provided to the second party via communication unit 501; and

[0089] In conjunction with the second party, a batch-based alternating encryption operation is performed, wherein the second data P of the i-th batch is received from the second party via communication unit 501. i2 Simultaneously with the ciphertext, determine the first data P(of the (i+1)th batch). i+1 The encrypted text of )1 is provided to the second party via communication unit 501. i+1 Simultaneously with ciphering 1, P is determined based on the local private key Ka. i2 The ciphertext is a quadratic ciphertext, where i is a natural number;

[0090] The communication unit 501 is further configured to receive the secondary ciphertext of all the first data from the second party when the second party has completed the secondary ciphertext calculation of all batches of the first data, or to provide the secondary ciphertext of all the second data to the second party when the secondary ciphertext calculation of all batches of the second data has been completed.

[0091] In the case where the communication unit 501 is configured to receive the secondary ciphertext of all the first data from the second party, the device 500 may further include a comparison unit 503, which is configured to compare the secondary ciphertext of each first data with the secondary ciphertext of each second data, thereby determining the intersection data of the first data and the second data.

[0092] It is understood that when the communication unit 501 is configured to provide the second party with the secondary ciphertext of all the second data, the device 500 may include only the communication unit 501 and the encryption unit 502, but not the comparison unit 503.

[0093] According to another embodiment, in which device 500 is located Figure 2 In the case of the second-party device shown

[0094] Encryption unit 502 is configured to respond to communication unit 501 receiving a first batch of first data P determined by a first party based on its local private key Ka. 11 The encrypted data is then jointly encrypted with the first party in batches, performing the following alternating encryption operation: upon receiving the first data P of the i-th batch from the first party via communication unit 501. i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext is provided to the first party in one instance, and P is provided to the first party through communication unit 501. i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The ciphertext is a quadratic ciphertext, where i is a natural number;

[0095] The communication unit 501 is further configured to provide the second ciphertext of all the first data to the first party, or to receive the second ciphertext of all the second data from the first party, after the encryption unit 502 has completed the second ciphertext calculation of all batches of the first data.

[0096] In the case where the communication unit 501 is configured to receive the secondary ciphertext of all the second data from the first party, the device 500 may further include a comparison unit 503, configured to compare the secondary ciphertext of each first data with the secondary ciphertext of each second data, thereby determining the intersection data of the first data and the second data.

[0097] It is worth noting that, Figure 5 The device 500 shown is applied to the first party and the second party respectively. Figure 3 , Figure 4 The methods described correspond to this, therefore, Figure 2 , Figure 3 , Figure 4 The descriptions of the relevant participants also apply to the relevant devices, and will not be repeated here.

[0098] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination of... Figure 3 , Figure 4 The methods described above.

[0099] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 3 , Figure 4 The methods described above.

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

[0101] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the technical concept in this specification. It should be understood that the above description is only a specific embodiment of the technical concept in this specification and is not intended to limit the scope of protection of the technical concept in this specification. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments in this specification should be included within the scope of protection of the technical concept in this specification.

Claims

1. A privacy-preserving intersection method, used to determine the intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; the method includes: The first party determines the first data P of the first batch based on its local private key Ka. 11 A ciphertext is provided to the second party; The first and second parties jointly perform the following batch-based alternating encryption operation: The second party obtains the first data P of the i-th batch from the first party. i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext, and provided to the first party with P i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The second ciphertext, the first party receives P from the second party i2 Simultaneously with the ciphertext, determine the first data P of the (i+1)th batch. （i+1）1 A encrypted message, provided to a second party, P （i+1）1 Simultaneously with ciphertext transmission, P is determined based on the local private key Ka. i2 The ciphertext is a quadratic ciphertext, where i is a natural number; After completing the secondary ciphertext calculation of all batches of first data, the second party provides the first party with the secondary ciphertext of all first data. The first party then compares the secondary ciphertext of each first data with the secondary ciphertext of each second data to determine the intersection of the first data and the second data. or After completing the secondary ciphertext calculation for all batches of the second data, the first party provides the second party with the secondary ciphertext of all the second data. The second party then compares the secondary ciphertext of each first data with the secondary ciphertext of each second data to determine the intersection of the first and second data.

2. The method as described in claim 1, wherein, The method further includes: Before encrypting the first and second data in batches, the first party and the second party each perform hash calculations on their local first and second data, and take the modulo of each hash value by the number of buckets n, thereby performing bucketing on the local first and second data. The number of buckets n is determined by the two parties through negotiation, and the same data in the first and second data are assigned to the corresponding buckets.

3. The method as described in claim 2, wherein, The number of buckets n satisfies the following condition: the time difference between encrypting a single batch of data and transmitting a single batch of data is less than a predetermined threshold.

4. The method of claim 2, wherein, The first and second data of a single batch include k data entries from each of the n buckets.

5. The method of claim 4, wherein, When the first party encrypts the first or second data of a single batch, or when the second party encrypts the second or first data of a single batch, n processes are used in parallel, with each process corresponding to a single bucket.

6. The method of claim 2, wherein, The first or second party compares the secondary ciphertext of each piece of first data with the secondary ciphertext of each piece of second data, including: In the corresponding buckets of the first and second parties, compare the secondary ciphertext of each piece of first data with the secondary ciphertext of each piece of second data.

7. The method of claim 1, wherein: The first party encrypts the first ciphertext of the first data or the second data in a single batch in the following way: mapping the first ciphertext of the first data or the second data to a point on an elliptic curve; and performing a dot product between the private key Ka and the corresponding point on the elliptic curve to obtain the first ciphertext of the first data or the second ciphertext of the second data. The second party encrypts the second data or the first ciphertext of the first data in a single batch by mapping the second data or the first ciphertext of the first data to points on an elliptic curve; and by performing a dot product between the private key Kb and the corresponding points on the elliptic curve to obtain the first ciphertext of the second data or the second ciphertext of the first data.

8. The method of claim 1, wherein, When the second party provides the first party with the secondary ciphertext of all the first data, the first party also encrypts the primary ciphertext of the last batch of second data to obtain the secondary ciphertext of the corresponding second data.

9. The method of claim 1, wherein, The first party determines the first data P of the first batch based on its local private key Ka. 11 While the first party sends a ciphertext, the second party remains dormant.

10. A privacy-preserving intersection method for determining the intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; The method is performed by a first party and includes: The first data P of the first batch is determined based on the local private key Ka. 11 A ciphertext is provided to the second party; In conjunction with a second party, perform batch-based alternating encryption operations, wherein, upon receiving the second data P of the i-th batch from the second party... i2 Simultaneously with the ciphertext, determine the first data P of the (i+1)th batch. （i+1）1 A encrypted message, provided to a second party, P （i+1）1 Simultaneously with ciphertext transmission, P is determined based on the local private key Ka. i2 The ciphertext is a quadratic ciphertext, where i is a natural number; The system receives the secondary ciphertext of all the first data from the second party, compares the secondary ciphertext of each piece of first data with the secondary ciphertext of each piece of second data, and thus determines the intersection of the first and second data. or After completing the secondary ciphertext calculation of all batches of the second data, the secondary ciphertext of all the second data is provided to the second party so that the second party can determine the intersection data of the first data and the second data by comparing the secondary ciphertext of each first data and the secondary ciphertext of each second data.

11. The method of claim 10, wherein, The method further includes: Before encrypting the first data in batches, the local first data is hashed, and each hash value is modulo the number of buckets n to perform bucketing on the local first data. The number of buckets n is determined by negotiation between the two parties.

12. The method of claim 11, wherein, The first and second data of a single batch include k data entries from each of n buckets. When encrypting the first data of a single batch, n processes are used in parallel, with each process corresponding to a single bucket.

13. A privacy-preserving intersection method for determining the intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; The method is performed by a second party and includes: In response to receiving the first batch of first data P determined by the first party based on its local private key Ka 11 A ciphertext is obtained, and the following batch-based alternating encryption operation is performed jointly with the first party: Upon obtaining the first data P of the i-th batch from the first party... i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext is provided to the first party in connection with providing P to the first party. i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The ciphertext is a quadratic ciphertext, where i is a natural number; After completing the secondary ciphertext calculation for all batches of the first data, the secondary ciphertext of all the first data is provided to the first party so that the first party can determine the intersection data of the first data and the second data by comparing the secondary ciphertext of each first data with the secondary ciphertext of each second data; or The system receives the secondary ciphertext of all the second data from the first party, and determines the intersection data of the first data and the second data based on the comparison between the secondary ciphertext of each first data and the secondary ciphertext of each second data.

14. The method of claim 13, wherein, The method further includes: Before encrypting the second data in batches, the local second data is hashed, and each hash value is modulo the number of buckets n to perform bucketing on the local second data. The number of buckets n is determined by negotiation between the two parties.

15. The method of claim 14, wherein, The second data in a single batch consists of k data entries from each of n buckets. When encrypting the second data in a single batch, n processes are used in parallel, with each process corresponding to a single bucket.

16. A privacy intersection apparatus for determining the intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; The device is located at the first party and includes a communication unit and an encryption unit, wherein: The encryption unit is configured to determine the first data P of each batch based on the local private key Ka. 11 A ciphertext is provided to the second party via the communication unit; and In conjunction with a second party, a batch-alternating encryption operation is performed, wherein, upon receiving the second data P of the i-th batch from the second party via the communication unit... i2 Simultaneously with the ciphertext, determine the first data P of the (i+1)th batch. （i+1）1 A encrypted message is provided to the second party via the communication unit. （i+1）1 Simultaneously with ciphertext transmission, P is determined based on the local private key Ka. i2 The ciphertext is a quadratic ciphertext, where i is a natural number; The communication unit is further configured to receive the secondary ciphertext of all the first data from the second party, or, after completing the secondary ciphertext calculation of all batches of the second data, provide the secondary ciphertext of all the second data to the second party. When the communication unit is configured to receive the secondary ciphertext of all first data from a second party, the device further includes a comparison unit configured to compare the secondary ciphertext of each first data with the secondary ciphertext of each second data, thereby determining the intersection data of the first data and the second data.

17. A privacy intersection apparatus for determining the intersection of multiple pieces of first data held by a first party and multiple pieces of second data held by a second party, while protecting data privacy; The device is located on the second party and includes a communication unit and an encryption unit, wherein: The encryption unit is configured to respond to the communication unit receiving a first batch of first data P determined by the first party based on its local private key Ka. 11 The encrypted data is then jointly encrypted with the first party in batches, performing the following alternating encryption operation: upon receiving the first data P of the i-th batch from the first party via the communication unit... i1 Simultaneously with the encrypted data, the second data P of the i-th batch is determined based on the local private key Kb. i2 A ciphertext is provided to the first party in one instance, and P is provided to the first party through the communication unit. i2 At the same time as encrypting the ciphertext, P is also encrypted. i1 One encrypted message obtained P i1 The ciphertext is a quadratic ciphertext, where i is a natural number; The communication unit is further configured to, when the encryption unit has completed the secondary ciphertext calculation of all batches of first data, provide the secondary ciphertext of all first data to the first party, or receive the secondary ciphertext of all second data from the first party. When the communication unit is configured to receive the secondary ciphertext of all the second data from the first party, the device further includes a comparison unit configured to compare the secondary ciphertext of each first data with the secondary ciphertext of each second data, thereby determining the intersection data of the first data and the second data.

18. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 10-15.

19. 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, it implements the method of any one of claims 10-15.

Images