A multi-party secure intersection method and system

By using partitioning algorithms and multi-level ciphertext processing technology in multi-party security interception, the problem of inefficient security interception in big data environment is solved, and efficient and secure data interception operations are achieved.

CN114386070BActive Publication Date: 2025-04-29ANT BLOCKCHAIN TECHNOLOGY (SHANGHAI) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202210033431.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-01-12
Publication Date
2025-04-29
Estimated Expiration
2042-01-12

AI Technical Summary

Technical Problem

In the case of big data, it is difficult for the prior art to efficiently implement secure intersection (PSI) because a single device has limited performance when processing large amounts of data, resulting in inefficient execution.

Method used

By partitioning the data elements in the privacy data set in the first cluster of each participant using a preset partitioning algorithm, and obtaining multi-level ciphertext with the assistance of the second cluster, multiple encryption is used to encrypt it using the exchangeable encryption algorithm, and finally determining the intersection of the privacy data sets of each participant in the first cluster.

Benefits of technology

This method improves the execution efficiency of security intersection, and reduces the complexity and computing load of data interaction through partitioning and multi-level ciphertext processing, ensuring the security of data privacy.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114386070B_ABST
    Figure CN114386070B_ABST
Patent Text Reader

Abstract

The embodiments of this specification disclose a multi-party secure intersection method and system, which involves two or more participants, each of which is deployed with a first cluster and a second cluster, and the first cluster of each participant stores its privacy data set. The method is executed by one of the participants, including: partitioning the data elements in its privacy data set according to a preset partitioning algorithm through the first cluster to obtain multiple local partitions; obtaining multi-level ciphertexts of data elements in each local partition through the first cluster with the assistance of the second cluster of other participants, and assisting the first cluster of other participants to obtain multi-level ciphertexts of data elements in each partition of other participants through the second cluster; obtaining the intersection results corresponding to each local partition through the first cluster, and determining the intersection of the privacy data sets of each participant based on the intersection results corresponding to the multiple local partitions through the first cluster.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to a multi-party secure intersection method and system. Background Art

[0002] PSI (Private Set Intersection), also known as secure set intersection (or simply secure intersection), is one of the basic functions of Secure Multi-Party Computation (SMPC or MPC). When multiple parties each hold a private data set (i.e., a private set), PSI allows any party to obtain the intersection of the private data sets of all parties while protecting the privacy of the data of all parties. At present, especially in the case of big data, it is hoped to provide an efficient secure intersection method. Summary of the invention

[0003] One of the embodiments of the present specification provides a multi-party secure intersection method, involving two or more participants, each of which is deployed with a first cluster and a second cluster, and the first cluster of each participant stores its private data set, and the private data set includes multiple data elements; the method is executed by one of the participants, and includes: partitioning the data elements in its private data set according to a preset partitioning algorithm through the first cluster to obtain multiple local partitions; the partitioning algorithm makes the multiple local partitions correspond to multiple partitions obtained by other participants one by one, and the partitions to which the same data elements in the private data sets of different participants belong correspond; the first cluster is used to partition the data elements in the other participants according to a preset partitioning algorithm; The multi-level ciphertext of the data elements in each local partition is obtained with the assistance of the second cluster; the multi-level ciphertext of the data elements is obtained by encrypting the data elements twice or more by using a commutative encryption algorithm; the second cluster assists the first cluster of other participants in obtaining the multi-level ciphertext of the data elements in each partition of other participants; the intersection results corresponding to each local partition are obtained through the first cluster, wherein the intersection result corresponding to the partition indicates the intersection of the multi-level ciphertext of each data element in the partition and the multi-level ciphertext of each data element in the partition of other participants corresponding to the partition; the intersection of the privacy data sets of each participant is determined by the first cluster based on the intersection results corresponding to multiple local partitions.

[0004] One of the embodiments of the present specification provides a secure intersection system, wherein two or more participants respectively deploy the system, the system includes a first cluster and a second cluster, the first cluster of each participant stores its privacy data set, and the privacy data set includes multiple data elements; the first cluster is used to partition the data elements in its privacy data set according to a preset partitioning algorithm to obtain multiple local partitions, wherein the partitioning algorithm makes the multiple local partitions correspond one-to-one with the multiple partitions obtained by other participants, and the partitions to which the same data elements in the privacy data sets of different participants belong correspond; the first cluster is also used to: The multi-level ciphertext of the data elements in each local partition is obtained with the assistance of the first cluster of other participants; the multi-level ciphertext of the data elements is obtained by encrypting the data elements twice or more using a commutative encryption algorithm; the second cluster is used to: assist the first cluster of other participants in obtaining the multi-level ciphertext of the data elements in each partition of other participants; the first cluster is also used to obtain the intersection results corresponding to each local partition, wherein the intersection result corresponding to a partition indicates the intersection of the multi-level ciphertext of each data element in the partition and the multi-level ciphertext of each data element in the partition of other participants corresponding to the partition; the first cluster is also used to determine the intersection of the privacy data sets of the participants based on the intersection results corresponding to multiple local partitions. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] This specification will be further described in the form of exemplary embodiments, which will be described in detail by the accompanying drawings. These embodiments are not restrictive, and in these embodiments, the same number represents the same structure, wherein:

[0006] Figure 1 is an exemplary block diagram of a multi-party secure intersection system according to some embodiments of this specification;

[0007] Figure 2 is an exemplary flow chart of a multi-party secure intersection method according to some embodiments of this specification;

[0008] Figure 3 It is a flowchart of a two-party secure intersection method shown in some embodiments of this specification. DETAILED DESCRIPTION

[0009] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following is a brief introduction to the drawings required for the description of the embodiments. Obviously, the drawings described below are only some examples or embodiments of this specification. For ordinary technicians in this field, this specification can also be applied to other similar scenarios based on these drawings without creative work. Unless it is obvious from the language environment or otherwise explained, the same reference numerals in the figures represent the same structure or operation.

[0010] It should be understood that the "system", "device", "unit" and / or "module" used herein are a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

[0011] As shown in this specification, unless the context clearly indicates an exception, the words "a", "an", "a kind" and / or "the" do not refer to the singular, but also include the plural. Generally speaking, the terms "include" and "comprise" only indicate the inclusion of the steps and elements that have been clearly identified, and these steps and elements do not constitute an exclusive list. The method or device may also include other steps or elements.

[0012] Flowcharts are used in this specification to illustrate the operations performed by the system according to the embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed precisely in order. Instead, the steps may be processed in reverse order or simultaneously. At the same time, other operations may also be added to these processes, or one or more operations may be removed from these processes.

[0013] In the case of big data, the execution efficiency of secure intersection (PSI) is particularly important. It is understandable that when the amount of data in a private collection is large, a single device may not be able to implement secure intersection or may take a long time to complete secure intersection due to limited performance. In some embodiments, secure intersection can be implemented based on a computing cluster, and the execution efficiency of secure intersection can be improved through parallel processing of multiple devices in the cluster. It is understandable that a computing cluster (hereinafter referred to as a cluster) includes multiple computing devices, and each computing device can be called a node.

[0014] In a multi-party secure intersection, each party has its own private data set. Without disclosing the data privacy of each party, one or all of them can obtain the intersection of the private data sets of each party. As an example only, the private data set can be an ID set, and the ID set can include the IDs of multiple users, such as UID (User Identification). Under the premise that the IDs of both parties are the same, the users identified by the same ID are also the same. Through multi-party secure intersection, the authorized party can obtain the intersection of the ID sets of all parties, so that the common users of all parties can be determined. In some application scenarios, determining the common user helps to combine the user data of different dimensions of both parties. For example, in a credit scenario, the tax bureau has the user's tax payment data, and the bank has the user's credit data. If a credit assessment model is to be trained, the tax bureau and the bank need to first determine the common users of both parties. Furthermore, the tax bureau can provide the tax payment data of the common users of both parties as the feature data required for training, and the bank can provide the credit data of the common users of both parties as the label data required for training. In some embodiments, the training here may refer to distributed model training based on secure multi-party computing (MPC), or may refer to centralized model training based on trusted third-party devices, such as TEE (Trusted Execution Environment) devices.

[0015] Figure 1 1 is an exemplary block diagram of a secure intersection system according to some embodiments of the present specification. Participants (such as the first party and the second party) are respectively equipped with a system 100. Figure 1 As shown, the system 100 may include a first cluster 110 and a second cluster 120 .

[0016] The first cluster 110 may include a plurality of first nodes, such as the first node 110-1, the first node 110-2, the first node 110-3, ..., the first node 110-n. The second cluster 120 may include a plurality of second nodes, such as the second node 120-1, the second node 120-2, the second node 120-3, ..., the second node 120-n.

[0017] In some embodiments, the first cluster may be a cluster based on a big data framework (hereinafter referred to as a big data cluster), such as a Spark cluster. The big data cluster may be deployed through a public cloud service, which may be used through a public network (such as the Internet) and is generally low-cost or even free.

[0018] In some embodiments, the second cluster can be used for secure computing, where security refers to ensuring data security during the computing process. Specifically, the first party / the second party can deploy the second cluster through the intranet to ensure high controllability in terms of data security.

[0019] The first clusters of each party respectively store a privacy data set, and the privacy data set may include multiple data elements. In some embodiments, the privacy data set of any party may be centrally stored in a first node, or distributedly stored in multiple first nodes. For example, when the first cluster is a Spark cluster, the privacy data set may be stored in the form of RDD (Resilient Distributed Datasets), and the RDD is divided into multiple parts and different parts of the RDD are stored in different first nodes. In some embodiments, one or more data elements in the privacy data set of any party may be native data within the cluster, or may come from a device outside the cluster (such as an external database). For example, when the first cluster is a Spark cluster, the Spark cluster may obtain the privacy data set to be converted from an external device, and then convert it into RDD, thereby obtaining the converted privacy data set.

[0020] For the working principle of system 100, that is, how to achieve multi-party secure intersection, please refer to Figure 2 and its related description.

[0021] Figure 2 It is an exemplary flow chart of a secure intersection method according to some embodiments of the present specification.

[0022] There may be two or more parties involved in the secure intersection search. In the process of multiple parties' secure intersection search, each party executes the same process. Some embodiments of this specification mainly describe the secure intersection search method from the perspective of one of the parties, such as Figure 2 As shown, for any party among the multiple parties (for convenience of reference below, it may be referred to as the first party), the exemplary secure intersection process 200 includes:

[0023] Step 210: partition the data elements in the privacy data set according to a preset partitioning algorithm through the first cluster to obtain multiple local partitions.

[0024] The partitioning algorithm can make: the multiple local partitions correspond one-to-one with the multiple partitions obtained by other parties, and the partitions to which the same data elements in the privacy data sets of each party belong correspond to each other. It should be understood that the parties can agree on the partitioning algorithm to be used before partitioning.

[0025] A specific partitioning algorithm is provided below as an example to facilitate understanding of the role of the partitioning algorithm.

[0026] In some embodiments, for any data element, the partition of the data element can be determined according to the hash value of the data element. The hash function can convert an input of any length into an output of a fixed length, and in the case of big data, the data elements in the privacy data set can be relatively evenly divided into various partitions.

[0027] In some embodiments, the remainder of the hash value of the data element divided by the preset value (i.e., hash value% preset value, where % represents a modulus or remainder operation) can be determined, and the partition corresponding to the remainder is determined as the partition corresponding to or belonging to the data element. It can be understood that the local partition and other party partitions corresponding to the same remainder correspond to each other. In addition, one remainder may correspond to one partition, or multiple remainders may correspond to one partition. For example, the hash value of a data element is expressed as 197 in decimal. If the divisor (the preset value) is 10, each remainder from 0 to 9 can correspond to a partition (the divisor is the number of partitions at this time), and the data element is divided into the partition corresponding to the remainder 7. Of course, the remainders 0 to 9 can also be divided into five groups {0,1}, {2,3}, {4,5}, {6,7}, and {8,9} at fixed intervals, each group corresponding to a partition, and at this time, the data element is divided into the partition corresponding to the {6,7} group.

[0028] In some embodiments, the data element in the privacy data set may be in hash form. For example, when the privacy data set is an ID set, the ID in the ID set may be a hash ID. In the case where the data element itself is a hash value, with reference to the aforementioned embodiment, the remainder of the data element divided by the preset value (i.e., data element % preset value, where % represents a modulus or remainder operation) may be determined, and the partition corresponding to the remainder may be determined as the partition corresponding to the data element.

[0029] Different partitions can be stored in different first nodes so that multiple nodes can process multiple partitions in parallel, thereby improving the execution efficiency of the secure intersection. As an example only, assuming that the number of partitions obtained by any party is N, these N (N is an integer not less than 2) partitions can be processed in parallel by the N first nodes in the first cluster of the party. For the specific implementation of parallel processing, please refer to the description of the relevant steps below.

[0030] Step 220: For each local partition, obtain the multi-level ciphertext of each data element in the partition through the first cluster with the assistance of the second cluster of the other party.

[0031] The multi-level ciphertext of the data element can be obtained by encrypting the data element at least twice using a commutative encryption algorithm, wherein the commutative encryption algorithm provides support for the subsequent determination of the intersection of the privacy data sets of each party, and the details can be referred to the relevant description of step 240 and step 250.

[0032] For a two-party secure intersection, the multi-level ciphertext of a data element can be obtained by each of the two parties using its own key to encrypt the data element (such as the plaintext of the data element) in turn. For a multi-party (assuming there are k parties, k≥3) secure intersection, the multi-level ciphertext of a data element can be obtained by each of the multiple parties using its own key to encrypt the data element in turn. It can be seen that each party can encrypt the data element once using its own key, that is, n participating parties (n≥2) can iteratively encrypt the data element n times to obtain the n-time ciphertext of the data element. It should be understood that the key of any party belongs to the privacy information of that party and is not shared with other parties.

[0033] In some embodiments, the first cluster of the first party can use its own key (or called the first key) to encrypt each data element in the privacy data set it holds, and obtain the first-level ciphertext of the multiple partitioned data elements locally. Further, for each local partition, the first cluster of the first party can send the first-level sub-ciphertext of each data element in the partition to the second cluster of the other party. Furthermore, the second cluster of the other party can use its own key (or called the second key) to encrypt the first-level ciphertext of each data element in the partition at least once, obtain the multi-level ciphertext of each data element in the partition and return it to the first cluster of the first party. In other words, the first cluster of the first party can receive the multi-level ciphertext of each data element in the partition from the second cluster of the other party.

[0034] It should be noted that the second key mentioned in this specification is a general term for the keys of other parties, that is, no matter whether the other party has one or more keys, the keys of other parties are called second keys to distinguish them from the first party's own keys.

[0035] Referring to the above content, for two parties to securely request intersection, the first cluster of the first party can send the first-level ciphertext of each data element in each local partition to the second cluster of the other party (or recorded as the second party), and then the second cluster of the second party can use its own key (second key) to encrypt the first-level ciphertext of each data element in the partition, obtain the second-level ciphertext of each data element in the partition and return it to the first cluster of the first party. Thus, the first cluster of the first party can receive the second-level ciphertext of each data element in the partition from the second cluster of the second party.

[0036] Referring to the above content, for secure intersection of multiple parties (assuming k parties, k ≥ 3), the first cluster of the first party can send the first-level ciphertext of each data element in each local partition to the second cluster of a certain other party (or recorded as the second party). The second cluster of the second party can use its own key (second key) to encrypt the first-level ciphertext of each data element in the partition, obtain the second-level ciphertext of each data element in the partition and send it to the second cluster of the next other party (or recorded as the third party). The second cluster of the third party can use its own key (also called the second key relative to the first party) to encrypt the second-level ciphertext of each data element in the partition, and obtain the third-level ciphertext of each data element in the partition. And so on, until each data element in the partition is encrypted once by the own key of each participant, and the k-level ciphertext of each data element in the partition is obtained, and the encrypted participant finally sends it to the first cluster of the first party.

[0037] In some other embodiments, the first cluster of the first party may send the data elements of multiple local partitions to the second cluster (of its own party), and encrypt each data element in each partition by the second cluster (of its own party) using the first key. Afterwards, the second cluster sends the encrypted first-level ciphertext of each data element in each partition to the second cluster of the other party (such as the second party), or the second cluster returns the encrypted first-level ciphertext of each data element in each partition to the first cluster (of its own party), so that the first cluster sends the first-level ciphertext of each local partition to the second cluster of the other party. Furthermore, the second cluster of the other party may encrypt the first-level ciphertext of each data element in each partition at least once using the second key to obtain multi-level ciphertexts of each data element in each partition. For details of the process of the second cluster of the other party encrypting the first-level ciphertext of each local partition data element of the first party at least once, please refer to the aforementioned embodiments.

[0038] Step 230: For each partition of the other party, the second cluster assists the first cluster of the other party to obtain the multi-level ciphertext of each data element in the partition.

[0039] Referring to the description of step 220, the first cluster of the first party obtains the multi-level ciphertext of each data element in each local partition with the assistance of the second cluster of the other party. Equivalently, the second cluster of the first party also assists the first cluster of the other party to obtain the multi-level ciphertext of each data element in each partition of the other party.

[0040] Referring to the above content, for two parties to securely request intersection, the first cluster of the second party can send the first-level ciphertext of each data element in each partition to the second cluster of the first party, and then the second cluster of the first party can use its own key (first key) to encrypt the first-level ciphertext of each data element in the partition, obtain the second-level ciphertext of each data element in the partition and return it to the first cluster of the second party. Thus, the second cluster of the first party can assist the first cluster of the second party in obtaining the second-level ciphertext of the data elements in each partition.

[0041] Referring to the above content, for multi-party (assuming k parties, k≥3) secure intersection, the second cluster of the first party can receive at least one level of ciphertext (such as level one ciphertext or level two ciphertext or more level ciphertext) of the partitioned data element of the other party transmitted by the other party, encrypt it with the first key and transmit it to the second cluster of the next other party for the next level of encryption, or return it to the first cluster of the party to which the partitioned data element belongs. Exemplarily, the second cluster of the first party can receive the level one ciphertext of the partitioned data element of the second party transmitted by the first cluster of the second party. The second cluster of the first party can encrypt the level one ciphertext of each data element in the partition with its own key (first key), obtain the level two ciphertext of each data element in the partition and send it to the second cluster of the third party. The second cluster of the third party can encrypt the level two ciphertext of each data element in the partition with its own key, obtain the level three ciphertext of each data element in the partition. And so on, until each data element of the partition of the second party is encrypted once by the own key of each participant, obtain the k-level ciphertext of each data element in the partition, and finally the encrypted participant sends it to the first cluster of the second party. As another example, the multiple parties are three parties. The second cluster of the first party can receive the second-level ciphertext of the third-party partition data element transmitted by the second party (such as the second cluster of the second party). The second cluster of the first party can encrypt the second-level ciphertext of each data element in the partition using its own key (first key), obtain the third-level ciphertext of each data element in the partition and send it to the first cluster of the third party.

[0042] It should be understood that the details of assisting encryption can also be referred to the detailed description of step 220, which will not be repeated here.

[0043] Step 240: For each local partition, obtain the intersection result corresponding to the partition through the first cluster.

[0044] Step 250: Determine the intersection of the privacy data sets of each party based on the intersection results corresponding to the multiple local partitions of the first cluster.

[0045] The intersection result corresponding to a partition may indicate the intersection of the multi-level ciphertext of each data element in the partition and the multi-level ciphertext of each data element in other partitions corresponding to the partition.

[0046] As mentioned above, the multi-level ciphertext is obtained based on a commutative encryption algorithm. The commutative encryption algorithm satisfies that when the same plaintext is encrypted continuously using multiple keys, the final ciphertext obtained is independent of the encryption order. Iterative encryption using multiple keys means that each encryption uses a key, and each encryption is performed with the current ciphertext as input to encrypt again until the final ciphertext is obtained. In order to facilitate the understanding of the properties of the commutative algorithm, the corresponding mathematical expression is given below using two encryptions as an example: E key2 (E key1 (M))=E key1 (E key2 (M)). Wherein, key1 and key2 represent the keys used for the two encryptions, E() represents the exchangeable encryption algorithm, and M represents the plaintext. It can be seen that no matter whether key1 or key2 is used for encryption first, the obtained secondary ciphertext remains unchanged.

[0047] Based on the properties of the commutative encryption algorithm, for the same data element, although the encryption order corresponding to the multi-level ciphertext of the data element obtained by each party is different (such as the encryption key used in the first encryption process corresponding to the multi-level ciphertext obtained by the first party is the key of the first party, and the encryption key used in the first encryption process corresponding to the multi-level ciphertext obtained by the second party is the key of the second party), the multi-level ciphertext of the data element finally obtained by each party is the same. Therefore, the intersection of the multi-level ciphertext of the data element can reflect the same data element. In other words, the intersection result corresponding to a local partition can reflect the same data element in the partition and the partition of other parties corresponding to the partition. Therefore, the first cluster of the first party can determine the intersection of the privacy data sets of each party based on the intersection results corresponding to multiple local partitions.

[0048] In some embodiments, each party can send the multi-level ciphertext of the data element of each partition to a certain party to centrally determine the intersection of the multi-level ciphertext of the data element in the corresponding partition of each party, thereby improving the execution efficiency of the secure intersection. Furthermore, different partitions of each party can be distributed to different nodes of a certain party, while ensuring that the partitions corresponding to each party are sent to the same node, and the corresponding node intersects the multi-level ciphertext of the data element in the partition corresponding to each party. The certain party can be the first party or one of the other parties (such as the second party or the third party in the aforementioned example) or an independent party device whose data does not participate in the secure intersection. In some embodiments, the first cluster of the first party can send the multi-level ciphertext of each data element in each local partition to the second cluster (of its own party) or the second cluster of the other party or the independent party device. Furthermore, the second cluster of the first party or the second cluster of the other party or the independent party device intersects the multi-level ciphertext of each data element in the received partition and the multi-level ciphertext of each data element in the partition of the other party corresponding to the partition, obtains the intersection result corresponding to the partition and sends it to the first cluster of the first party. In other words, the first cluster of the first party can receive the intersection result corresponding to the partition from its own second cluster or the second cluster of the other party or the independent party device. According to the aforementioned encryption content, the first clusters of each party can obtain multi-level ciphertexts without direct interaction. On this basis, the first clusters of each party can obtain the intersection results corresponding to multiple partitions and then determine the intersection of the privacy data sets of each party. During the entire secure intersection process, there can be no direct interaction between the first clusters of each party, so that data security can be guaranteed by the second cluster used to implement secure computing.

[0049] In some embodiments, each data element in the privacy data set may be numbered. The numbers may be arranged by each party for each data element in its privacy data set, and the numbers correspond to the data elements one by one. It can be understood that no matter whether the data element is in plain text or cipher text, the corresponding number remains unchanged. That is, the plain text and multi-level cipher text of the same data element correspond to the same number. In some embodiments, each party may send the multi-level cipher text of the data element of each partition to a certain party, and send the corresponding number of each data element together. For example, the first cluster of the first party may send the multi-level cipher text and the corresponding number of each data element in each local partition to the second cluster (of its own party) or the second cluster of the other party or the independent party device. Accordingly, the intersection result corresponding to the local partition of the first party may include the own number corresponding to the intersection of the multi-level cipher text of each data element in the partition and the multi-level cipher text of each data element in the partition corresponding to the partition, that is, the intersection result corresponding to any partition may include the own number of the same data element in the partition and the partition of the other party corresponding to the partition. Through the corresponding relationship of the numbers, the first party can quickly obtain the data element plaintext corresponding to the intersection result without decrypting the multi-level ciphertext in the intersection result, further improving the intersection efficiency, which is more significant in the big data scenario. Since the numbers of each party are arranged by themselves, sending the multi-level ciphertext of the data element and the corresponding number to the one party will not cause additional information leakage. After the one party obtains the intersection of each partition, it can naturally obtain the number set of different participating parties corresponding to the intersection of each partition. The one party can send the numbers of different parties corresponding to the intersection to each party, so that each party can quickly obtain the data element plaintext corresponding to the intersection result without decrypting the multi-level ciphertext in the intersection result.

[0050] In some embodiments, in order to improve the execution efficiency of secure intersection, one or more of the following steps may be performed in parallel: the step of obtaining the multi-level ciphertext of each data element in at least some of the multiple local partitions (refer to step 220); the step of assisting in obtaining the multi-level ciphertext of each data element in at least some of the multiple other party partitions (refer to step 230); the step of obtaining the intersection result corresponding to at least some of the multiple local partitions (refer to step 240). As an example, the first partition of the first party is stored on the first node 110-1, and the second partition is stored on the second node 110-2; the first node 110-1 of the first party obtains the secondary ciphertext of each data element of the first partition in cooperation with a second node of the second party (such as the second node 120-1), and the first node 110-2 of the first party obtains the secondary ciphertext of each data element of the second partition in cooperation with a second node of the second party (such as the second node 120-2), and then the first party obtains the multi-level ciphertext of the data elements in each local partition in parallel through the first cluster with the assistance of the second clusters of other participating parties. For another example, the second node 120-1 of the first party can assist the first node 110-1 of the second party to obtain the secondary ciphertext of each data element of the first partition of the second party, and the second node 120-2 of the first party assists the first node 110-2 of the second party to obtain the secondary ciphertext of each data element of the second partition of the second party, and then the first party assists the first cluster of other participating parties to obtain the multi-level ciphertext of the data elements in each partition of other participating parties in parallel through the second cluster. For another example, the first node 110-1 of the first party can obtain the intersection result corresponding to the first partition from a second node of its second cluster (such as the second node 120-1), and the first node 110-2 of the first party can obtain the intersection result corresponding to the second partition from a second node of its second cluster (such as the second node 120-2), so that the first party obtains the intersection results corresponding to each local partition in parallel through the first cluster.

[0051] In some embodiments, the intersection results corresponding to each local partition can be distributedly stored in the first cluster. For example, the intersection results corresponding to each local partition of the first party can be distributedly stored at multiple first nodes of the first cluster of the first party. Specifically, for each local partition, the first node storing the partition can determine the same data elements in the partition and other party partitions corresponding to the partition based on the intersection results corresponding to the partition as part of the intersection of the privacy data sets of each party, and then the intersection of the privacy data sets of each party can be distributedly stored in the first cluster. In some other embodiments, each first node can send a part of the intersection of the privacy data sets of each party obtained by itself to one of the first nodes (or referred to as the target first node) for storage, so that the intersection of the privacy data sets of each party can be centrally stored in the target first node in the first cluster.

[0052] It is understood that two or more parties may each execute Figure 2 The process shown in the figure collaboratively completes the multi-party secure intersection search. In order to have a more intuitive understanding of the interactive process, an embodiment of a two-party secure intersection search is provided below as a reference.

[0053] Figure 3 The present invention is a flowchart of a method for securely finding intersection between two parties according to some embodiments of the present specification, wherein the two parties include a first party and a second party.

[0054] like Figure 3 As shown, each party may deploy a Spark cluster and a second cluster (called a PSI cluster) for implementing secure computing. The Spark clusters of both parties store their own privacy datasets, which include multiple data elements. For example, the privacy dataset of the first party may include data elements B, A, and G, and the privacy dataset of the second party may include data elements A, B, and C. The Spark clusters of both parties may convert the privacy datasets into RDDs.

[0055] Each Spark cluster can add numbers to each data element in the RDD. Since each data element is organized in the form of data columns, the numbers can also be called line numbers.

[0056] Each party's Spark cluster can perform a map operation on the RDD. Here, the map operation uses the first function (denoted as f1). The role of f1 is to use the party's key to encrypt the data elements of each row in the RDD through a commutative encryption algorithm (referred to as party encryption). After the map (f1) operation, each party's Spark cluster can obtain the first-level ciphertext of each data element in the RDD. For example, the first party's Spark cluster can obtain the first-level ciphertext E1 (B) of data element B, the first-level ciphertext E1 (A) of data element A, and the first-level ciphertext E1 (G) of data element G. The second party's Spark cluster can obtain the first-level ciphertext E1 (A) of data element A, the first-level ciphertext E1 (B) of data element B, and the first-level ciphertext E1 (C) of data element C. After local encryption (i.e., the first encryption), the data elements in the RDD are in the form of first-level ciphertext.

[0057] Then, the Spark cluster of each party can perform partition operations on the data elements in the RDD using a preset partitioning algorithm. Since the RDD itself is distributed storage (i.e., it has multiple partitions), the partitioning operation here is equivalent to repartitioning. It is understandable that the two parties can agree on the algorithm used for repartitioning in advance. The partitioning algorithm makes: the multiple partitions obtained by the first party and the multiple partitions obtained by the second party correspond one to one, and the partitions where the same data elements in the privacy data sets of each party are located correspond to each other. For example, the partitioning algorithm can be to calculate the hash value of the data element plaintext; determine the remainder of the hash value of the data element plaintext divided by the preset value, and determine the partition corresponding to the remainder as the new partition to which the first-level ciphertext of the data element belongs. After repartitioning, the RDD of the first party includes partition 1-1 and partition 1-2, and the RDD of the second party includes partition 2-1 and partition 2-2, wherein partition 1-1 and partition 2-1 correspond to each other, and partition 1-2 and partition 2-2 correspond to each other. The same data element A in the privacy data sets of both parties falls in the corresponding partitions 1-1 and partition 2-1, and the same data element B in the privacy data sets of both parties falls in the corresponding partitions 1-2 and partition 2-2. It can be understood that when a data element is described as belonging to a partition, the ciphertext of the data element also belongs to the partition.

[0058] Each party's Spark cluster can perform a mapPartitions operation for each partition of its own party. Here, the mapPartitions operation uses the second function (denoted as f2). The function of f2 is to send the first-level ciphertext of each data element in the partition to the other party's PSI cluster. Then, the other party's PSI cluster can use its key to encrypt the first-level ciphertext of each data element in the partition through the exchangeable encryption algorithm, obtain the second-level ciphertext of each data element in the partition and return it to the first party's Spark cluster. Thus, each party's Spark cluster can obtain the second-level ciphertext of the data element in each partition. For example, the Spark cluster of the first party can obtain the secondary ciphertext E2(E1(A)) of data element A and the secondary ciphertext E2(E1(G)) of data element G in partition 1-1, and the primary ciphertext E1(B) of data element B in partition 1-2, and the Spark cluster of the second party can obtain the secondary ciphertext E2(E1(A)) of data element A in partition 2-1, and the secondary ciphertext E2(E1(B)) of data element B and the secondary ciphertext E2(E1(C)) of data element C in partition 2-2. After encryption by the other party (i.e., the second encryption), the data elements in the partition are in the secondary ciphertext form.

[0059] Each party can continue to perform the mapPartitions operation for each partition of its own party. Here, the mapPartitions operation uses the third function (denoted as f3). The function of f3 is to send the secondary ciphertext of each data element in the partition to the PSI cluster of one party, such as the PSI cluster of the first party. Then, the PSI cluster of the first party can compare the secondary ciphertext of each data element in the corresponding partitions received, and return the comparison result to the Spark cluster of one or both parties. For example, the Spark cluster of the first party can obtain the comparison result corresponding to partition 1-1 and the comparison result corresponding to partition 1-2, and the Spark cluster of the second party can obtain the comparison result corresponding to partition 2-1 and the comparison result corresponding to partition 2-2. Among them, the comparison result corresponding to the partition (that is, the intersection result corresponding to the partition) can include the row number corresponding to the intersection of the secondary ciphertext of each data element in the partition and the secondary ciphertext of each data element in the partition corresponding to the partition, that is, the comparison result corresponding to the partition can include the row number of the same data element in the partition and the partition corresponding to the partition. For example, the comparison results corresponding to partition 1-1 and partition 2-1 may include the row number of data element A, and the comparison results corresponding to partition 1-2 and partition 2-2 may include the row number of data element B. Accordingly, the PSI cluster of the first party may send the row number 1 of data element A on the first party to the Spark cluster of the first party, and send the row number 0 of data element A on the second party to the Spark cluster of the second party; the PSI cluster of the first party may send the row number 0 of data element B on the first party to the Spark cluster of the first party, and send the row number 1 of data element B on the second party to the Spark cluster of the second party. Of course, the secondary ciphertext of each data element in the partition may also be sent to the PSI cluster of the second party or an independent party device for comparison ( Figure 3 not shown).

[0060] The Spark cluster of either party can merge the comparison results corresponding to all its partitions to obtain the row number corresponding to the intersection of the two parties' private data sets, and then find the corresponding plaintext through the row number to achieve secure intersection. For example, the Spark cluster of the first party can find the corresponding plaintext A and B through row number 1 and row number 0, and the intersection of the two parties' private data sets can include plaintext A and B. For another example, the Spark cluster of the second party can find the corresponding plaintext A and B through row number 0 and row number 1, and the intersection of the two parties' private data sets can include plaintext A and B.

[0061] It should be noted that the above description of the relevant process is only for example and explanation, and does not limit the scope of application of this specification. For those skilled in the art, various modifications and changes can be made to the process under the guidance of this specification. However, these modifications and changes are still within the scope of this specification.

[0062] The beneficial effects that may be brought about by the embodiments of this specification include but are not limited to: (1) by partitioning, the number of multi-level ciphertext pairs to be selected can be reduced when finding the intersection of multi-level ciphertexts, thereby improving the execution efficiency of secure intersection; (2) multiple nodes process multiple partitions in parallel, which can improve the execution efficiency of secure intersection; (3) using the first cluster based on the big data framework can improve the execution efficiency of secure intersection; (4) by simply adding or subtracting machines (such as the first node or the second node), linear expansion can be achieved to accommodate secure intersection of larger data volumes; (5) with the help of the second cluster used for secure computing, direct interaction between the first clusters can be reduced or even avoided, which can ensure data security, such as avoiding privacy data leakage. It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects that may be produced may be any one or a combination of the above, or any other beneficial effects that may be obtained.

[0063] The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only for example and does not constitute a limitation on the embodiments of this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements and corrections to the embodiments of this specification. Such modifications, improvements and corrections are suggested in the embodiments of this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

[0064] At the same time, this specification uses specific words to describe the embodiments of this specification. For example, "one embodiment", "an embodiment" and / or "some embodiments" refer to a certain feature, structure or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "one embodiment" or "an embodiment" or "an alternative embodiment" mentioned twice or more in different locations in this specification does not necessarily refer to the same embodiment. In addition, certain features, structures or characteristics in one or more embodiments of this specification can be appropriately combined.

[0065] In addition, it will be appreciated by those skilled in the art that the various aspects of the embodiments of this specification may be illustrated and described by a number of patentable categories or situations, including any new and useful process, machine, product or combination of substances, or any new and useful improvements thereto. Accordingly, the various aspects of the embodiments of this specification may be performed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The above hardware or software may all be referred to as "data blocks", "modules", "engines", "units", "components" or "systems". In addition, the various aspects of the embodiments of this specification may be represented as a computer product located in one or more computer-readable media, the product including computer-readable program code.

[0066] A computer storage medium may include a propagated data signal containing computer program code, for example, in baseband or as part of a carrier wave. The propagated signal may be in a variety of forms, including electromagnetic, optical, etc., or a suitable combination. A computer storage medium may be any computer-readable medium other than a computer-readable storage medium, which can be connected to an instruction execution system, device or apparatus to communicate, propagate or transmit the program for use. The program code on the computer storage medium may be transmitted via any suitable medium, including radio, cable, fiber optic cable, RF, or similar media, or any combination of the above media.

[0067] The computer program coding required for the operation of each part of the embodiment of this specification can be written in any one or more programming languages, including object-oriented programming languages ​​such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET, Python, etc., conventional procedural programming languages ​​such as C language, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, dynamic programming languages ​​such as Python, Ruby and Groovy, or other programming languages, etc. The program coding can be run completely on the user's computer, or run on the user's computer as an independent software package, or partly run on the user's computer and partly run on the remote computer, or run completely on the remote computer or processing equipment. In the latter case, the remote computer can be connected to the user's computer by any network form, such as a local area network (LAN) or a wide area network (WAN), or connected to an external computer (e.g., by the Internet), or in a cloud computing environment, or used as a service such as software as a service (SaaS).

[0068] In addition, unless explicitly stated in the claims, the order of the processing elements and sequences described in the embodiments of this specification, the use of alphanumeric characters, or the use of other names are not intended to limit the order of the processes and methods of the embodiments of this specification. Although the above disclosure discusses some invention embodiments that are currently considered useful through various examples, it should be understood that such details are only for illustrative purposes, and the attached claims are not limited to the disclosed embodiments. On the contrary, the claims are intended to cover all modifications and equivalent combinations that are consistent with the essence and scope of the embodiments of this specification. For example, although the system components described above can be implemented by hardware devices, they can also be implemented only by software solutions, such as installing the described system on an existing processing device or mobile device.

[0069] Similarly, it should be noted that in order to simplify the description of the embodiments disclosed in this specification, thereby helping to understand one or more embodiments of the invention, in the above description of the embodiments of this specification, multiple features are sometimes combined into one embodiment, figure or description thereof. However, this disclosure method does not mean that the features required by the objects of the embodiments of this specification are more than the features mentioned in the claims. In fact, the features of the embodiments are less than all the features of the single embodiment disclosed above.

[0070] Each patent, patent application, patent application publication, and other materials, such as articles, books, specifications, publications, documents, etc., cited in this specification is hereby incorporated by reference in its entirety. Except for application history documents that are inconsistent with or conflicting with the contents of this specification, documents that limit the broadest scope of the claims of this application (currently or later attached to this application) are also excluded. It should be noted that if the descriptions, definitions, and / or use of terms in the materials attached to this specification are inconsistent or conflicting with the contents described in this specification, the descriptions, definitions, and / or use of terms in this specification shall prevail.

[0071] Finally, it should be understood that the embodiments described in this specification are only used to illustrate the principles of the embodiments of this specification. Other variations may also fall within the scope of the embodiments of this specification. Therefore, as an example and not a limitation, alternative configurations of the embodiments of this specification may be considered consistent with the teachings of this specification. Accordingly, the embodiments of this specification are not limited to the embodiments explicitly introduced and described in this specification.

Claims

1. A secure intersection method involves two or more participants, each of which is deployed with a first cluster and a second cluster, and the first cluster of each participant stores its private data set, wherein the private data set includes multiple data elements; The method is performed by one of the participants, including: The first cluster partitions the data elements in its private data set according to a preset partitioning algorithm to obtain a plurality of local partitions; the partitioning algorithm makes the plurality of local partitions correspond one-to-one with the plurality of partitions obtained by other participants, and the partitions to which the same data elements in the private data sets of different participants belong correspond; The multi-level ciphertext of the data element in each local partition is obtained by the first cluster with the assistance of the second cluster of other participants; the multi-level ciphertext of the data element is obtained by encrypting the data element twice or more using a commutative encryption algorithm; Assisting the first cluster of other participants through the second cluster to obtain multi-level ciphertexts of data elements in each partition of other participants; Obtaining intersection results corresponding to each local partition through the first cluster, wherein the intersection result corresponding to the partition indicates the intersection of the multi-level ciphertext of each data element in the partition and the multi-level ciphertext of each data element in the partition of other participants corresponding to the partition; The intersection of the private data sets of each participant is determined by the first cluster based on the intersection results corresponding to the multiple local partitions.

2. The method of claim 1, wherein: The first cluster is a cluster based on a big data processing framework, and the second cluster is used for secure computing.

3. The method of claim 1, wherein: The first cluster is a Spark cluster.

4. The method of claim 1, wherein: Partitioning the data elements in the privacy data set according to a preset partitioning algorithm by the first cluster to obtain a plurality of local partitions includes: Calculate the hash value of the data element; The remainder of the hash value of the data element divided by the preset value is determined, and the partition corresponding to the remainder is determined as the partition to which the data element belongs.

5. The method of claim 1, wherein: The first cluster obtains the multi-level ciphertext of the data elements in each local partition with the assistance of the second cluster of other participants, including one of the local partitions: Encrypting each data element in the partition by using the first cluster with the first key to obtain a first-level ciphertext of each data element in the partition; Sending the first-level ciphertext of each data element in the partition to the second cluster of the other participant through the first cluster, so that the second cluster of the other participant encrypts the first-level ciphertext of each data element in the partition at least once using the second key to obtain the multi-level ciphertext of each data element in the partition; receiving, through the first cluster, multi-level ciphertexts of each data element in the partition from a second cluster of another participant; Or, include one of the local partitions: By the first cluster: sending the data elements in the partition to the second cluster so that the second cluster encrypts each data element in the partition using the first key; Sending the encrypted primary ciphertext of each data element in the partition to the second cluster of other participants, so that the second cluster of other participants encrypts the primary ciphertext of each data element in the partition at least once using the second key to obtain multi-level ciphertexts of each data element in the partition; The multi-level ciphertext of each data element in the partition is received from the second cluster of other participants through the first cluster.

6. The method of claim 1, wherein: The first cluster of the other participant is assisted by the second cluster to obtain the multi-level ciphertext of the data element in each partition of the other participant, including one of the partitions of the other participant: The ciphertext of each data element in the partition that has been encrypted at least once is encrypted by using the first key through the second cluster.

7. The method of claim 1, wherein: Obtain the intersection results corresponding to each local partition through the first cluster, including one of the local partitions: By means of the first cluster: sending the multi-level ciphertext of each data element in the partition to the second cluster or the second cluster of another party or an independent party device, so that the second cluster or the second cluster of another party or the independent party device intersects the received multi-level ciphertext of each data element in the partition with the multi-level ciphertext of each data element in the partition of another participant corresponding to the partition, and obtains the intersection result corresponding to the partition; And, receiving the intersection result corresponding to the partition from the second cluster or the second cluster of the other party or the independent party device.

8. The method of claim 1, wherein: Each data element in the privacy data set has a corresponding number; the intersection result corresponding to any local partition includes the number of the same data element in the partition and the partition of other participants corresponding to the partition.

9. The method of claim 1, wherein: The obtaining of the multi-level ciphertext of the data element in each local partition by the first cluster with the assistance of the second cluster of the other participant includes: obtaining the multi-level ciphertext of the data element in each local partition in parallel by the first cluster with the assistance of the second cluster of the other participant; The method of assisting the first cluster of other participants to obtain the multi-level ciphertext of data elements in each partition of other participants through the second cluster includes: assisting the first cluster of other participants to obtain the multi-level ciphertext of data elements in each partition of other participants in parallel through the second cluster; The obtaining the intersection results corresponding to each local partition through the first cluster includes: obtaining the intersection results corresponding to each local partition in parallel through the first cluster.

10. A secure intersection system, wherein: Two or more participants respectively deploy the system, the system includes a first cluster and a second cluster, the first cluster of each participant stores its private data set, and the private data set includes multiple data elements; The first cluster is used to partition the data elements in its private data set according to a preset partitioning algorithm to obtain multiple local partitions, wherein the partitioning algorithm makes the multiple local partitions correspond one-to-one with the multiple partitions obtained by other participants, and the partitions to which the same data elements in the private data sets of different participants belong correspond; The first cluster is further used to: obtain multi-level ciphertexts of data elements in each local partition with the assistance of the second cluster of other participants; the multi-level ciphertexts of the data elements are obtained by encrypting the data elements twice or more using a commutative encryption algorithm; The second cluster is used to: assist the first cluster of other participants to obtain multi-level ciphertexts of data elements in each partition of other participants; The first cluster is further used to obtain the intersection results corresponding to each local partition, wherein the intersection result corresponding to the partition indicates the intersection of the multi-level ciphertext of each data element in the partition and the multi-level ciphertext of each data element in the partition of other participants corresponding to the partition; The first cluster is further used to determine the intersection of the private data sets of each participant based on the intersection results corresponding to the multiple local partitions.