A multi-party secure aggregation method and system

Abstract

The embodiment of the specification discloses a kind of multi-party secure aggregation method and system, multi-party includes multiple participants, the method is applied to any participant, the method includes: the private data held is divided into multiple groups of sub data corresponding to multiple substructures;For each substructure: execute start operation or relay operation;Start operation includes sending first ciphertext to the next neighbor participant, first ciphertext is obtained based on the target sub data of the first party encryption, target sub data is the sub data corresponding to substructure;Relay operation includes: obtain second ciphertext from the previous neighbor participant;Third ciphertext is obtained based on the second ciphertext of the data of the first party's substructure corresponding to substructure;In response to satisfying preset condition, third ciphertext is sent to decryption party, for obtaining the decryption result corresponding to third ciphertext;In response to not satisfying preset condition, third ciphertext is sent to the next neighbor participant.

Description

Technical Field

[0001] This specification relates to the field of information security technology, and in particular to a multi-party security aggregation method and system. Background Technology

[0002] Multi-party data aggregation is a technology widely used in various business scenarios. For example, in federated learning scenarios for machine learning models across various business domains, it involves aggregating the gradient data held by multiple participants in the federated learning process to enable them to jointly train the machine learning model. Furthermore, given the increasingly important role of data in today's world, data protection is crucial in many applications. For instance, in multi-party data aggregation scenarios, it is sometimes necessary to protect the private data held by each participant to prevent its leakage to other parties, thus achieving secure aggregation of multi-party data.

[0003] Therefore, there is an urgent need for a secure multi-party aggregation method and system to achieve secure aggregation of multi-party data. Summary of the Invention

[0004] One aspect of this specification provides a multi-party secure aggregation method, wherein the multi-party includes multiple participating parties, the method is applied to any participating party, and the method includes: dividing private data held by the party into multiple sets of sub-data corresponding to multiple substructures; for each substructure: performing a startup operation or a relay operation; the startup operation includes sending a first ciphertext to a subsequent neighboring participating party, the first ciphertext being obtained by encrypting the party's target sub-data, the target sub-data being the sub-data corresponding to the substructure; the relay operation includes: obtaining a second ciphertext from a previous neighboring participating party; obtaining a third ciphertext based on the second ciphertext corresponding to the data of the party's substructure; in response to satisfying a preset condition, sending the third ciphertext to a decryption party to obtain the decryption result corresponding to the third ciphertext; in response to not satisfying the preset condition, sending the third ciphertext to a subsequent neighboring participating party.

[0005] Another aspect of the embodiments of this specification provides a multi-party secure aggregation system, wherein the multi-party includes multiple participating parties, the system is deployed on any of the participating parties, and the system includes: a partitioning module, used to partition the private data held by the participant into multiple sets of sub-data corresponding to multiple substructures; an operation module, used for each substructure to: perform a startup operation or a relay operation; the startup operation includes sending a first ciphertext to the next neighboring participant, the first ciphertext being obtained based on the encryption of the participant's target sub-data, the target sub-data being the sub-data corresponding to the substructure; the relay operation includes: obtaining a second ciphertext from the previous neighboring participant; obtaining a third ciphertext based on the second ciphertext corresponding to the data of the participant's substructure; in response to meeting a preset condition, sending the third ciphertext to the decryption party to obtain the decryption result corresponding to the third ciphertext; in response to not meeting the preset condition, sending the third ciphertext to the next neighboring participant.

[0006] Another aspect of the embodiments of this specification provides a multi-party secure aggregation apparatus, including at least one storage medium and at least one processor, wherein the at least one storage medium is used to store computer instructions; and the at least one processor is used to execute the computer instructions to implement a multi-party secure aggregation method.

[0007] Another aspect of the embodiments of this specification provides a storage medium for storing computer instructions that, when executed by a processor, implement a multi-party secure aggregation method. Attached Figure Description

[0008] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0009] Figure 1 These are exemplary application scenario diagrams of a multi-party security aggregation system shown in some embodiments of this specification;

[0010] Figure 2 These are exemplary schematic diagrams showing multiple sets of sub-data corresponding to multiple substructures, according to some embodiments of this specification;

[0011] Figure 3 This is an exemplary flowchart of a multi-party secure aggregation method according to some embodiments of this specification;

[0012] Figure 4 These are exemplary schematic diagrams illustrating relay operations according to some embodiments of this specification;

[0013] Figure 5 These are exemplary schematic diagrams illustrating a multi-party secure aggregation method according to other embodiments of this specification;

[0014] Figure 6 This is an exemplary block diagram of a multi-party security aggregation system according to some embodiments of this specification. Detailed Implementation

[0015] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0016] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0017] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0018] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0019] Multi-party data aggregation refers to the aggregation of private data held by multiple parties to achieve the goal of integrating their private data. Aggregation can include various data aggregation methods, such as data summation (the result of summation aggregation can also be used to achieve other data aggregation methods, such as average aggregation), data multiplication (e.g., multiplying vectors, arrays, etc., element by element), etc. For ease of explanation, the embodiments in this specification mainly use data summation aggregation as an example to illustrate the multi-party data aggregation method. The multi-party data aggregation method proposed in this specification can also be used for other types of data aggregation.

[0020] Multi-party data aggregation can be widely applied to various business scenarios. For example, it can be applied to federated learning scenarios for machine learning models in various business domains (such as text classification and entity relationship prediction). In this scenario, the private gradient data (e.g., gradient vectors) held by multiple federated learning participants can be summed and aggregated, enabling multiple participants to collaboratively train the machine learning model. Another example is user risk control scenarios, where the private user credit scores held by multiple financial service companies (e.g., user credit scores composed of multiple types of scores) can be averaged and aggregated, enabling comprehensive user credit score data for user risk monitoring.

[0021] In some cases (e.g., when the private data held by each party involves privacy information), the private data held by multiple parties needs to be protected to ensure that the private data of each party is not leaked to other participants during the process of multi-party data aggregation, i.e., secure multi-party data aggregation. Based on this, this specification proposes a secure multi-party data aggregation method to achieve secure multi-party data aggregation.

[0022] In multi-party secure aggregation methods, each participating party can encrypt its private data, and an additional party (referred to as the decryptor) can be added to decrypt the encrypted data during the aggregation process. This protects the private data held by each party from being leaked to other participating parties during the aggregation process. However, this method still carries the risk of data leakage in some situations. For example, if the decryptor is untrusted, and can obtain the encrypted private data of a participating party, it can directly obtain the private data and cause leakage. Therefore, this specification also proposes a multi-party secure aggregation method that ensures the private data held by each party is not leaked to other participating parties and the decryptor during the aggregation process. Furthermore, it is desirable to improve the data processing performance (e.g., data processing efficiency, resource allocation rate) of the processing equipment during multi-party secure aggregation. Therefore, this specification also proposes a multi-party secure aggregation method that enables the processing equipment of each participating party to efficiently achieve multi-party secure data aggregation, thereby improving the data processing performance of the processing equipment.

[0023] Figure 1 This is an exemplary application scenario diagram of a multi-party security aggregation system according to some embodiments of this specification.

[0024] System 100 may include participant processing device 110, decryption processing device 120, and network 130.

[0025] In some embodiments, the functions of each participant in the multi-party secure aggregation (e.g., participants 1 to n holding private data) can be implemented by participant processing devices 110 (e.g., processing devices 110-1 for participant 1, 110-2 for participant 2, ..., 110-n for participant n). In some embodiments, the functions of the decryptor in the multi-party secure aggregation can be implemented by decryptor processing device 120.

[0026] The processing device (e.g., participant processing device 110, decryption processing device 120) may include one or more sub-processing devices (e.g., single-core processing device or multi-core multi-chip processing device). In some embodiments, the processing device may include various types of processors, systems, platforms, etc., or any combination thereof.

[0027] Participant processing device 110 (e.g., processing devices 110-1, 110-2, ..., 110-n) and decryption processing device 120 can communicate with one or more components in system 100 via network 130 to implement various processes in the multi-party secure aggregation method.

[0028] The participant processing device 110 can be used to process all information and / or data related to the participants. In some embodiments, the participant processing device 110 (e.g., processing devices 110-1, 110-2, ..., 110-n) can encrypt its own private data (e.g., sub-data corresponding to each substructure obtained by dividing private data) to obtain encryption results 140 (e.g., the first ciphertext 140-1 of participant 1, the first ciphertext 140-2 of participant 2, ..., the first ciphertext 140-n of participant n). For more details about the first ciphertext, see [link to documentation]. Figure 3 And its related descriptions.

[0029] Participating processing devices 110, such as processing devices 110-1, 110-2, ..., 110-n, can interact via network 130 and perform startup or relay operations. For more information on interactions between participants and the execution of startup or relay operations, please refer to... Figure 3 And its related descriptions.

[0030] Participating processing devices 110 (e.g., processing devices 110-1, 110-2, ..., 110-n) can send the third ciphertext 150 to the decrypting processing device 120 via network 130. The decrypting processing device 120 can decrypt the third ciphertext 150 to obtain the decryption result 160 corresponding to the third ciphertext 150. The decryption result 160 can be the result of aggregating the private data of each participating party (e.g., the sub-data corresponding to each substructure), such as the summation and aggregation result (7.6, 9) of the sub-data of participating party 1 (0.4, 1.9), participating party 2 (0.5, 1.8), ..., and participating party n (1.7, 2.3). Thus, system 100 can aggregate the private data of multiple parties, and during the data aggregation process, the private data of each party will not be leaked to other participating parties or the decrypting party.

[0031] In some embodiments, each participant may also obtain the decryption result 160, for example, the decryption processing device 120 sends the decryption result 160 to the participant processing device 110 (e.g., processing devices 110-1, 110-2, ..., 110-n) or other feasible acquisition methods.

[0032] For more information on the third ciphertext 150 and the decryption result 160, please refer to [link / reference]. Figure 3 And its related descriptions.

[0033] The information transmission relationships between the devices described above are merely examples, and this application is not limited to them.

[0034] It should be noted that the application scenarios are provided for illustrative purposes only and are not intended to limit the scope of this specification. Those skilled in the art can make various modifications or variations based on the description in this specification. For example, system 100 may also include a storage device. As another example, system 100 may be implemented on other devices to achieve similar or different functions. However, these changes and modifications will not depart from the scope of this specification.

[0035] Figure 3 This is an exemplary flowchart illustrating a multi-party secure aggregation method according to some embodiments of this specification.

[0036] Multi-party secure aggregation methods can involve multiple parties holding private data and the decryption party, enabling the secure aggregation of private data from multiple parties. For example... Figure 3 As shown, the multi-party secure aggregation method may involve participant 1 (310), participant 2 (320), participant 3 (330), participant 4 (340), participant 5 (350) and decryption party (360).

[0037] The private data held by multiple participants can be of various types, such as images, matrices, vectors, arrays, etc. Each participant's private data can have a certain structure, such as including a certain number of elements or being composed of multiple parts. In some embodiments, the private data held by each participant can have a common structure, such as the private images held by each participant being of the same size, the private matrices being of the same size, the private vectors being of the same length, or the private vectors having the same number of subvectors.

[0038] In some embodiments, Figure 3 The illustrated interaction flow can be collaboratively executed by the processing devices of the parties involved in the multi-party secure aggregation (e.g., the parties holding private data, the decryptor). For example, the portion of the interaction flow executed by the parties holding private data or the decryptor can be stored in the participants' storage devices (such as the processing device's built-in storage unit or external storage device) in the form of programs or instructions. When these programs or instructions are executed, they can realize the multi-party secure aggregation process. The steps in flow 300 of this specification (e.g., steps 302 and 304) are mainly illustrated using the execution of any one of the multiple parties holding private data as an example. Flow 300 can be applied to any one of the multiple parties.

[0039] In some embodiments, process 300 may be implemented by a multi-party secure aggregation system 600.

[0040] Step 302: Divide the private data held into multiple sets of sub-data corresponding to multiple substructures.

[0041] In some embodiments, step 302 may be performed by the partitioning module 610.

[0042] In some embodiments, the private data held by the participants can be divided into multiple parts by various feasible methods (e.g., by the user, by the processing device according to a preset method, etc.). Each part of the data is divided is called a sub-data, and the structure of the private data is also divided into multiple parts. Each part of the structure is divided is called a sub-structure, and multiple sets of sub-data correspond to multiple sub-structures.

[0043] Figure 2 This is an exemplary schematic diagram showing multiple sets of sub-data corresponding to multiple substructures, according to some embodiments of this specification.

[0044] like Figure 2 As shown, participants 1 through 5 hold private data 210-1, 210-2, 210-3, 210-4, and 210-5, respectively. For illustrative purposes only, the private data of participants 1 through 5 are gradient vectors obtained during model training in federated learning. Each vector contains 11 elements, and each private data point consists of multiple sub-vectors, each corresponding to the gradient data of a specific structure of the model. For example, participant 1's private data 210-1 is (1.11, 1.29, 1.31, 1.21, 1.32, 1.55, 1.54, 1.14, 1.13, 1.61, 1.24), which includes seven sub-vectors: (1.11, 1.29), (1.31), (1.21, 1.32), (1.55), (1.54), (1.14, 1.13), and (1.61, 1.24). The first, second, and third elements of the private data of participants 1 to 5 can be divided into substructure 1, the fourth and fifth elements into substructure 2, ..., and the tenth and eleventh elements into substructure 5. Each substructure includes corresponding sub-data. For example, the sub-data corresponding to substructure 3 of participant 2 is (1.35, 1.12).

[0045] Multiple participants can share multiple substructures. For example, Figure 2 The private data 210-1, 210-2, 210-3, 210-4 and 210-5 of participants 1 to 5 are divided into 5 groups of sub-data corresponding to the common substructure 1 to substructure 5.

[0046] The number of sub-data items, or substructures, obtained from the partitioning of private data can be determined according to requirements. In some embodiments, the number of partitioned sub-data items, or substructures, is the same as the number of participants holding the private data. For example, if there are 5 participants, the private data is partitioned into 5 sub-data items corresponding to 5 substructures.

[0047] In some embodiments, the private data can be partitioned uniformly. This uniform partitioning can be absolutely uniform (e.g., each substructure has an equal amount of data) or approximately uniform (e.g., each substructure has a relatively similar amount of data). By uniformly partitioning the private data, the resources (e.g., runtime, computing resources) required for processing each substructure can be more evenly distributed in subsequent operations, thereby improving the data processing performance of each processing device during secure aggregation of multi-party data.

[0048] Step 304, for each substructure: perform a startup operation or a relay operation.

[0049] In some embodiments, step 304 may be performed by operation module 620.

[0050] Multiple participants can establish sequential adjacency relationships. In some embodiments, multiple participants can establish sequential adjacency relationships in a circular pattern.

[0051] like Figure 3 As shown, participants 1 to 5 establish a circular adjacency relationship. For each participant (this participant), its adjacent participants can include the previous neighbor and the next neighbor.

[0052] In some embodiments, a preceding neighbor participant refers to a participant that transmits data to itself. For example, participant 5 (350) transmits data to participant 1 (310), where participant 1 is itself and participant 5 is its preceding neighbor participant.

[0053] In some embodiments, a subsequent neighboring participant refers to a participant that receives data transmitted by itself. For example, participant 3 (330) receives data transmitted by participant 2 (320), where participant 2 is itself and participant 3 is its subsequent neighboring participant.

[0054] The adjacency relationship between multiple participants can be represented in various feasible ways, such as numbering the participants.

[0055] The data corresponding to each substructure can be processed separately to aggregate multiple sub-data from multiple participants in each substructure, resulting in the aggregated sub-data for each substructure. The aggregated sub-data results from multiple substructures are then combined to obtain the aggregated private data from multiple participants.

[0056] For each substructure, the corresponding processing may include: multiple participants sequentially performing a startup operation or a relay operation.

[0057] In the processing of a substructure, the first operation performed is called the startup operation. For each substructure, there is one participant that performs the startup operation, and the participant that performs the startup operation can be called the first participant for that substructure.

[0058] In the processing corresponding to a substructure, after the first participant performs the initiation operation, the operations performed sequentially by other participants are called relay operations. For example, such as... Figure 3 As shown, the processing corresponding to substructure 2 may include: participant 2 performing a startup operation, and participants 3, 4, 5, and 1 performing relay operations in sequence.

[0059] In some embodiments, for at least two of the multiple substructures, the first participant performing the startup operation is different. For example, for substructure 1, substructure 2, substructure 3, substructure 4, and substructure 5, the first participant performing the startup operation can be participant 1, participant 2, participant 3, participant 4, and participant 5, respectively.

[0060] Since the startup operations corresponding to different substructures can start simultaneously, allowing different participants to perform startup operations for different substructures allows the processing of multiple substructures to be carried out in parallel, improving the efficiency of multi-party data aggregation.

[0061] In some embodiments, for each substructure, the initiation operation includes: the first participant sending its first ciphertext to the next neighboring participant.

[0062] The first ciphertext of a participant refers to the ciphertext data obtained by encrypting its own target sub-data. The target sub-data is the sub-data corresponding to the currently pointed-to sub-structure. For example, such as... Figure 3 As shown, the startup operation corresponding to substructure 2 is executed by participant 2. The target sub-data of participant 2 is (2.34, 1.26), which is encrypted to obtain the first ciphertext Enc{(2.34, 1.26)}.

[0063] In some embodiments, for each substructure, the relay operation performed by a participant includes: obtaining a second ciphertext from a previous neighboring participant; and obtaining a third ciphertext based on the participant's data corresponding to the currently referred substructure and the second ciphertext.

[0064] In some embodiments, when the participant performing the relay operation is the next-next participant of the first participant, the obtained second ciphertext is the first ciphertext of the first participant. For example, for substructure 2, the first participant performing the startup operation is participant 2, and the target subdata of participant 2 is (2.34, 1.26). The relay operation performed by the next-next participant of participant 2, namely participant 3, includes: obtaining the first ciphertext Enc{(2.34, 1.26)} from participant 2; and obtaining the third ciphertext based on the data of this party corresponding to the currently referred substructure and the first ciphertext Enc{(2.34, 1.26)}.

[0065] In some embodiments, when the participant performing the relay operation is not the next neighbor of the first participant, the second ciphertext obtained is the third ciphertext of the previous neighbor of that participant. For example, for substructure 2, the first participant performing the startup operation is participant 2, and the relay operation performed by participant 4 includes: obtaining the third ciphertext (e.g., third ciphertext a3) of the previous neighbor participant (i.e., participant 3), and obtaining the third ciphertext (e.g., third ciphertext a4) of the participant based on the data of the participant corresponding to the currently referred substructure and the third ciphertext of the previous neighbor participant.

[0066] In some embodiments, the third ciphertext of a participant is the sum of the target sub-data of the participant and all participants that performed the initiation and relay operations before it. For example, for substructure 2, participant 2 first performs the initiation operation, followed by participants 3, 4, 5, and 1 performing relay operations in sequence. Participant 2's target sub-data is (2.34, 1.26). After participating 2 performs the initiation operation, it obtains the first ciphertext Enc{(2.34, 1.26)} and transmits it to participant 3. Participant 3's target sub-data is (1.13, 1.09). Participant 3 performs the relay operation and obtains the third ciphertext Enc{(2.34, 1.26) + (1.13, 1.09)}. For more information on relay operations and the third ciphertext, see [link to relevant documentation]. Figure 4 And its related descriptions.

[0067] In some embodiments, for each substructure, the relay operation performed by the participant further includes: in response to a preset condition being met, the participant sends the third ciphertext to the decryptor 360, which can decrypt the third ciphertext to obtain the corresponding decryption result. For example, for substructure 2, participant 1 sends the third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)+(1.46, 2.34)+(1.21, 1.32)} to the decryptor 360, and the corresponding decryption result, i.e., the plaintext corresponding to the third ciphertext, is (2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)+(1.46, 2.34)+(1.21, 1.32)=(8.07, 8.75). Alternatively, in response to a preset condition not being met, the participant sends the third ciphertext to the next neighboring participant. For example, in substructure 2, participant 3 sends its third ciphertext to participant 4.

[0068] In some embodiments, the preset condition may include: in the process corresponding to a substructure, the current party is the last participant to perform the relay operation. For example, for substructure 2, in its corresponding process, participants 3, 4, 5 and 1 perform relay operations in sequence. When the current party is the last participant to perform the relay operation (i.e., participant 1), the preset condition is met; otherwise, the preset condition is not met.

[0069] In some embodiments, the preset conditions may include: the third ciphertext of the party meets preset ciphertext conditions. For example, the number of operations performed to obtain the third ciphertext of the party reaches a threshold (the threshold may be equal to the number of start operations, relay operations, etc. that need to be performed in the processing corresponding to a substructure), or the ciphertext size of the third ciphertext of the party exceeds a threshold (the threshold may be equal to the ciphertext size of the sum of the target sub-data of multiple participants), etc.

[0070] The data encryption used in the embodiments of this specification (e.g., encrypting target sub-data to obtain the first ciphertext) can be homomorphic encryption, such as addition homomorphic encryption that supports addition operations, multiplication homomorphic encryption that supports multiplication operations, or other semi-homomorphic encryption methods, such as full homomorphic encryption that supports both addition and multiplication operations. It can also be other encryption methods that can achieve similar functionality to homomorphic encryption. Homomorphic encryption can support: performing specific forms of algebraic operations (e.g., adding plaintext to ciphertext, encrypting ciphertext with ciphertext, multiplying ciphertext with plaintext, multiplying ciphertext with ciphertext, etc.) on the ciphertext to obtain an encrypted result, and decrypting the result of this operation to obtain the same result as performing the same operation on the plaintext.

[0071] In some embodiments, each participant can use a public key to encrypt the target sub-data to obtain a first ciphertext, and the decryptor can use the private key corresponding to the public key to decrypt the obtained third ciphertext to obtain the corresponding decryption result. The public and private keys can be generated in various feasible ways, such as by the decryptor or other trusted third parties.

[0072] In some embodiments, for each substructure, the multi-party secure aggregation method may further include distributing the decryption result corresponding to the third ciphertext to each participant. Thus, each participant can obtain the sub-data aggregation result corresponding to each substructure.

[0073] In some embodiments, the decryption result corresponding to the third ciphertext can be distributed to each participant in various feasible ways. For example, the decryptor distributes the decryption result to each participant; one of the participants obtains the decryption result and distributes it to other participants in various feasible ways (e.g., the participant sends the decryption result to its next-neighbor participant, and the next-neighbor participant who obtained the decryption result then continues to send the decryption result to its next-neighbor participant). For more details on distributing the decryption result corresponding to the third ciphertext to each participant, see [link to relevant documentation]. Figure 5 And its related descriptions.

[0074] Figure 4 These are exemplary schematic diagrams illustrating relay operations according to some embodiments of this specification.

[0075] Figure 4 The content primarily uses the relay operations executed sequentially by each participant within the processing of a substructure as an example. For each substructure, it can be explained according to... Figure 4 The Chinese method enables each participating party to execute relay operations sequentially.

[0076] like Figure 4 As shown, taking substructure 2 as an example, in the processing corresponding to substructure 2, the relay operations executed sequentially by each participant include: participant 3 executes the first relay operation 410, participant 4 executes the second relay operation 420, participant 5 executes the third relay operation 430, and participant 1 executes the fourth relay operation 440.

[0077] In some embodiments, the first relay operation 410 performed by participant 3 (the first participant corresponding to substructure 2, i.e., the next neighbor participant of participant 2) includes: participant 3 obtaining a second ciphertext from participant 2, where the second ciphertext is the first ciphertext Enc{(2.34, 1.26)} obtained by participant 2 based on the sub-data (2.34, 1.26) corresponding to substructure 2; participant 3 obtaining a third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)} based on the data corresponding to its own substructure and the obtained second ciphertext. At this time, the first relay operation 410 does not meet the preset conditions, and participant 3 sends its own third ciphertext to the next neighbor participant (participant 4).

[0078] In some embodiments, the second relay operation 420 performed by participant 4 includes: participant 4 obtaining a second ciphertext from participant 3, where the second ciphertext is participant 3's third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)}; participant 4 obtaining its own third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)} based on the data corresponding to its own substructure and the obtained second ciphertext. At this time, the second relay operation 420 does not meet the preset conditions, and participant 4 sends its own third ciphertext to the next neighboring participant (participant 5).

[0079] In some embodiments, the third relay operation 430 performed by participant 5 includes: participant 5 obtaining a second ciphertext from participant 4, where the second ciphertext is participant 4's third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)}; participant 5 obtaining its own third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)+(1.46, 2.34)} based on the data corresponding to its own substructure and the obtained second ciphertext. At this time, the third relay operation 430 does not meet the preset conditions, and participant 5 sends its own third ciphertext to the next neighboring participant (participant 1).

[0080] In some embodiments, the fourth relay operation 440 performed by participant 1 includes: participant 1 obtaining a second ciphertext from participant 5, where the second ciphertext is participant 5's third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)+(1.46, 2.34)}; participant 1 obtaining its own third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)+(1.46, 2.34)+(1.21, 1.32)} based on the data corresponding to its own substructure and the obtained second ciphertext. At this time, the fourth relay operation 440 satisfies the preset conditions, and participant 1 sends its own third ciphertext to the decryptor, who decrypts participant 1's third ciphertext to obtain the corresponding decryption result. For example, the decryptor decrypts the third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)+(1.46, 2.34)+(1.21, 1.32)} and obtains the corresponding decryption result (2.34, 1.26)+(1.13, 1.09)+(1.93, 2.74)+(1.46, 2.34)+(1.21, 1.32)=(8.07, 8.75).

[0081] In some embodiments, during the relay operation performed by each participating party, obtaining the third ciphertext based on the data corresponding to its own substructure and the second ciphertext may include: obtaining the third ciphertext based on its own target sub-data (i.e., the sub-data corresponding to its own substructure) and the second ciphertext through a specified operation (e.g., specifying the operation as a plaintext-to-ciphertext algorithm in summation aggregation, or specifying the operation as a plaintext-to-ciphertext algorithm in multiplication aggregation, etc.); or obtaining the third ciphertext based on its own first ciphertext (i.e., the ciphertext of the sub-data corresponding to its own substructure) and the second ciphertext through a specified operation (e.g., specifying the operation as a ciphertext-to-ciphertext algorithm in summation aggregation, or specifying the operation as a ciphertext-to-ciphertext algorithm in multiplication aggregation, etc.).

[0082] Taking the first relay operation 410 performed by participant 3 as an example: Participant 3 can use its target sub-data (1.13, 1.09) and the obtained second ciphertext (i.e., participant 2's first ciphertext) to calculate Enc{(2.34, 1.26)}+(1.13, 1.09) using a plaintext encryption algorithm to obtain the third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)}. Alternatively, participant 3 can use its first ciphertext Enc{(1.13, 1.09)} and the obtained second ciphertext (i.e., participant 2's first ciphertext) to calculate Enc{(2.34, 1.26)}+Enc{(1.13, 1.09)} using a ciphertext encryption algorithm to obtain the third ciphertext Enc{(2.34, 1.26)+(1.13, 1.09)}.

[0083] Figure 5 This is an exemplary schematic diagram of a multi-party secure aggregation method according to other embodiments of this specification.

[0084] In some embodiments, for each substructure, the multi-party secure aggregation method may include distributing the decryption result corresponding to the third ciphertext to each participant, so that each participant can obtain the sub-data aggregation result corresponding to each substructure. Figure 5 The content primarily uses the example of distributing the decryption result corresponding to the third ciphertext to each participant for a given substructure as an illustration. For each substructure, it can be based on... Figure 5 The Chinese method implements the distribution of the decryption result corresponding to the third ciphertext to each participant.

[0085] In some embodiments, such as Figure 5 As shown, for each substructure, one of the multiple participants, such as the last participant performing the relay operation, can obtain the decryption result corresponding to the third ciphertext obtained by the decryptor, and the decryption result can be obtained by each participant through interaction between multiple participants.

[0086] In some embodiments, multiple participants may establish a sequential adjacency relationship (e.g. Figure 3 In the multi-party secure aggregation method described above (establishing adjacent relationships in a ring), for each substructure, distributing the decryption result corresponding to the third ciphertext to each participant includes: multiple participants sequentially performing an initial distribution operation or a continued distribution operation.

[0087] In the distribution of decryption results for a substructure, the first operation performed is called the initial distribution operation. For each substructure, one participant performs the initial distribution operation. The participant performing the initial distribution operation can also be the last participant performing the relay operation. For example... Figure 5 As shown, for substructure 2, the participant performing the initial distribution operation 510 is the last participant (i.e., participant 1) to perform the relay operation. The initial distribution operation may include: obtaining the decryption result from the decryptor and sending the decryption result to the next neighboring participant.

[0088] In the decryption result distribution process corresponding to a substructure, the distribution operations that the remaining participants continue to perform sequentially after one participant performs the initial distribution operation are called continuation distribution operations. Continuation distribution operations may include: obtaining the decryption result from the preceding neighboring participant and sending the decryption result to the following neighboring participant.

[0089] like Figure 5As shown, the distribution process of the decryption result (e.g., (8.07, 8.75)) corresponding to substructure 2 may include: participant 1 performing an initial distribution operation 510, participant 2 performing a first continued distribution operation 520, participant 3 performing a second continued distribution operation 530, and participant 4 performing a third continued distribution operation 540.

[0090] In some embodiments, the initial distribution operation 510 performed by participant 1 includes: obtaining the decryption result from the decryptor and sending the decryption result to its neighboring participant (i.e., participant 2).

[0091] In some embodiments, the first continued distribution operation 520 performed by participant 2 includes: obtaining the decryption result from the previous neighboring participant (participant 1) and sending the decryption result to the next neighboring participant (participant 3).

[0092] In some embodiments, the second continued distribution operation 530 performed by participant 3 includes: obtaining the decryption result from the previous neighboring participant (participant 2) and sending the decryption result to the next neighboring participant (participant 4).

[0093] In some embodiments, the third continued distribution operation 540 performed by participant 4 includes: obtaining the decryption result from the previous neighboring participant (participant 3) and sending the decryption result to the next neighboring participant (participant 5).

[0094] like Figure 5 As shown, for substructure 2, after participant 1 completes the initial distribution operation, and participants 2, 3 and 4 complete the subsequent distribution operation in turn, participants 1 to 5 all obtain the decryption result corresponding to substructure 2, that is, they obtain the sub-data aggregation result corresponding to substructure 2.

[0095] In some embodiments, for at least two of the multiple substructures, the participants performing the initial distribution operation are different. For example, for substructure 2, the initial distribution operation is performed by participant 1; for substructure 3, the initial distribution operation is performed by participant 2.

[0096] Since the initial distribution operations corresponding to different substructures can be performed simultaneously, allowing different participants to perform the initial distribution operations for different substructures allows the decryption result distribution processing for multiple substructures to be carried out in parallel. This enables the efficient distribution of the decryption results corresponding to the substructures to each participant, which is beneficial to improving the overall distribution efficiency.

[0097] It should be noted that the above descriptions of the various processes are for illustrative purposes only and do not limit the scope of this specification. Those skilled in the art can make various modifications and changes to the processes under the guidance of this specification. However, these modifications and changes are still within the scope of this specification. For example, changes to the process steps in this specification, such as adding preprocessing steps, storage steps, or other data processing steps.

[0098] It should be noted that in some embodiments of this specification, terms such as "previous neighbor participant" and "next neighbor participant" are used to distinguish different participants involved in the multi-party secure aggregation method. However, "previous neighbor participant" and "next neighbor participant" are only used to distinguish participants and do not impose any restrictions on the participants.

[0099] Figure 6 This is an exemplary block diagram of a multi-party security aggregation system according to some embodiments of this specification.

[0100] The multi-party security aggregation system 600 can be deployed on any participant (e.g., on a participant's processing device). Figure 6 As shown, the multi-party security aggregation system 600 may include: a partitioning module 610 and an operation module 620.

[0101] In some embodiments, the partitioning module 610 can be applied to any participant in the multi-party secure aggregation method, and the partitioning module 610 can be used to partition the private data held by the participant into multiple sets of sub-data corresponding to multiple substructures.

[0102] In some embodiments, the operation module 620 can be applied to any participant in the multi-party secure aggregation method. The operation module 620 can be used to perform a startup operation or a relay operation for each substructure. The startup operation includes sending a first ciphertext to the next neighboring participant, the first ciphertext being obtained by encrypting the target sub-data of the participant, the target sub-data being the sub-data corresponding to the substructure. The relay operation includes obtaining a second ciphertext from the previous neighboring participant; obtaining a third ciphertext based on the data corresponding to the participant's substructure and the second ciphertext; in response to meeting a preset condition, sending the third ciphertext to the decryption party to obtain the decryption result corresponding to the third ciphertext; in response to not meeting the preset condition, sending the third ciphertext to the next neighboring participant.

[0103] For a detailed description of each module of the system shown above, please refer to the flowchart section of this manual, for example... Figure 3 , Figure 4 and Figure 5 And related explanations.

[0104] It should be understood that Figure 6The systems and modules shown can be implemented in various ways. For example, in some embodiments, the systems and modules can be implemented by hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the methods and systems described above can be implemented using computer-executable instructions and / or included in processor control code, for example, on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The systems and modules of this specification can be implemented not only by hardware circuits such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., but also by software, for example, executed by various types of processors, or by a combination of the aforementioned hardware circuits and software (e.g., firmware).

[0105] It should be noted that the above description of the multi-party security aggregation system and its modules is for convenience only and should not be construed as limiting this specification to the scope of the embodiments described. It is understood that those skilled in the art, after understanding the principles of the system, may arbitrarily combine the various modules or construct subsystems connected to other modules without departing from these principles. For example, in some embodiments, the partitioning module 610 and the operation module 620 may be different modules within the same system, or a single module may implement the functions of two or more of the aforementioned modules. For example, various modules may share a storage module, or each module may have its own separate storage module. Such variations are all within the scope of protection of this specification.

[0106] This specification also provides a multi-party secure aggregation device, including at least one storage medium and at least one processor. The at least one storage medium is used to store computer instructions; the at least one processor is used to execute the computer instructions to implement a multi-party secure aggregation method. The method is applied to any participating party and includes: dividing its private data into multiple sets of sub-data corresponding to multiple substructures; for each substructure: performing a startup operation or a relay operation; the startup operation includes sending a first ciphertext to a subsequent participating party, the first ciphertext being obtained based on encrypting the party's target sub-data, the target sub-data being the sub-data corresponding to the substructure; the relay operation includes: obtaining a second ciphertext from a previous participating party; obtaining a third ciphertext based on the second ciphertext corresponding to the party's substructure; in response to meeting a preset condition, sending the third ciphertext to a decryption party to obtain the decryption result corresponding to the third ciphertext; in response to not meeting the preset condition, sending the third ciphertext to a subsequent participating party.

[0107] The beneficial effects that the embodiments of this specification may bring include, but are not limited to: (1) By establishing a ring-shaped adjacency relationship among multiple participants, each participant divides the private data into multiple sets of sub-data corresponding to multiple substructures. For each substructure, multiple participants sequentially perform startup or relay operations, which can realize the parallel processing of multiple substructures. Each participant can simultaneously send and receive data and process data. Moreover, the workload of each participant is very evenly distributed, and each participant can transmit data at high speed. No participant is idle, making full use of the bandwidth of each participant. The performance of the entire multi-party secure aggregation system reaches a very good state. (2) Furthermore, the aforementioned method can improve the anti-collusion capability of multi-party data aggregation. That is, no matter which participant the decryption party colludes with, it cannot obtain the private data held by other participants, thus ensuring data security during the multi-party data aggregation process. (3) In addition, by establishing a ring-shaped adjacency relationship among multiple participants to realize multi-party secure aggregation, it is only necessary to number each participant and send data to the next adjacent participant in the order of the number, which reduces the difficulty of maintaining the network topology of the multi-party secure aggregation system.

[0108] It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects may be any one or a combination of the above, or any other possible beneficial effects.

[0109] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0110] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0111] Furthermore, those skilled in the art will understand that various aspects of this specification can be described and illustrated in several patentable ways or situations, including any new and useful combination of processes, machines, products, or substances, or any new and useful improvements thereof. Accordingly, various aspects of this specification can be implemented entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. All of the above hardware or software may be referred to as a “data block,” “module,” “engine,” “unit,” “component,” or “system.” Furthermore, various aspects of this specification may be represented as a computer product located on one or more computer-readable media, including computer-readable program code.

[0112] Computer storage media may contain a propagated data signal containing computer program code, for example, on baseband or as part of a carrier wave. This propagated signal may take various forms, including electromagnetic, optical, and suitable combinations thereof. Computer storage media can be any computer-readable medium other than a computer-readable storage medium, which can be connected to an instruction execution system, apparatus, or device to enable communication, propagation, or transmission of a program for use. The program code located on the computer storage medium can be propagated through any suitable medium, including radio, cable, fiber optic cable, RF, or similar media, or any combination of the above media.

[0113] The computer program code required for the operation of each part of this manual 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, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP; dynamic programming languages ​​such as Python, Ruby, and Groovy; or other programming languages. This program code can run entirely on the user's computer, or as a standalone software package on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any network, such as a local area network (LAN) or wide area network (WAN), or connected to an external computer (e.g., via the Internet), or in a cloud computing environment, or used as a service such as Software as a Service (SaaS).

[0114] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0115] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0116] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0117] For each patent, patent application, patent application publication, and other material, such as articles, books, specifications, publications, and documents, referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0118] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and are considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. A method for secure aggregation of multiple parties, wherein the multiple parties include multiple participants, the multiple participants have multiple common substructures, and the multiple participants establish a circular adjacency relationship; The method is applied to any participating party, and the method includes: Divide the private data you hold into multiple sets of sub-data corresponding to multiple sub-structures; For each substructure: the plurality of participants sequentially perform a startup operation or a relay operation, wherein the relay operation is performed after the startup operation; The initiation operation includes sending a first ciphertext to the next neighboring participant. The first ciphertext is obtained by encrypting the target sub-data of the participant, and the target sub-data is the sub-data corresponding to the sub-structure. The relay operation includes: Obtain the second ciphertext from the previous neighboring participant; The third ciphertext is obtained based on the data corresponding to the substructure described above and the second ciphertext. In response to the fulfillment of preset conditions, the third ciphertext is sent to the decryption party to obtain the decryption result corresponding to the third ciphertext; In response to the failure to meet the preset conditions, the third ciphertext is sent to the next neighboring participant.

2. The method according to claim 1, wherein for at least two of the plurality of substructures, the participants performing the startup operation are different.

3. The method according to claim 1, wherein the number of the plurality of substructures is the same as the number of the plurality of participants.

4. The method according to claim 1, wherein for each substructure, obtaining the third ciphertext based on the data corresponding to the substructure and the second ciphertext comprises: Based on the target sub-data and the second ciphertext, a specified operation is performed to obtain the third ciphertext; or The third ciphertext is obtained by performing a specified operation based on the first and second ciphertexts.

5. The method according to claim 1, wherein the preset conditions include one or more of the following: This party is the last participant to perform the relay operation; or The third ciphertext obtained by this party satisfies the preset ciphertext conditions.

6. The method according to claim 1, further comprising: For each substructure: perform the initial dispatch operation or continue the dispatch operation; The initial distribution operation includes: obtaining the decryption result from the decryptor and sending the decryption result to the next neighboring participant; The continued distribution operation includes: obtaining the decryption result from the previous neighboring participant and sending the decryption result to the subsequent neighboring participant.

7. A multi-party secure aggregation system, wherein the multi-party includes multiple participants, the multiple participants have multiple common substructures, and the multiple participants establish a ring-shaped adjacency relationship; The system is deployed at any participating party, and the system includes: The partitioning module is used to divide the private data held into multiple groups of sub-data corresponding to multiple substructures; The operation module is configured to, for each substructure, cause the plurality of participants to sequentially execute a startup operation or a relay operation, wherein the relay operation is executed after the startup operation; The initiation operation includes sending a first ciphertext to the next neighboring participant. The first ciphertext is obtained by encrypting the target sub-data of the participant, and the target sub-data is the sub-data corresponding to the sub-structure. The relay operation includes: Obtain the second ciphertext from the previous neighboring participant; The third ciphertext is obtained based on the data corresponding to the substructure described above and the second ciphertext. In response to the fulfillment of preset conditions, the third ciphertext is sent to the decryption party to obtain the decryption result corresponding to the third ciphertext; In response to the failure to meet the preset conditions, the third ciphertext is sent to the next neighboring participant.

8. A multi-party secure aggregation device, comprising at least one storage medium and at least one processor, the at least one storage medium being configured to store computer instructions; the at least one processor being configured to execute the computer instructions to implement the method as claimed in any one of claims 1-6.

9. A storage medium for storing computer instructions that, when executed by a processor, implement the method as claimed in any one of claims 1-6.

Images