Key generation method, device, apparatus, storage medium and program product

Abstract

This application discloses a key generation method, apparatus, device, storage medium, and program product, belonging to the field of secure computing technology. The method is applied to a first participant in a multi-party secure computing system, which also includes multiple second participants. The method includes: receiving first ciphertext sent by the multiple second participants; generating a first key fragment based on the first ciphertext sent by the multiple second participants and the private key of the first participant; encrypting the first key fragment using a joint public key to obtain a first fragment ciphertext; receiving second fragment ciphertext sent by the multiple second participants; and performing homomorphic addition on the second fragment ciphertext sent by the multiple second participants and the first fragment ciphertext to obtain a homomorphic computing key for the multi-party secure computing system. Therefore, this application can generate a homomorphic computing key for a multi-party secure computing system without revealing the private key of each participant.

Description

Technical Field

[0001] This application relates to the field of secure computing technology, and in particular to a key generation method, apparatus, device, storage medium, and program product. Background Technology

[0002] In multi-party secure computation scenarios, such as cross-border e-commerce, financial risk control, and medical data sharing, a threshold multi-key homomorphic encryption scheme is required to ensure the privacy and security of multi-party interactive data. The process of the threshold multi-key homomorphic encryption scheme is as follows: n participants each generate their own private and public keys, and run a distributed key generation (DKG) protocol to generate a joint public and private key for all n parties, as well as the computation key required for homomorphic computation. The joint public key is made public so that all participants can use it for encryption, and the computation key is sent to the data processing node (denoted as the Server) so that the Server can perform homomorphic computation on the ciphertext sent by each participant without decryption.

[0003] During secure computation, each party encrypts its message using a shared public key and sends the ciphertext to the server. Upon receiving the ciphertext, the server performs homomorphic computation with the aid of the computation key, obtaining the ciphertext result, which is then sent back to each participant. Each participant, upon receiving the ciphertext result, runs a joint decryption protocol to decrypt it, obtaining the final plaintext computation result. The computation key is obtained by encrypting the square of the shared private key using the shared public key. The shared private key is the sum of the private keys of all participants; that is, each participant's private key is a secret fragment of the shared private key.

[0004] Therefore, how to generate homomorphic computation keys without revealing the private keys of each participant has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a key generation method, apparatus, device, storage medium, and program product, which can generate homomorphic computation keys for multi-party secure computation systems without disclosing the private keys of each participant. The technical solution is as follows:

[0006] Firstly, a key generation method is provided, applied to a first participant in a multi-party secure computation system, wherein the multi-party secure computation system further includes multiple second participants, the method comprising:

[0007] The system receives first ciphertext sent by the plurality of second participants, wherein the first ciphertext is obtained by performing a homomorphic multiplication operation on the private key of each second participant and a first private key ciphertext, and the first private key ciphertext is obtained by encrypting the private key of the first participant; based on the first ciphertext sent by the plurality of second participants and the private key of the first participant, a first key fragment is generated; the first key fragment is encrypted using a joint public key to obtain a first fragment ciphertext, wherein the joint public key is determined based on the public key of the first participant and the public keys of the plurality of second participants; and receives second fragment ciphertexts sent by the plurality of second participants. The second ciphertext is obtained by the second participant encrypting the second key fragment using the joint public key. The second key fragment is generated by the second participant based on multiple second ciphertexts and the second participant's private key. The multiple second ciphertexts are obtained by performing homomorphic multiplication operations between the private keys of other participants (excluding the second participant) and the second private key ciphertexts. The second private key ciphertext is obtained by encrypting the second participant's private key. Homomorphic addition operations are performed on the second ciphertexts sent by the multiple second participants and the first ciphertext to obtain the homomorphic computation key of the multi-party secure computation system.

[0008] Therefore, it can be seen that by exchanging private key ciphertexts and performing homomorphic multiplication operations using their own private keys, multiple participants can generate a fragmented ciphertext. Each participant's fragmented ciphertext represents a share of the homomorphic computation key; that is, each participant can independently determine a fragment of the homomorphic computation key. By aggregating the fragmented ciphertexts of all participants through encryption, the homomorphic computation key of the multi-party secure computation system can be obtained. Thus, by utilizing public-key encryption, homomorphic encryption, and the method of generating the homomorphic computation key by aggregating the fragmented ciphertexts of each participant, this application ensures that each participant does not disclose their private key information during the process of jointly determining the homomorphic computation key, thereby guaranteeing the privacy and security of each participant's private key.

[0009] In one possible implementation, before receiving the second fragment ciphertext sent by the plurality of second participants respectively, the method further includes:

[0010] The system receives the second private key ciphertext sent by the plurality of second participants respectively; performs a homomorphic multiplication operation on the private key of the first participant and the second private key ciphertext sent by the plurality of second participants respectively to obtain the second ciphertext corresponding to the plurality of second participants respectively; and sends the corresponding second ciphertext to the plurality of second participants respectively.

[0011] In one possible implementation, sending the respective second ciphertext to each of the plurality of second participants includes:

[0012] For any one of the plurality of second participants, a first proof parameter is received from the second participant. The first proof parameter is used to characterize that the second private key ciphertext sent by the second participant is legally generated by the second participant and that the private key used to generate the second private key ciphertext is the private key of the second participant. Based on the first proof parameter sent by the second participant, the legality of the second private key ciphertext sent by the second participant is verified. If the legality verification is successful, the corresponding second ciphertext is sent to the second participant.

[0013] Therefore, during the exchange of private key ciphertext between the first participant and multiple second participants, all participants need to attach proof parameters to their own output private key ciphertext to prove the legitimacy of their output. In this way, by generating and verifying proof parameters, each participant can ensure that their share of the private key (relative to the federated private key) is genuine and secure. Furthermore, it effectively prevents fraud and tampering by multiple participants. If a participant attempts to deceive other participants or tamper with its share of the private key (relative to the federated private key), its generated proof parameters will fail verification, allowing other participants to detect and prevent such fraudulent activity in a timely manner.

[0014] In one possible implementation, generating a first key fragment based on the first ciphertext sent by the plurality of second participants and the private key of the first participant includes:

[0015] The sum of the first ciphertexts sent by the plurality of second participants is decrypted to obtain the first plaintext; the first key fragment is generated based on the square of the first plaintext and the private key of the first participant.

[0016] In other words, this application reduces the risk of direct leakage of the private key by generating key fragments instead of using the private key directly.

[0017] In one possible implementation, before generating the first key fragment based on the first ciphertext sent by the plurality of second participants and the private key of the first participant, the method further includes:

[0018] The first participant's private key is encrypted using the first participant's public key to obtain the first private key ciphertext, and then the first private key ciphertext is broadcast.

[0019] In one possible implementation, the method further includes:

[0020] Broadcast a second proof parameter, which is used to characterize that the first private key ciphertext was legally generated by the first participant and that the private key used to generate the first private key ciphertext is the private key of the first participant.

[0021] In other words, before the first participant and multiple second participants generate their own key fragments, they need to exchange their private key ciphertexts and ciphertexts with their own private keys attached.

[0022] In one possible implementation, the method further includes:

[0023] Obtain the initial private key of the first participant and determine the initial private key as the private key of the first participant; or, generate the private key of the first participant by exchanging fragments of their respective initial private keys with the plurality of second participants, wherein the fragments of the initial private key are obtained by splitting the corresponding initial private key based on a target number, the target number being the sum of the number of the first participant and the plurality of second participants.

[0024] In one possible implementation, generating the first participant's private key by exchanging fragments of their respective initial private keys with the plurality of second participants includes:

[0025] The system receives first private key fragments sent by the plurality of second participants, wherein the first private key fragments are fragments of the initial private keys of the second participants that are allocated to the first participant; and generates the private key of the first participant based on the first private key fragments sent by the plurality of second participants.

[0026] Therefore, when determining the homomorphic computation private key of multiple participants, this application can generate the private key of each participant by exchanging private key fragments. In this way, each participant's private key contains the share of other participants, avoiding the possibility of the participant's private key being stolen and leaked, improving the security of the participant's private key, and making it impossible for a single participant to deduce and calculate the private keys of each participant.

[0027] Secondly, another key generation method is provided, applied to a first participant in a multi-party secure computation system, wherein the multi-party secure computation system also includes multiple second participants, and the method includes:

[0028] The system receives first private key fragments sent by the plurality of second participating parties, where each fragment is a portion of the initial private key of a second participating party allocated to the first participating party. Based on the first private key fragments sent by the plurality of second participating parties, a private key of the first participating party is generated. The private key of the first participating party is encrypted to obtain a first private key ciphertext, which is then broadcast. The system receives second private key ciphertexts sent by the plurality of second participating parties, where each second private key ciphertext is obtained by encrypting the private key of a second participating party. Based on the first private key ciphertext, the second private key ciphertexts sent by the plurality of second participating parties, and a joint public key, a homomorphic computation key for the multi-party secure computation system is generated, where the joint public key is determined based on the public key of the first participating party and the public keys of the plurality of second participating parties.

[0029] Therefore, this application demonstrates that when determining the homomorphic computation private key for multiple participants, it can first generate each participant's private key by exchanging private key fragments. In this way, each participant's private key contains the shares of other participants, avoiding the possibility of theft and leakage of participant private keys, thus improving the security of participant private keys and preventing a single participant from deriving and calculating the private keys of other participants. Furthermore, with the private keys secure, using encrypted private keys and exchanging ciphertexts to determine the homomorphic computation key of the multi-party secure computation system will not leak the private keys of each participant, further enhancing the security of determining the homomorphic computation key.

[0030] In one possible implementation, before generating the private key of the first participant based on the first private key fragments sent by the plurality of second participants respectively, the method further includes:

[0031] The system receives fragmentation proof parameters sent by the plurality of second participants, wherein the fragmentation proof parameters are used to characterize that the first private key fragment is legally obtained by the second participant, and the sum of the first private key fragment and other private key fragments is the same as the initial private key of the second participant, and the other private key fragments are fragments of the initial private key of the second participant allocated to other participants besides the first participant; based on the fragmentation proof parameters sent by the plurality of second participants, the system verifies the legality of the first private key fragments sent by each of the plurality of second participants; if the legality verification of the plurality of second participants is passed, the system executes the step of generating the private key of the first participant based on the first private key fragments sent by the plurality of second participants.

[0032] Therefore, during the exchange of private key fragments, each participant needs to attach a fragment proof parameter to their output private key fragment to prove the legitimacy of their output. In this way, each participant can ensure that the private key fragments (relative to the complete initial private key) distributed to other participants are authentic and secure. Furthermore, it effectively prevents fraud and tampering by multiple participants. If a participant attempts to deceive other participants or tamper with a private key fragment, its generated proof parameter will fail verification, allowing other participants to detect and prevent such fraudulent behavior in a timely manner.

[0033] In one possible implementation, the first private key fragment is sent to the first participant via a secret sharing method of (t, n), where t and n are positive integers and 1 ≤ t ≤ n; where n is the sum of the number of the first participant and the plurality of second participants, and (t, n) indicates that the initial private key of the second participant can be recovered if more than t participants provide the corresponding private key fragments.

[0034] Since other participants only possess a fragment of the second participant's private key, a single participant cannot decipher the second participant's private key, thus enhancing the security of the second participant's private key.

[0035] In one possible implementation, before generating the homomorphic computation key for the multi-party secure computation system based on the first private key ciphertext, the second private key ciphertexts sent by the plurality of second participants respectively, and the joint public key, the method further includes:

[0036] Obtain a joint parameter, which is jointly determined based on a random number generated by the first participant to generate its own public key and random numbers generated by the plurality of second participants to generate their own public keys respectively; generate the public key of the first participant based on the joint parameter and the private key of the first participant, and broadcast the public key of the first participant; receive the public keys of the plurality of second participants respectively; generate the joint public key based on the public keys of the plurality of second participants and the public key of the first participant.

[0037] In other words, if each participant generates a private key by exchanging fragments of their initial private key, the public key of each participant can also be generated in the same way, thereby improving the security of the public key during multi-party interactions.

[0038] Thirdly, a key generation apparatus is provided, which has the function of implementing the key generation method described in the first aspect. The key generation apparatus includes at least one module for implementing the key generation method provided in the first aspect.

[0039] Fourthly, a key generation apparatus is provided, which has the function of implementing the key generation method described in the second aspect above. The key generation apparatus includes at least one module for implementing the key generation method provided in the second aspect above.

[0040] Fifthly, a computer device is provided, comprising a processor and a memory, the memory being used to store a computer program for executing the key generation method provided in the first aspect, or to store a computer program for executing the key generation method provided in the second aspect. The processor is configured to execute the computer program stored in the memory to implement the key generation method described in the first aspect, or to implement the key generation method described in the second aspect.

[0041] Optionally, the computer device may further include a communication bus for establishing a connection between the processor and the memory.

[0042] In a sixth aspect, a computer-readable storage medium is provided, wherein the storage medium stores instructions that, when executed on a computer, cause the computer to perform the key generation method described in the first aspect, or to perform the key generation method described in the second aspect.

[0043] In a seventh aspect, a computer program product comprising instructions is provided, which, when executed on a computer, cause the computer to perform the key generation method described in the first aspect, or to perform the key generation method described in the second aspect.

[0044] Alternatively, a computer program is provided that, when run on a computer, causes the computer to execute the key generation method described in the first aspect above, or to execute the key generation method described in the second aspect above.

[0045] The technical effects achieved by the third to seventh aspects mentioned above are similar to those achieved by the corresponding technical means in the first or second aspects, and will not be repeated here. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of a homomorphic encryption scheme provided in an embodiment of this application;

[0047] Figure 2 This is a schematic diagram of a threshold multi-key homomorphic encryption scheme provided in an embodiment of this application;

[0048] Figure 3 This is a schematic diagram of the calculation process of a privacy multiplication protocol provided in an embodiment of this application;

[0049] Figure 4 This is a schematic diagram of a multi-party secure computation scenario provided in an embodiment of this application;

[0050] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0051] Figure 6 This is a flowchart illustrating a key generation method provided in an embodiment of this application;

[0052] Figure 7 This is a flowchart illustrating another key generation method provided in an embodiment of this application;

[0053] Figure 8 This is a schematic diagram of the structure of a key generation device provided in an embodiment of this application;

[0054] Figure 9 This is a schematic diagram of another key generation device provided in the embodiments of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0056] To facilitate understanding, before explaining the key generation method provided in this application, the terminology, application scenarios, and implementation environment involved in the embodiments of this application will be introduced first.

[0057] First, the terminology used in the embodiments of this application will be introduced.

[0058] 1. Fully homomorphic encryption (FHE)

[0059] Fully homomorphic encryption is an innovative encryption technique that allows arbitrary computations to be performed on encrypted data without decryption, yielding the same encrypted result as the plaintext computation. This ensures data privacy while enabling effective data analysis and processing. In other words, fully homomorphic encryption performs computations on plaintext by manipulating ciphertext, thus guaranteeing that ciphertext computations can be completed in an untrusted environment.

[0060] See Figure 1 A fully homomorphic encryption scheme typically includes four main algorithms: a key generation algorithm (KeyGen), an encryption algorithm (Enc), a decryption algorithm (Dec), and a homomorphic operation algorithm (Eval).

[0061] The key generation algorithm generates public and private keys, as well as the public key for homomorphic computation if necessary. The encryption algorithm uses the public key to encrypt plaintext *m* into ciphertext *Enc(m)*. The decryption algorithm uses the private key to decrypt the ciphertext *Enc(f(m))* back into plaintext *F(m)*. Furthermore, the homomorphic computation algorithm, as the core of the fully homomorphic encryption scheme, allows arbitrary functions to be executed directly on the ciphertext, yielding the same encrypted result as the plaintext computation.

[0062] Currently, fully homomorphic encryption has evolved through three generations. The first generation's main contribution was a breakthrough in theoretical concepts; the mainstream fully homomorphic encryption algorithms mainly refer to the second and third generations. Second-generation fully homomorphic encryption algorithms, such as bounded-noise fully homomorphic encryption (BFV), ring-learning-based fully homomorphic encryption (Brakerski-Gentry-Vaikuntanathan, BGV), and Cheon-Kim-Kim-Song (CKKS), support addition, scalar multiplication, multiplication, and batch processing, but are not adept at nonlinear function computations. Third-generation fully homomorphic algorithms, such as the fastfully homomorphic encryption library over the torus (TFHE), support complex nonlinear operations but do not support batch processing.

[0063] BFV achieves encryption by placing plaintext in the high-order bits of the ciphertext and removing noise in the low-order bits through integer division. This scheme supports operations such as addition, multiplication, and scalar multiplication, and has high computational efficiency. Therefore, the BFV scheme is suitable for scenarios that require performing a large number of linear operations on encrypted data, such as data analysis in cloud computing and training machine learning models.

[0064] The BGV solution introduces a novel noise control technique that significantly improves performance compared to the first-generation FHE algorithm, lowers the barrier to entry for engineers implementing FHE, and enhances security. The BGV solution also supports operations such as addition, multiplication, and scalar multiplication, and supports finite-level homomorphic operations, making it suitable for scenarios requiring finite-level homomorphic operations on encrypted data, such as financial data analysis and medical data sharing.

[0065] CKKS is a fully homomorphic encryption scheme capable of handling floating-point and complex numbers. It is constructed based on the BGV or BFV scheme and uses complex encoding techniques to encrypt floating-point numbers. The CKKS scheme also supports operations such as addition, multiplication, and scalar multiplication, and offers high precision and computational efficiency. It is suitable for scenarios requiring precise calculations on encrypted data, such as inference in machine learning models and scientific computing.

[0066] TFHE is a torus-based fully homomorphic encryption scheme that enables complex nonlinear operations on encrypted data without decryption. This scheme offers high security and computational efficiency, but its complexity limits its batch processing capabilities. TFHE is suitable for scenarios requiring complex nonlinear operations on encrypted data, such as training machine learning models and performing logical reasoning on encrypted data.

[0067] Therefore, based on different application scenarios, different fully homomorphic encryption schemes can be flexibly selected or set to process ciphertext.

[0068] 2. Homomorphic encryption schemes with single and multiple keys

[0069] In a two-party scenario consisting of a client and a server, only a single-key homomorphic encryption scheme is involved.

[0070] It's important to note that the client, as the data owner, wants to encrypt its data before transmitting it to the server for some kind of computation, while ensuring the data remains undisclosed during transmission and computation. Based on this, the client generates an encryption key and uses it to encrypt its data. The encrypted data is then sent to the server for homomorphic computation. The server, as the provider of computing resources, receives the encrypted data from the client and performs homomorphic computation without decryption. The server doesn't need to know the specific content of the encrypted data; it only needs to perform the specific computation according to the client's requirements. After the computation is complete, the server returns the result (still encrypted) to the client.

[0071] In a single-key homomorphic encryption scheme, the client encrypts data using its own key and sends the encrypted data to the server. The server performs a homomorphic computation on the encrypted data without decryption, obtains the encrypted computation result, and sends it back to the client. Upon receiving the encrypted computation result, the client decrypts it using its own key to obtain the final plaintext computation result. Therefore, a single-key homomorphic scheme can satisfy the basic requirements for secure two-party computation as described above.

[0072] Furthermore, single-key homomorphic schemes can also be applied to any of the following two-party secure computation scenarios:

[0073] (1) Secure outsourced computing in the cloud: Clients can outsource computationally intensive tasks to cloud servers while protecting data privacy. Through homomorphic encryption, cloud servers can complete tasks without decrypting the data.

[0074] (2) Encrypted Artificial Intelligence (AI) Model Inference: In the field of machine learning, the client can input encrypted data into the AI ​​model, and the server performs inference without decrypting the data and returns the encrypted inference result. The client decrypts the data to obtain the final inference result.

[0075] (3) Privacy-preserving password leakage detection: In the field of network security, clients can send encrypted passwords to servers for leakage detection. The server detects whether the password has been leaked without decrypting it and returns an encrypted detection result. The client decrypts the password to determine whether it is secure.

[0076] However, in multi-party secure computation scenarios involving multiple participants, single-key homomorphic schemes cannot meet the requirements for encrypting data from all participants. Therefore, threshold multi-key homomorphic encryption schemes are needed.

[0077] See Figure 2 The homomorphic encryption scheme with multiple keys mainly includes the following steps (1)-(4).

[0078] (1) Key generation and distribution: First, n participants (denoted as p1, p2, ..., Pn) each generate their own private key fragments (denoted as sk1, sk2, ..., skn) and public key fragments (denoted as pk1, pk2, ..., pkn). Then, the n participants run a distributed key generation (DKG) protocol to generate a joint public key (denoted as pk) and a joint private key (denoted as sk) for the n participants, as well as the homomorphic computation key (EVK, sometimes also written as evk) required for homomorphic computation.

[0079] The joint public key pk is made public so that all participants can use it to encrypt data / messages and other content that needs to be transmitted. The homomorphic computation key evk is sent to the server (denoted as Server) that jointly analyzes / processes the multi-party data so that Server can perform homomorphic computations on the ciphertext sent by each participant without decryption.

[0080] (2) Data encryption and transmission: Each participant uses the joint public key pk to encrypt its own message m to obtain homomorphically encrypted ciphertext, denoted as Enc(pk, m1), Enc(pk, m2), ..., Enc(pk, mn). These encrypted ciphertexts are sent to the Server.

[0081] (3) Homomorphic computation: After receiving the ciphertext, the server performs a homomorphic computation of a function f with the aid of the computation key evk. The result of the computation is still encrypted and is denoted as ciphertext (ctresult). The server then sends it back to all parties.

[0082] (4) Joint decryption and result sharing: After receiving the ciphertext of the result (ctresult), each party runs a joint decryption protocol (Dec) to decrypt it, obtains the operation result f(m1, m2, ..., mn), and shares it with all participants.

[0083] It should be noted that in the above process, the joint public key `pk` is used to encrypt the message, ensuring its security during transmission and allowing the server to perform homomorphic computation on the ciphertext without decryption. The joint private key `sk` is used to decrypt the ciphertext resulting from the homomorphic computation and is generated through a distributed key generation protocol, ensuring that no single participant can decrypt the message alone. The homomorphic computation key `evk` assists the server in performing homomorphic computation, containing the information needed for the computation, but is insufficient to decrypt the message.

[0084] In summary, the threshold multi-key homomorphic encryption scheme achieves secure computation and data sharing among multiple participants through the synergistic effect of a joint public key, a joint private key, and a homomorphic computation key.

[0085] 3. BGV Encryption Scheme

[0086] The BGV encryption scheme is a fully homomorphic integer encryption scheme that allows specific mathematical operations to be performed on encrypted data without prior decryption. This scheme protects data privacy while supporting computation on encrypted data, and has broad application prospects.

[0087] The BGV encryption scheme mainly includes the following steps (1)-(4).

[0088] (1) Determine the basic parameters: ciphertext modulus (denoted as q), plaintext modulus (denoted as p), and ring (denoted as Rq). Here, q is the modulus used in the encryption process to determine the range of values ​​for the ciphertext. In the BGV scheme, the ciphertext is an integer ring Rq = Zq / (X) modulo q. NThe value is taken from +1). P is the modulus in the plaintext space, used to recover the plaintext from the ciphertext during decryption. Typically, p is much smaller than q. Rq is the ring containing the ciphertext, defined as Rq = Zq / (X... N +1), where X N +1 is a polynomial used to construct a ring structure over a finite field.

[0089] (2) Key generation: The private key is generated from a ternary distribution (also known as a ternary distribution) {-1, 0, 1} / (X N +1), or a binomial distribution (also known as a binary distribution) {0, 1} / (X) N The public key is randomly selected from the private key s and a randomly selected a∈Rq. It is a polynomial used in the decryption process. The public key is calculated from the private key s and a randomly selected a∈Rq. Specifically, b = as + pe is calculated, where e is a noise polynomial taken from a Gaussian distribution with a standard deviation of σ. Finally, the public key (a, b) and the private key s are output.

[0090] (3) Encryption process Enc(m): The input is plaintext m and public key (a, b). The output ciphertext ct is as follows: First, randomly select r and e1, where r is a random vector used for encryption, and e1 is a noise polynomial from a Gaussian distribution with standard deviation σ, just like e. Then, calculate a' = ra mod q, and calculate b' = rb + pe1 + m = ras + rpe + pe1 + m mod q. The output ciphertext ct = (a', b') ∈ Rq 2 .

[0091] (4) Decryption process Dec(ct, s): The input is the ciphertext ct = (a', b') and the private key s. The process of decrypting to obtain the plaintext is as follows: First, calculate m' = b' – a's = m + rpe + pe1 mod Rq. Then, check if |rpe + pe1| < q / (2p) (decryption correctness requirement). If it is satisfied, continue to calculate m' mod p = m, and the plaintext message m can be obtained.

[0092] For the BGV scheme, its homomorphic computation key can be simply understood as the joint public key pk and the joint private key sk. 2 The ciphertext Enc(pk, sk) produced by encrypting (i.e., the square of the combined private key) 2 ).

[0093] 4. Distributed Key Generation Protocol

[0094] Distributed key generation (DKG), as a core component of threshold homomorphic encryption, plays a crucial role. It allows a set of n participants to jointly generate a homomorphic public-private key pair, where the joint public key pk is publicly available, while the joint private key sk is shared among the n participants as a secret share. This distributed key generation mechanism ensures the system's security and robustness, providing a solid foundation for subsequent homomorphic computation.

[0095] Therefore, a well-constructed DKG protocol is crucial to the overall scheme, as it relates to the performance of subsequent homomorphic computations and the decryption process.

[0096] 5. (t, n) Threshold secret sharing

[0097] The idea behind (t, n) threshold secret sharing is to divide the secret s into n parts and assign a sub-share to each participant. Only when t or more participants cooperate can the secret be recovered; fewer than t participants cannot obtain any useful information about the secret. Therefore, (t, n) threshold secret sharing has wide applications in key management, attribute encryption, and digital signatures.

[0098] 6. Threshold Homomorphic Encryption Scheme

[0099] Threshold cryptography is a branch of cryptography that allows a group of participants to collaboratively perform cryptographic operations, such as encryption, decryption, and signing, when certain conditions (e.g., a quantitative requirement) are met. These operations typically rely on a secret (e.g., a private key), which is divided into multiple parts (called shares, slices, or shards) and distributed to different participants. Only when a certain number of participants cooperate can the complete secret be reconstructed, allowing the corresponding cryptographic operation to be performed.

[0100] In threshold homomorphic encryption schemes, the meaning of "threshold" is similar to that in threshold cryptography. Specifically, it refers to the minimum number of participants (or threshold value) required to perform homomorphic encryption operations. Only when a number of participants, or more than this threshold, participate can encryption keys, homomorphic operations, and decryption operations be effectively generated.

[0101] This design makes threshold homomorphic encryption schemes more secure and flexible. On the one hand, it prevents a single or a small number of participants from gaining complete control over encrypted data, thus protecting data privacy and security. On the other hand, it also allows for the flexible addition or reduction of the number of participants as needed to adapt to different application scenarios and requirements.

[0102] In practical applications, the "threshold" value in threshold homomorphic encryption schemes is usually set based on specific security requirements and application scenarios. For example, in a multi-party computation scenario, if it is desired to ensure that only a certain number of participants (e.g., at least three) can decrypt a certain encrypted data packet, then the threshold value can be set to three. In this way, even if a participant withdraws or betrays the platform, as long as the number of remaining participants still meets the threshold requirement, the decryption operation can continue.

[0103] 7. Commitment

[0104] A commitment is a cryptographic technique that allows one party (the promisor) to prove the existence of a value to another party (the verifier) ​​without directly revealing that value. In threshold multi-key homomorphic encryption schemes, commitments can be used to ensure that participants guarantee the authenticity of their data.

[0105] (1) The commitment is implemented through the function H(·).

[0106] First, the committer chooses a random value *r*, which is typically a large integer or a random number. Then, the committer hashes the data and the random value *r* using a hash function H (such as a secure hash algorithm 256-bit (SHA-256)) to obtain the commitment value C = H(data||r), where "||" represents string concatenation. Finally, the committer publishes the commitment value C to the verifier, but keeps the random value *r* and the data *data* as secrets.

[0107] (2) The commitment is implemented by using the function Com(·).

[0108] In some cases, a special commitment function Com(·) may be used to implement a commitment. This function is usually based on complex cryptographic constructs, such as Pedersen commitments.

[0109] In this approach, the promiser and the verifier jointly select a basis vector g and a random vector h (these vectors are typically points on an elliptic curve). The promiser then computes the promise value Com(data, r) ​​= gr using the data data and the random value r. Finally, the promiser publishes the promise value gr to the verifier, but keeps the random value r and the data data as secrets.

[0110] It should be noted that, in this application embodiment, only the above two types of commitments are used as examples to illustrate the content of the commitments required in this application embodiment. It should be understood that, with the development of commitment techniques in cryptography, other commitments can also be used to achieve this, and this application embodiment does not limit this.

[0111] 8. Binary relations and consistency proofs

[0112] Binary relations and consistency proofs are important concepts in mathematical cryptography. They ensure that encrypted data maintains a specific relation during computation and that the decrypted result is consistent with the result of performing the same operation directly on the plaintext.

[0113] In mathematics, a binary relation refers to a relationship or correspondence between two elements. In homomorphic encryption schemes, a binary relation typically refers to a mathematical relationship between plaintext and its encrypted ciphertext, ensuring that the encryption operation does not change the essential connection between the data. A consistency proof is evidence that proves a statement or information is true or correct. In threshold multi-key homomorphic encryption schemes, consistency proofs are used to ensure that the secrets or data shared among the participants are consistent. That is, consistency proofs can be used to verify whether the key fragments shared among the participants are identical.

[0114] As an example, the implementation process of a consistency proof may include the following steps (1)-(3).

[0115] (1) Selecting a binary relation: Determine the binary relation to be verified. For example, for a proof of consistency of key fragments, the binary relation could be "the key fragment of participant Pi is equal to the key fragment of participant Pj".

[0116] (2) Proof generation: Participant Pi generates a proof parameter using his own key fragment and a random value. This proof parameter proves that his key fragment satisfies the aforementioned binary relation with participant Pj's key fragment. This proof parameter typically involves complex cryptographic operations, such as zero-knowledge proofs.

[0117] (3) Verification of the Proof: Participant Pj or other verifiers use the received proof and their own key fragment to verify the validity of the proof. If the proof is valid, it indicates that participant Pi's key fragment is consistent with participant Pj's key fragment.

[0118] 9. Privacy Multiplication Agreement

[0119] The privacy multiplication protocol is a specially designed and verified protocol in this application embodiment for the process of generating the homomorphic computation key evk. Its purpose is to calculate the sum of the secret fragments of each participant while ensuring the privacy of the input of each participant.

[0120] See Figure 3The privacy multiplication protocol aims to compute the additive slices of z = xy, i.e., to compute z1, z2, and z3, satisfying z = z1 + z2 + z3 = xy, while ensuring the privacy of inputs from all participants. This protocol is applicable to multiple participants (using 3 participants Node1, Node2, and Node3 as an example), each holding an additive slice of x and y. Here, Enc(·) represents an encryption scheme with additive homomorphic properties.

[0121] Taking Node1 as an example, the calculation process includes the following steps (1)-(6).

[0122] (1) Encryption and Broadcasting: Node1 uses its own public key 1 to encrypt its own secret fragment x1, obtains Enc1(x1), and broadcasts it to the other participants (Node2 and Node3).

[0123] (2) Receiving ciphertext: Node1 simultaneously receives ciphertext Enc2(x2) from Node2 and ciphertext Enc3(x3) from Node3.

[0124] (3) Homomorphic operation and transmission: Node1 performs a homomorphic operation to calculate the ciphertext E. 12 =y1*Enc2(x2)+δ 12 (where δ) 12 This is a random number added by Node1 for verification; its corresponding plaintext message is y1*x2+δ. 12 ), and E 12 Send it to Node2. Similarly, Node1 computes the ciphertext E. 13 =y1*Enc3(x3)+δ 13 (where δ) 13 It is another random number), and E 13 Send to Node3.

[0125] (4) Receive and process ciphertext: Node1 receives ciphertext E from Node2. 21 (The result of the homomorphic operation corresponding to Node2 includes the encryption of y2*x1 and another random number δ) 21 ) and the ciphertext E from Node3 31 (The result of the homomorphic operation corresponding to Node3 includes the encryption of y3*x1 and another random number δ) 31 Furthermore, Node1 processes the received ciphertext E. 21 and E 31 After adding and decrypting, the plaintext message obtained is y2x1+y3x1+δ. 21 +δ 31 .

[0126] (5) Calculate z1: Node1 receives the plaintext message y2x1+y3x1+δ 21 +δ 31 Based on this, add x1y1 (i.e., the product of the x and y fragments held by Node1 itself), and subtract the random number δ that it added. 12 and δ 13 The result is calculated as z1 = y1x1 + y2x1 + y3x1 + δ 21 +δ 31 -δ 12 -δ 13 .

[0127] (6) Verification and Summation: Verification shows that when all participants calculate and publish their z-shards according to the above steps, z1 + z2 + z3 = z = xy. This is because the random number part will cancel out in the sum of the three parties, satisfying the condition that the sum is 0.

[0128] Secondly, the application scenarios of the embodiments of this application will be introduced.

[0129] The key generation scheme provided in this application is applicable to various scenarios involving multi-party data encryption computation, such as joint anti-fraud analysis involving customer privacy data from multiple banks in financial scenarios, and joint security analysis involving patient privacy data from multiple hospitals in medical scenarios.

[0130] See Figure 4 In a multi-party secure computation system, multiple parties need to encrypt and send data to the server. The server performs homomorphic operations on the data provided by the multiple parties without decryption and sends the ciphertext computation results back to the multiple parties. The multiple parties then jointly decrypt the data to obtain the final plaintext computation result.

[0131] In this process, to ensure that the data of each participant is not accessed by other participants, each participant needs to jointly generate a joint public key (pk) to encrypt the data to be sent to the server, and simultaneously jointly generate a joint private key (sk) to decrypt the ciphertext calculation result returned by the server. Since the joint private key (sk) is jointly generated by multiple participants, and each participant only holds a fragment of that joint private key (sk), only through the collaboration of multiple participants can the ciphertext calculation result be decrypted; a single participant cannot accurately decrypt the ciphertext calculation result.

[0132] It should be noted that, Figure 4The example of three participants does not constitute a limitation on the application system of this application embodiment. In actual applications, the multi-party secure computing system may include more or fewer participants, and the server in the multi-party secure computing system may be a single server, a cluster of multiple servers, a cloud server, or a data center, etc. This application embodiment does not impose any limitations on this.

[0133] To facilitate understanding of the specific application of the key generation method provided in the embodiments of this application in a multi-party secure computing system, the following example illustrates the threshold multi-key homomorphic encryption scheme using a multi-party data fusion and privacy protection scenario in cross-border e-commerce trade.

[0134] In cross-border e-commerce, multiple parties involved, including e-commerce platforms, banks, customs, and logistics companies, need to share data to complete transactions. However, due to privacy concerns and the need to protect trade secrets, none of them wish to directly expose their raw data. In this situation, a threshold multi-key homomorphic encryption scheme can be used to achieve secure data fusion and computation.

[0135] As explained earlier, threshold multi-key homomorphic encryption, as an advanced encryption technology, combines the characteristics of homomorphic encryption and multi-key encryption, and introduces the concept of threshold secret sharing. This scheme allows multiple participants to encrypt data using their respective keys and perform homomorphic computations on the data without decryption. Simultaneously, through the threshold secret sharing mechanism, the original data can only be decrypted and obtained when a sufficient number of participants cooperate, thus ensuring data security.

[0136] Suppose there are four participants in cross-border e-commerce trade: A (e-commerce platform), B (bank), C (customs), and D (logistics company). They want to jointly calculate the total amount and average transaction time of a certain transaction without exposing their own raw data, which may include the following steps (1)-(5).

[0137] (1) Key generation: Each participant A, B, C, and D generates its own public-private key pair and publishes the public key to all participants.

[0138] (2) Data encryption: Each participant uses its own private key to encrypt the data to be shared and sends the encrypted data to other participants. For example, A uses its own private key to encrypt the transaction amount, B uses its own private key to encrypt the transaction time, and so on.

[0139] (3) Data aggregation: All participants aggregate the received encrypted data to obtain the encrypted total amount and average transaction time. Due to the use of homomorphic encryption technology, this encrypted data can be directly used for mathematical operations without decryption first.

[0140] (4) Homomorphic computation: Homomorphic computation is performed on the aggregated data under encrypted conditions to obtain encrypted computation results. These computation results remain encrypted but can be directly used for subsequent analysis and decision-making.

[0141] (5) Decryption and Result Sharing: When it is necessary to decrypt the computation result, a sufficient number of participants (e.g., reaching a preset threshold) need to cooperate and provide their private keys. Through the threshold secret sharing mechanism, the original computation result can be decrypted and shared with all participants.

[0142] In this example, the threshold multi-key homomorphic encryption scheme not only ensures data privacy and security but also enables data fusion and efficient computation among multiple participants. This scheme has broad application prospects in scenarios such as cross-border e-commerce, financial risk control, and medical data sharing.

[0143] For the aforementioned multi-party secure computation system and BGV scheme, assuming each participant shares a common random value 'a', each participant Pi can choose their own private key 'si', and can independently compute their public key parameter bi = asi + pei. Due to its linear relationship, the joint public key pk corresponds to b = sum bi = a*(sum si) + p(sum ei), and the corresponding joint private key sk = sum si.

[0144] Therefore, the generation of the joint public key pk and joint private key sk is logically simple. The difficulty lies in how to generate the homomorphic computation key evk, that is, how to generate the joint private key sk under the joint public key pk. 2 The ciphertext (at this point, each participant holds an additive fragment of the joint public key pk and the joint private key sk) is the key to constructing the DKG phase of the threshold multi-key scheme.

[0145] Based on this, the embodiments of this application provide a key generation method that can generate a homomorphic computation key evk = Enc(pk, sk) for multiple participants without disclosing the private keys of each participant. 2 This allows the server to perform joint analysis and computation on the data of multiple participants without decryption, based on the homomorphic computation key.

[0146] Finally, the implementation environment of the embodiments of this application will be described.

[0147] Figure 5This is a schematic diagram of the structure of a computer device according to an embodiment of this application. The computer device may be... Figure 4 The user equipment of any of the participating parties shown can be, for example, a terminal or a server. Figure 5 As shown, the computer device includes at least one processor 501, a communication bus 502, a memory 503, and at least one communication interface 504.

[0148] Processor 501 can be a general-purpose central processing unit (CPU), a network processor (NP), a microprocessor, or one or more integrated circuits for implementing the solutions of this application, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0149] The communication bus 502 is used to transmit information between the aforementioned components. The communication bus 502 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0150] The memory 503 may be a read-only memory (ROM), a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), an optical disc (including a compact disc read-only memory (CD-ROM), a compressed optical disc, a laser disc, a digital versatile optical disc, a Blu-ray disc, etc.), a magnetic disk storage medium, or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but not limited thereto. The memory 503 may exist independently and be connected to the processor 501 via a communication bus 502. The memory 503 may also be integrated with the processor 501.

[0151] Communication interface 504 uses any transceiver-like device for communicating with other devices or communication networks. Communication interface 504 includes a wired communication interface and may also include a wireless communication interface. The wired communication interface may be, for example, an Ethernet interface. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0152] As an example, processor 501 may include one or more CPUs, such as Figure 5 CPU0 and CPU1 are shown in the diagram.

[0153] As an example, a computer device may include multiple processors, such as Figure 5 The processors 501 and 505 are shown in the diagram. Each of these processors may be a single-core processor or a multi-core processor. A processor here may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0154] In some embodiments, the computer device may further include output devices and input devices. The output device communicates with the processor 501 and can display information in various ways. For example, the output device may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device communicates with the processor 501 and can receive user input in various ways. For example, the input device may be a mouse, keyboard, touchscreen device, or sensing device.

[0155] In some embodiments, memory 503 is used to store program code 510 for executing the scheme of this application, and processor 501 can execute the program code 510 stored in memory 503. The program code 510 may include one or more software modules, and the computer device can implement the following by using processor 501 and the program code 510 in memory 503. Figure 6 or Figure 7 The key generation method provided in the embodiment.

[0156] It should be understood that the application scenarios and hardware architectures described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the emergence of new application scenarios or the evolution of implementation architecture, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0157] Next, the key generation method provided in the embodiments of this application will be explained in detail.

[0158] Figure 6 This is a flowchart of a key generation method provided in an embodiment of this application. The method is applied to the user equipment of the first participant in a multi-party secure computation system. This user equipment can be the aforementioned... Figure 5 The computer equipment shown. The multi-party secure computation system also includes multiple second parties. Please refer to... Figure 6 The method includes the following steps.

[0159] Step 601: Receive the first ciphertext sent by multiple second participants respectively. The first ciphertext is obtained by performing a homomorphic multiplication operation on the private key of the second participant and the first private key ciphertext. The first private key ciphertext is obtained by encrypting the private key of the first participant.

[0160] It should be understood that since the first ciphertext is generated based on the second participant's private key and the first private key ciphertext, before performing step 601 above, the first participant and the second participant need to exchange their respective private key ciphertexts, then generate ciphertexts based on each other's private key ciphertexts and their own private keys, and exchange their generated ciphertexts.

[0161] In this embodiment, the ciphertext of the private key generated by the first participant using its own private key is denoted as the first private key ciphertext; the ciphertext of the private key generated by the first participant using its own private key is denoted as the second private key ciphertext. The ciphertext obtained by the second participant performing a homomorphic multiplication operation on its own private key and the first private key ciphertext is denoted as the first ciphertext; the ciphertext obtained by the first participant performing a homomorphic multiplication operation on its own private key and the second private key ciphertext is denoted as the second ciphertext.

[0162] Next, taking the interaction object of the first participant as an example of a second participant, we will explain the process of exchanging private key ciphertext between the first and second participants, as well as the implementation process of exchanging ciphertext.

[0163] First, the process of exchanging private key ciphertext between the first and second participants will be introduced.

[0164] In some embodiments, the first participant uses its own public key to encrypt its own private key to obtain a first private key ciphertext, and then broadcasts the first private key ciphertext.

[0165] As an example, suppose there is a first participant (denoted as Pi) and a second participant (denoted as pj), and the first and second participants use an encryption scheme {XEnc(·), XDec(·)} with additive homomorphic properties, and the public key of the first participant's XEnc(·) is pk. i The corresponding private key is sk i The first private key ciphertext can then be represented by the following formula (1).

[0166] C si =XEnc i (pk i ,sk i (1)

[0167] Among them, C si The first private key ciphertext, PK i sk is the public key of the first participant. i This is the private key of the first participant.

[0168] Similarly, the second participant uses its own public key to encrypt its private key, obtaining a second private key ciphertext, and sends the second private key ciphertext to the first participant. The second private key ciphertext can be represented by the following formula (2).

[0169] C sj =XEnc i (pk j ,sk j (2)

[0170] Among them, C sj For the second private key ciphertext, pk j sk is the public key of the second participant. j This is the private key of the second participant.

[0171] It should be understood that the second private key ciphertext can be sent point-to-point, directly from the second participant to the first participant, or it can be sent to the first participant via broadcast. This application embodiment does not limit this, but aims to emphasize that the first participant can receive the second private key ciphertext sent by the second participant.

[0172] Furthermore, since the private key ciphertext exchanged between the first and second participants will be used to generate the joint private key and homomorphic computation key in subsequent processes, it is essential to ensure the security and accuracy of the private key ciphertext. This is to prevent malicious participants from providing illegitimate private key ciphertext to interfere with the collaborative generation of the homomorphic computation key. Therefore, during the exchange of private key ciphertext between the first and second participants, both parties need to attach a consistency proof to their output private key ciphertext to guarantee its legitimacy to the other party.

[0173] Taking the second participant as an example, in one possible implementation, the second participant broadcasts a first proof parameter while sending the second private key ciphertext to the first participant. The first proof parameter is used to characterize that the second private key ciphertext sent by the second participant was legally generated by the second participant, and that the private key used to generate the second private key ciphertext is the private key of the second participant.

[0174] After receiving the first proof parameter broadcast by the second participant, the first participant first verifies the validity of the second private key ciphertext sent by the second participant based on the first proof parameter. If the validity verification passes, the first participant generates a second ciphertext based on the second private key ciphertext and its own private key, and sends the second ciphertext to the second participant. If the validity verification fails, the first participant outputs the identification information of the second participant and terminates the homomorphic computation process.

[0175] The identification information of the second participant may include the second participant's number, identity, device type, etc. in the multi-party secure computing system, and this application embodiment does not limit this.

[0176] It should be noted that the methods for generating proof parameters and verifying proof parameters can refer to relevant technologies. This application does not limit these methods and will not elaborate further here.

[0177] Similarly, while broadcasting the first private key ciphertext, the first participant will also broadcast the second proof parameter. The second proof parameter is used to indicate that the first private key ciphertext was legally generated by the first participant and that the private key used to generate the first private key ciphertext is the first participant's private key.

[0178] Based on the second proof parameter broadcast by the first participant, multiple second participants can also verify the legitimacy of the first private key ciphertext broadcast by the first participant based on the second proof parameter.

[0179] Therefore, during the exchange of private key ciphertext among multiple participants, each participant needs to attach a proof parameter to their output private key ciphertext to prove the legitimacy of their output. In this way, by generating and verifying proof parameters, each participant can ensure that their share of the private key (relative to the joint private key) is genuine and secure. Furthermore, it effectively prevents fraud and tampering by multiple participants. If a participant attempts to deceive other participants or tamper with their private key share, their generated proof parameter will fail verification, allowing other participants to detect and prevent such fraudulent activity in a timely manner.

[0180] Secondly, the process of exchanging ciphertext between the first and second participants will be introduced.

[0181] In one possible implementation, after receiving the second private key ciphertext sent by the second participant, the first participant performs a homomorphic multiplication operation between the first participant's private key and the second private key ciphertext to obtain the second ciphertext corresponding to the second participant, and then sends the second ciphertext to the second participant.

[0182] As an example, for the second participant, the second ciphertext generated by the first participant can be represented by the following formula (3).

[0183] E ij =sk i ·C sj (3)

[0184] Among them, E ij The second ciphertext, sk i C is the private key of the first participant. sj This is the ciphertext for the second private key.

[0185] Similarly, for the first participant, the first ciphertext generated by the second participant can be represented by the following formula (4).

[0186] Eji =sk j ·C si (4)

[0187] Among them, E ji The second ciphertext, sk j C is the private key of the second participant. si This is the first private key ciphertext.

[0188] In some embodiments, since both the first ciphertext and the second ciphertext carry the private key of the participants, a random number δ can be introduced to ensure the security of the encryption process. This random number δ is linearly combined with the plaintext (or some representation thereof) during the encryption process to generate the ciphertext, making it difficult for attackers to deduce the plaintext (i.e., the private key of the participants) from the ciphertext.

[0189] Based on this, a corresponding random number can be added to both the second ciphertext and the first ciphertext. The random number is chosen by the party generating the ciphertext (e.g., the first party), and the random number chosen by each second party is different. In this case, formulas (3) and (4) can also be expressed by formulas (5) and (6).

[0190] E ij =sk i ·C sj +δ ij (5)

[0191] E ji =sk j ·C si +δ ji (6)

[0192] Where, δ ij δ is the random number chosen by the first participant for the second participant. ji This is a random number chosen by the second participant for the first participant. The meanings of other parameters are given in formulas (3) and (4) above.

[0193] In one possible implementation, the first participant, while sending the second ciphertext to the second participant, may also send proof parameters regarding the second ciphertext to the second participant, so that the second participant can verify the legitimacy of the second ciphertext sent by the first participant at this stage. Similarly, the second participant, while sending the first ciphertext to the first participant, may also send proof parameters regarding the first ciphertext to the first participant, so that the first participant can verify the legitimacy of the first ciphertext sent by the second participant at this stage.

[0194] Step 602: Generate a first key fragment based on the first ciphertext sent by multiple second participants and the private key of the first participant.

[0195] In one possible implementation, step 602 can be implemented as follows: decrypting the sum of the first ciphertexts sent by multiple second participants to obtain the first plaintext; generating a first key fragment based on the square of the first plaintext and the private key of the first participant.

[0196] As an example, the first key fragment can be represented by the following formula (7) or (8).

[0197] z i =XDec(sk i , ∑ j E ji )+sk i ·sk i (7 )

[0198] z i =XDec(sk i , ∑ j E ji )+sk i ·sk i -∑ j δ ij (8 )

[0199] Among them, z i For the first key fragment, sk i Let be the private key of the first participant, j∈n, where n is the total number of participants in the multi-party secure computation scenario, i.e., the sum of the number of representations of the first participant and multiple second participants. When there are multiple second participants, the computation of the first key fragment requires the first ciphertext E of all second participants. ji Add and decrypt.

[0200] It should be understood that formula (7) corresponds to formulas (3) and (4) above, and represents the case where random numbers are not considered; formula (8) corresponds to formulas (5) and (6) above, and in the case of introducing random numbers, the first participant needs to subtract the random number δ used by itself for all second participants when generating the first key fragment. ij sum.

[0201] Therefore, this application's embodiments take into account that the private key is a critical element in the encryption and decryption process, and its leakage will expose the encrypted data to security risks. By generating key fragments instead of directly using the private key, the risk of direct private key leakage can be reduced.

[0202] Similarly, for multiple second participants, each second participant will also generate a second key fragment. The way the second participant generates the second key fragment is similar to the implementation logic of the first participant generating the key fragment, and can be referred to the above implementation process, which will not be repeated here.

[0203] As an example, the second key fragment generated by the second participant can be denoted as z. j It contains its own private key sk j The square of.

[0204] In some embodiments, the first participant needs to determine its private key before performing step 602 above. This application provides two methods for determining the private key of a participant, which can be either the first participant or the second participant. Next, taking the first participant as an example, the two implementation methods for determining the first participant's private key will be described respectively.

[0205] In the first implementation, the first participant obtains its own initial private key and uses this initial private key as the private key for generating the homomorphic computation key using the DKG protocol. In this case, the first participant's private key is the same as its initial private key.

[0206] As an example, if the initial private key of the first participant is si, then when executing the key determination method provided in this application embodiment, the initial private key si is directly determined as the private key of the first participant, that is, the private key sk of the first participant. i =si.

[0207] In the second implementation, the first participant generates its own private key by exchanging fragments of their respective initial private keys with multiple second participants. This private key is used to execute the DKG protocol to generate a homomorphic computation key. In this case, the first participant's private key is not equal to the initial private key.

[0208] In one possible implementation, the process of generating the private key of the first participant by exchanging fragments of their respective initial private keys with multiple second participants may include the following steps (1)-(2).

[0209] (1) Receive the first private key fragments sent by multiple second participants respectively. The first private key fragments are the fragments that are divided from the initial private key of the second participants and given to the first participants.

[0210] In one possible implementation, the first private key fragment is sent to the first participant via a secret sharing method of (t, n), where t and n are positive integers and 1 ≤ t ≤ n. Here, n is the sum of the number of the first participant and multiple second participants, and (t, n) indicates that the initial private key of the second participant can be recovered if more than t participants provide their corresponding private key fragments.

[0211] As an example, taking a single second participant as an example, when it performs a (t, n) secret sharing on its own initial private key sj, it splits its own private key sj into {sj1, sj2, ..., sj...} n The process involves sending sj2 to the first participant. At this point, the first participant receives sj2 as the first private key fragment. sj1 is the private key fragment retained by the second participant.

[0212] Similarly, when the first participant also performs a secret sharing of its initial private key si (t, n), it divides its private key si into {si1, si2, ..., si...} n The process involves sending si2 to a second participant. At this point, the second participant receives si2, which is the private key fragment originating from the first participant. Here, si1 is the private key fragment retained by the first participant.

[0213] In one possible implementation, the second participant sends a fragment of the first private key to the first participant along with a fragmentation proof parameter. This fragmentation proof parameter indicates that the first private key fragment was legally obtained by the second participant, and that the sum of the first private key fragment and the other private key fragments is the same as the second participant's initial private key. The other private key fragments are fragments allocated from the second participant's initial private key to participants other than the first participant.

[0214] Based on this, the first participant receives fragmented proof parameters sent by multiple second participants respectively; based on the fragmented proof parameters sent by multiple second participants respectively, the legality of the first private key fragment sent by each of the multiple second participants is verified; if the legality verification of multiple second participants is passed, the following step (2) is executed.

[0215] In some embodiments, the first participant can choose a random number ρ for the private key si. si And based on the random number ρ si Generate a commitment about your own private key siCom si (ρ si ,si), and broadcast the commitment value Com si (ρ si ,si).

[0216] In other words, when the first participant sends the private key fragment si2 to a second participant, it can also make a commitment to that private key fragment si2 and send the commitment value Com. si (ρ si2 ,si2) is given to the second participant. Where, ρ si2 ρ is the random number chosen by the first participant for the private key fragment si2. si2 It can be selected in real time, or the first participant can select the above random number ρ. si The fragments allocated to the second participant after segmentation are not limited in this embodiment.

[0217] Furthermore, the first participant sends the commitment value Com. si (ρ si2 After si2), the random number ρ will be generated. si2 Send it to the second participant so that the second participant can verify the validity of the commitment value based on the random number.

[0218] In one possible implementation, the second participant receives the private key fragment si2 and the commitment value Com. si (ρ si2 ,si2) and random number ρ si2 Then, based on these parameters, the legitimacy of the private key fragment sent by the first participant will be verified to determine the legitimate identity of the first participant. If the legitimacy verification passes, the following step (2) will be executed. If the verification fails, the key generation process will end and the identifier of the first participant will be output.

[0219] (2) Generate the private key of the first participant based on the first private key fragments sent by multiple second participants respectively.

[0220] In one possible implementation, the first participant can generate its private key based on the first private key fragments sent by multiple second participants using the following formula (9).

[0221] si′=∑ j∈[n] sj i (9)

[0222] Where si′ is the private key of the first participant, and sj i Let si′ be the private key fragment sent by the second participant Pj to the first participant, where j∈n and n is the sum of the number of the first participant and multiple second participants. That is, aggregate all private key fragments j≠i, and use the aggregation result si′ as the private key ski of the first participant.

[0223] In this case, the private key of the first participant in the output is ski = si′.

[0224] In some embodiments, if multiple participants also exchange random numbers for their private keys, the first participant also needs to generate a random number for the private key based on the random numbers sent by multiple second participants using the following formula (10).

[0225] ρ′ si =∑ j∈[n] ρ sji (10)

[0226] Where, ρ′ si ρ is the private key of the first participant. sji Let ρ' be a random number sent by the second participant to the first participant, where j∈n, and n is the sum of the number of participants from the first participant and multiple second participants. That is, aggregate all random numbers j≠i, and the aggregated result ρ' is... si The private key of the first participant is used to generate a random number.

[0227] In this case, the first participant's private key ski = (si′, ρ′) si ).

[0228] In summary, when determining the homomorphic computation private key of multiple participants, the embodiments of this application can generate the private key of each participant by exchanging private key fragments. In this way, each participant's private key contains the share of other participants, avoiding the possibility of the participant's private key being stolen and leaked, improving the security of the participant's private key, and making it impossible for a single participant to deduce and calculate the private keys of each participant.

[0229] Furthermore, during the exchange of private key fragments, each participant needs to attach a fragment proof parameter to their output private key fragment to prove the legitimacy of their output. In this way, each participant can ensure that the private key fragments (relative to the complete initial private key) distributed to other participants are authentic and secure. It also effectively prevents fraud and tampering by multiple participants. If a participant attempts to deceive other participants or tamper with a private key fragment, its generated proof parameter will fail verification, allowing other participants to detect and prevent such fraudulent activity in a timely manner.

[0230] In some embodiments, taking the BGV scheme as an example, for the first participant, the public key pki is determined based on the private key ski and related parameters a, p, and e (the meanings of which can be found in the terminology explanation above). Therefore, when determining the private key ski includes the two implementation methods described above, determining the joint public key pk also includes two implementation methods. The implementation process for determining the joint public key pk will be explained below.

[0231] In the first implementation, the first participant selects a random number *ai* from the ring *Rq*, calculates a commitment value *hai* = H(ai) using a hash function, and broadcasts this commitment value *hai*. Simultaneously, the first participant also receives multiple commitment values ​​*haj* (j ≠ i, and j ∈ n, where n is the total number of participants) broadcast by the second participants. After receiving all commitment values ​​*haj*, the first participant broadcasts *ai* as a common parameter. At the same time, the first participant also receives *aj* (j ≠ i) sent by other participants. Then, the first participant verifies the validity of *aj* using the commitment value *haj*. If *haj* = H(aj), the first participant calculates the joint common parameter *a* = ∑*aj*. If *haj* ≠ H(aj), the first participant terminates the calculation and outputs the identifier of *j* to inform all participants that the second participant *pj* is a malicious participant.

[0232] Further, the first participant selects a private key si and noise ei, and sets bi = asi + pei. Then, the first participant calculates the commitment value hbi = H(bi) and broadcasts it. Simultaneously, the first participant also receives hbj from the second participant (j ≠ i). After receiving all commitment values ​​hbj, the first participant broadcasts bi as a common parameter. At the same time, the first participant also receives bj (j ≠ i) from the second participant (j ≠ i). Then, the first participant verifies the validity of bj using the commitment value hbj. If hbj = H(bj), then the first participant calculates the joint common parameter b = ∑bj. If hbj ≠ H(bj), the first participant terminates the calculation and outputs the identifier of j to inform all participants that the second participant pj is a malicious participant.

[0233] Finally, based on the joint common parameters a = ∑aj and b = ∑bj mentioned above, the joint public key pk = (a, b) is determined.

[0234] In the second implementation, since bi = asi + pei and the joint common parameter b = ∑bj, after determining the private key si of each participant, b = a∑si + p∑ei can be directly calculated.

[0235] It should be noted that when multiple participants exchange shares of noise ei, this can also be achieved through secret sharing of (t, n), while attaching a commitment value to the output noise slice so that the participant receiving the noise slice can verify its legitimacy. The specific implementation process can be found in the previous explanations and will not be repeated here.

[0236] Step 603: Encrypt the first key fragment using the joint public key to obtain the first fragment ciphertext. The joint public key is determined based on the public key of the first participant and the public keys of multiple second participants.

[0237] As an example, the first fragment ciphertext generated by the first participant can be represented by the following formula (11).

[0238] α i =Enc(pk, z) i (11)

[0239] Where, α i The first ciphertext fragment is 'pk', which is the joint public key, and 'z' is the ciphertext. i The first key is fragmented. The encryption scheme {Enc(·), Dec(·)} is the encryption scheme used between the participants in the secure computing system and the server performing homomorphic computation, to distinguish it from the encryption scheme used between the first participant and multiple second participants; of course, the encryption schemes used in these two stages can also be the same, and this application embodiment does not limit this.

[0240] In some embodiments, after generating the first fragment ciphertext, the first participant also needs to broadcast the first fragment ciphertext so that the first participant and multiple second participants can jointly perform the subsequent step 605 to generate the homomorphic computation key.

[0241] Similarly, while broadcasting the first ciphertext fragment, the first participant can also broadcast the proof parameters to proactively ensure the security of this interaction.

[0242] Step 604: Receive the second fragment ciphertext sent by multiple second participants. The second fragment ciphertext is obtained by the second participants encrypting the second key fragment using the joint public key. The second key fragment is generated by the second participants based on multiple second ciphertexts and the private key of the second participants. The multiple second ciphertexts are obtained by performing homomorphic multiplication operations between the private key of the other participants and the second private key ciphertext. The second private key ciphertext is obtained by encrypting the private key of the second participants.

[0243] It should be noted that for multiple second participants, each second participant will also generate a second fragment ciphertext. The method by which the second participant generates the second fragment ciphertext is the same as the method by which the first participant generates the first fragment ciphertext, which can be referred to in step 603 above, and will not be repeated here.

[0244] As an example, the second participant generates the second fragment ciphertext α. j =Enc(pk, z) j ).

[0245] In some embodiments, the second participant may send a proof parameter along with the second fragment ciphertext to actively ensure the security of the interaction.

[0246] Step 605: Perform homomorphic addition on the second fragment ciphertext and the first fragment ciphertext sent by multiple second participants respectively to obtain the homomorphic computation key of the multi-party secure computation system.

[0247] In other words, the first participant can obtain the homomorphic computation key (evk) by performing homomorphic addition on all the fragmented ciphertexts it possesses.

[0248] Taking the first participant as an example, its determined homomorphic computation key can be represented by the following formula (12).

[0249] evk=∑ i Enc(pk, z) = Enc(pk, sk) 2 (12)

[0250] Where evk is the homomorphic computation key, z is the key fragment generated by each participant, Enc(pk, z) is any fragment ciphertext owned by the first participant, pk is the joint public key, and sk is the joint private key.

[0251] It should be understood that, as explained in the privacy multiplication section above, even though random numbers are introduced for encryption security in the interaction process described above, i.e., steps 601-604, they will be canceled out when the sum of the fragmented ciphertexts z is finally calculated. Therefore, the homomorphically computed ciphertext evk will not contain the random numbers introduced in the above calculation process.

[0252] Similarly, for multiple second participants, they can calculate the homomorphic computation key based on the fragmented ciphertext they possess. Their computation logic is similar to that of the first participant, and will not be elaborated here.

[0253] It should be noted that since all the above interactions are conducted in ciphertext, although the first participant and multiple second participants can eventually calculate the same homomorphic computation key evk, the homomorphic computation key evk itself is ciphertext, and the participants do not know its specific plaintext content.

[0254] In summary, in this embodiment, multiple participants exchange private key ciphertexts and perform homomorphic multiplication operations using their own private keys to generate a fragmented ciphertext for each participant. Each participant's fragmented ciphertext represents a share of the homomorphic computation key; that is, each participant can determine a fragment of the homomorphic computation key. By aggregating the fragmented ciphertexts of all participants through encryption, the homomorphic computation key of the multi-party secure computation system is obtained. Thus, by utilizing public-key encryption, homomorphic encryption, and the method of generating the homomorphic computation key by aggregating the fragmented ciphertexts of each participant, this application ensures that each participant does not disclose their private key information during the process of jointly determining the homomorphic computation key, thereby guaranteeing the privacy and security of each participant's private key.

[0255] Figure 7 This is a flowchart of another key generation method provided in an embodiment of this application. This method is applied to the user equipment of the first participant in a multi-party secure computation system. The user equipment can be the one described above. Figure 5 The computer equipment shown. The multi-party secure computation system also includes multiple second parties. Please refer to... Figure 7 The method includes the following steps.

[0256] Step 701: Receive the first private key fragments sent by multiple second participants respectively. The first private key fragments are the fragments of the initial private key of the second participants that were allocated to the first participants.

[0257] In one possible implementation, the first private key fragment is sent to the first participant via a secret sharing method of (t, n), where t and n are positive integers and 1 ≤ t ≤ n; where n is the sum of the number of the first participant and multiple second participants, and (t, n) indicates that the initial private key of the second participant can be recovered if more than t participants provide the corresponding private key fragments.

[0258] In one possible implementation, the second participant can send a fragment of the private key to the first participant along with fragmentation proof parameters for that first private key fragment.

[0259] In this case, the first participant is further configured to: receive fragmentation proof parameters sent by multiple second participants respectively, wherein the fragmentation proof parameters are used to characterize that the first private key fragment is legally obtained by the second participant, and the sum of the first private key fragment and other private key fragments is the same as the initial private key of the second participant, and the other private key fragments are fragments of the initial private key of the second participant divided among other participants besides the first participant; verify the legality of the first private key fragment sent by each of the multiple second participants based on the fragmentation proof parameters sent by the multiple second participants respectively; if the legality verification of the multiple second participants is passed, then the following step 702 is executed.

[0260] Step 702: Generate the private key of the first participant based on the first private key fragments sent by multiple second participants respectively.

[0261] For details on the implementation process of generating the private key of the first participant in steps 701 and 702 above, please refer to [link / reference]. Figure 6 The second method for generating the private key of the first participant shown in the method embodiment has the same implementation process, so it will not be described again here.

[0262] As explained above, after steps 701 and 702, the private key of the first participant is generated as ski = si′.

[0263] Step 703: Encrypt the private key of the first participant to obtain the first private key ciphertext, and broadcast the first private key ciphertext.

[0264] Step 704: Receive the second private key ciphertext sent by multiple second participants respectively. The second private key ciphertext is obtained by encrypting the private key of the second participant.

[0265] After the first participant and multiple second participants determine their own private keys, they can use a joint public key to encrypt their private keys to obtain private key ciphertext, and then exchange their respective private key ciphertexts.

[0266] The first private key ciphertext generated by the first participant is Enc(pk, si′), and the second private key ciphertext generated by the second participant is Enc(pk, sj′).

[0267] In one possible implementation, the process of generating the joint public key can be as follows: obtaining joint parameters, which are jointly determined based on the random number generated by the first participant to generate its own public key and the random numbers generated by the multiple second participants to generate their own public keys respectively; generating the public key of the first participant based on the joint parameters and the private key of the first participant, and broadcasting the public key of the first participant; receiving the public keys of the multiple second participants respectively; and generating the joint public key based on the public keys of the multiple second participants and the public key of the first participant.

[0268] Taking the BGV scheme as an example, the joint parameters are a and b. The process of generating the joint parameters a and b can be found in the previous text. Figure 6 The relevant descriptions of the method implementation examples will not be repeated here.

[0269] Step 705: Based on the first private key ciphertext, the second private key ciphertexts sent by the multiple second participants respectively, and the joint public key, determine the homomorphic computation key of the multi-party secure computation system. The joint public key is determined based on the public key of the first participant and the public keys of the multiple second participants.

[0270] In one possible implementation, the process of generating a homomorphic computation key based on the first private key ciphertext and the second private key ciphertexts sent by multiple second participants may include the following steps (1)-(3).

[0271] (1) The first participant aggregates the first private key ciphertext and the second private key ciphertexts sent by multiple second participants respectively to obtain the ciphertext Enc(pk, sk), where sk is the joint private key, which is equal to the sum of the private keys of all participants, i.e. sk=s1′+s2′+……+sn′.

[0272] (2) The first participant calculates the fragment of the homomorphic computing key evk, that is, the first fragment evki = Enc(pk, sk*si′), and broadcasts evk1.

[0273] (3) The first participant receives the fragments of the homomorphic computing key sent by the other participants, and sums up all the fragments of the homomorphic computing key to obtain the homomorphic computing key.

[0274] As an example, the homomorphic computation key can be represented by the following formula (13).

[0275]

[0276] Where evk is the homomorphic computation key, pk is the joint public key, and sk is the joint private key. By summing the fragments from all participants, sk in the homomorphic computation key can be determined. 2 .

[0277] In summary, when determining the homomorphic computation private key for multiple participants, the embodiments of this application can generate each participant's private key first by exchanging private key fragments. In this way, each participant's private key contains the shares of other participants, avoiding the possibility of theft and leakage of participant private keys, improving the security of participant private keys, and making it impossible for a single participant to deduce and calculate the private keys of each participant. Furthermore, with the private key security guaranteed, when using encrypted private keys and exchanging private key ciphertexts to determine the homomorphic computation key of the multi-party secure computation system, the private keys of each participant will not be leaked, further improving the security of determining the homomorphic computation key.

[0278] It should be noted that, in the above Figure 6 and Figure 7In the implementation process of the key generation method shown, in order to ensure the security of interactive data in the multi-party secure computing system, each of the above-mentioned participants can make a commitment to the data / information they output each time they output data, or attach proof parameters such as consistency proof, so as to achieve active security of multiple participants in the interaction process. In this way, by verifying the legality of the output data / information of each participant, malicious participants can be detected in a timely manner.

[0279] Figure 8 This is a schematic diagram of a key generation device provided in an embodiment of this application. The key generation device can be implemented by software, hardware, or a combination of both, and can be part or all of the user equipment of the first participant in a multi-party secure computing system. This user equipment can be... Figure 5 The computer equipment shown. The multi-party secure computation system also includes multiple second parties. See [link to documentation]. Figure 8 The key generation device 800 includes: a ciphertext receiving module 801, a fragmentation generation module 802, a ciphertext generation module 803, a fragmentation receiving module 804, and a key generation module 805.

[0280] The ciphertext receiving module 801 is used to receive first ciphertext sent by multiple second participants. The first ciphertext is obtained by performing a homomorphic multiplication operation on the private key of each second participant and a first private key ciphertext. The first private key ciphertext is obtained by encrypting the private key of each first participant. For detailed implementation details, please refer to the above. Figure 6 The content of step 601 in the illustrated embodiment will not be repeated here.

[0281] The fragmentation generation module 802 is used to generate a first key fragment based on the first ciphertext sent by multiple second participants and the private keys of the first participants. For detailed implementation details, please refer to the above. Figure 6 The content of step 602 in the illustrated embodiment will not be repeated here.

[0282] The ciphertext generation module 803 is used to encrypt the first key fragment using a joint public key to obtain the first fragment ciphertext. The joint public key is determined based on the public key of the first participant and the public keys of multiple second participants. For detailed implementation details, please refer to the above. Figure 6 The content of step 603 in the illustrated embodiment will not be repeated here.

[0283] The fragment receiving module 804 is used to receive second fragment ciphertext sent by multiple second participants. The second fragment ciphertext is obtained by encrypting a second key fragment using a joint public key. The second key fragment is generated by the second participant based on multiple second ciphertexts and their private keys. The multiple second ciphertexts are obtained by performing homomorphic multiplication operations between the private keys of other participants (excluding the second participant) and the second private key ciphertexts. The second private key ciphertext is obtained by encrypting the private key of the second participant. For detailed implementation details, please refer to the above. Figure 6 The content of step 604 in the illustrated embodiment will not be repeated here.

[0284] The key generation module 805 performs homomorphic addition on the second fragment ciphertext and the first fragment ciphertext sent by multiple second participants to obtain the homomorphic computation key for the multi-party secure computation system. For detailed implementation details, please refer to the above. Figure 6 The content of step 605 in the illustrated embodiment will not be repeated here.

[0285] In one possible implementation, the ciphertext generation module 803 is also used for:

[0286] Receive ciphertexts of the second private key sent by multiple second participants;

[0287] Perform a homomorphic multiplication operation between the private key of the first participant and the ciphertext of the second private key sent by the multiple second participants respectively to obtain the second ciphertext corresponding to the multiple second participants respectively;

[0288] Send the corresponding second ciphertext to each of the multiple second participants.

[0289] In one possible implementation, the ciphertext generation module 803 is also used for:

[0290] For any one of the multiple second participants, receive the first proof parameter sent by the second participant. The first proof parameter is used to characterize that the second private key ciphertext sent by the second participant is legally generated by the second participant, and the private key used to generate the second private key ciphertext is the private key of the second participant.

[0291] Based on the first proof parameters sent by the second participant, verify the legitimacy of the second private key ciphertext sent by the second participant;

[0292] If the legitimacy verification passes, the corresponding second ciphertext is sent to the second participant.

[0293] In one possible implementation, the fragment generation module 802 is specifically used for:

[0294] The sum of the first ciphertexts sent by multiple second participants is decrypted to obtain the first plaintext;

[0295] The first key fragment is generated based on the square of the first plaintext and the private key of the first participant.

[0296] In one possible implementation, the ciphertext generation module 803 is also used for:

[0297] The first participant's private key is encrypted using the first participant's public key to obtain the first private key ciphertext, which is then broadcast.

[0298] In one possible implementation, the ciphertext generation module 803 is also used for:

[0299] Broadcast the second proof parameter, which is used to characterize that the first private key ciphertext was legally generated by the first participant and that the private key used to generate the first private key ciphertext is the private key of the first participant.

[0300] In one possible implementation, the key generation module 805 is further configured to:

[0301] Obtain the initial private key of the first participant and set it as the private key of the first participant; or,

[0302] The first participant's private key is generated by exchanging fragments of their respective initial private keys with multiple second participants. The fragments of the initial private key are obtained by splitting the corresponding initial private key based on a target number, which is the sum of the number of the first participant and the number of multiple second participants.

[0303] In one possible implementation, the key generation module 805 is further configured to:

[0304] Receive first private key fragments sent by multiple second participants respectively. The first private key fragments are the fragments of the initial private key of the second participants that were allocated to the first participants.

[0305] The private key of the first participant is generated based on the first private key fragments sent by multiple second participants.

[0306] In this embodiment, multiple participants exchange private key ciphertexts and ciphertexts obtained by homomorphic multiplication using their own private keys. Each participant can generate a fragmented ciphertext. Each participant's fragmented ciphertext represents a share of the homomorphic computation key; that is, each participant can determine a fragment of the homomorphic computation key. By aggregating the fragmented ciphertexts of all participants through encryption, the homomorphic computation key of the multi-party secure computation system is obtained. Thus, by utilizing public-key encryption, homomorphic encryption, and the method of generating the homomorphic computation key by aggregating the fragmented ciphertexts of each participant, this application ensures that each participant does not disclose their private key information during the process of jointly determining the homomorphic computation key, thereby guaranteeing the privacy and security of each participant's private key.

[0307] It should be noted that the key generation device 800 provided in the above embodiments is only illustrated by the division of the functional modules described above when generating homomorphic computing keys. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the key generation device 800 provided in the above embodiments and... Figure 6 The method implementations are based on the same concept, and their specific implementation process can be found in the method implementations, which will not be repeated here.

[0308] Figure 9 This is a schematic diagram of a key generation device provided in an embodiment of this application. The key generation device can be implemented by software, hardware, or a combination of both, and can be part or all of the user equipment of the first participant in a multi-party secure computing system. This user equipment can be... Figure 5 The computer equipment shown. The multi-party secure computation system also includes multiple second parties. See [link to documentation]. Figure 9 The key generation device 900 includes: a fragment receiving module 901, a private key generation module 902, a ciphertext generation module 903, a ciphertext receiving module 904, and a key generation module 905.

[0309] The fragment receiving module 901 is used to receive first private key fragments sent by multiple second participants. The first private key fragments are the fragments allocated to the first participants from the initial private keys of the second participants. For detailed implementation details, please refer to the above. Figure 7 The content of step 701 in the illustrated embodiment will not be repeated here.

[0310] The private key generation module 902 is used to generate the private key of the first participant based on the first private key fragments sent by multiple second participants. For detailed implementation process, please refer to the above. Figure 7 The content of step 702 in the illustrated embodiment will not be repeated here.

[0311] The ciphertext generation module 903 is used to encrypt the private key of the first participant to obtain the first private key ciphertext, and then broadcast the first private key ciphertext. For detailed implementation details, please refer to the above. Figure 7 The content of step 703 in the illustrated embodiment will not be repeated here.

[0312] The ciphertext receiving module 904 is used to receive second private key ciphertexts sent by multiple second participants. These second private key ciphertexts are obtained by encrypting the private keys of the second participants. For detailed implementation details, please refer to the above. Figure 7 The content of step 704 in the illustrated embodiment will not be repeated here.

[0313] The key generation module 905 is used to determine the homomorphic computation key of the multi-party secure computation system based on the first private key ciphertext, the second private key ciphertexts sent by multiple second participants respectively, and the joint public key. The joint public key is determined based on the public key of the first participant and the public keys of multiple second participants. For detailed implementation process, please refer to the above. Figure 7 The content of step 705 in the illustrated embodiment will not be repeated here.

[0314] In one possible implementation, the private key generation module 902 is also used for:

[0315] Receive fragmentation proof parameters sent by multiple second participants respectively. The fragmentation proof parameters are used to characterize that the first private key fragment is legally obtained by the second participant, and the sum of the first private key fragment and other private key fragments is the same as the initial private key of the second participant. The other private key fragments are fragments that are divided from the initial private key of the second participant and distributed to other participants other than the first participant.

[0316] Based on the fragmented proof parameters sent by multiple second participants, the legitimacy of the first private key fragment sent by each of the multiple second participants is verified.

[0317] If the legitimacy verification of multiple second participants passes, then the step of generating the private key of the first participant is performed based on the first private key fragments sent by the multiple second participants respectively.

[0318] In one possible implementation, the first private key fragment is sent to the first participant via a secret sharing of (t, n), where t and n are positive integers and 1 ≤ t ≤ n;

[0319] Where n is the sum of the number of the first participant and multiple second participants, and (t, n) indicates that the initial private key of the second participant can be recovered if more than t participants provide corresponding private key fragments.

[0320] In one possible implementation, the key generation module 905 is further used for:

[0321] Obtain the joint parameters, which are determined by combining the random numbers generated by the first participant for its own public key and the random numbers generated by multiple second participants for their own public keys.

[0322] Based on the joint parameters and the private key of the first participant, generate the public key of the first participant and broadcast the public key of the first participant;

[0323] Receive the public keys of multiple second participants;

[0324] A joint public key is generated based on the public keys of multiple second participants and the public key of the first participant.

[0325] In this embodiment, when determining the homomorphic computation private key for multiple participants, each participant's private key can be generated first by exchanging private key shards. In this way, each participant's private key contains the shares of other participants, avoiding the possibility of theft and leakage of participant private keys, improving the security of participant private keys, and making it impossible for a single participant to deduce and compute the private keys of other participants. Furthermore, with the private keys secure, when using encrypted private keys and exchanging private key ciphertexts to determine the homomorphic computation key of the multi-party secure computation system, the private keys of each participant will not be leaked, further improving the security of determining the homomorphic computation key.

[0326] It should be noted that the key generation device 900 provided in the above embodiments is only illustrated by the division of the above functional modules when generating homomorphic computing keys. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the key generation device 900 provided in the above embodiments and... Figure 7 The method implementations are based on the same concept, and their specific implementation process can be found in the method implementations, which will not be repeated here.

[0327] This application also provides a computer-readable storage medium storing instructions that, when executed on a processor, cause the processor to perform the steps of the key generation method shown in the above embodiments.

[0328] This application also provides a computer program product containing instructions that, when executed on a processor, cause the processor to perform the method for determining the output result of a model as described in the above embodiments. Alternatively, a computer program is provided that, when executed on a processor, causes the processor to perform the steps of the key generation method described in the above embodiments.

[0329] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital versatile disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiments of this application can be a non-volatile storage medium; in other words, it can be a non-transient storage medium.

[0330] It should be understood that "multiple" as mentioned herein refers to two or more. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and the terms "first," "second," etc., do not necessarily imply that they are different.

[0331] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0332] The above descriptions are embodiments provided in this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A key generation method, characterized in that, A first participant in a multi-party secure computation system, wherein the multi-party secure computation system also includes multiple second participants, the method comprising: The system receives first ciphertext sent by the plurality of second participants respectively. The first ciphertext is obtained by performing a homomorphic multiplication operation on the private key of the second participant and the first private key ciphertext. The first private key ciphertext is obtained by encrypting the private key of the first participant. Based on the first ciphertext sent by the plurality of second participants and the private key of the first participant, a first key fragment is generated; The first key fragment is encrypted using a joint public key to obtain the first fragment ciphertext. The joint public key is determined based on the public key of the first participant and the public keys of the plurality of second participants. The system receives second ciphertext fragments sent by the plurality of second participants. The second ciphertext fragments are obtained by the second participants encrypting the second key fragments using the joint public key. The second key fragments are generated by the second participants based on the plurality of second ciphertext fragments and the private key of the second participants. The plurality of second ciphertext fragments are obtained by performing homomorphic multiplication operations between the private keys of the participants other than the second participants and the second private key ciphertexts. The second private key ciphertexts are obtained by encrypting the private key of the second participants. Homomorphic addition is performed on the second fragment ciphertext and the first fragment ciphertext sent by the multiple second participants respectively to obtain the homomorphic computation key of the multi-party secure computation system.

2. The method as described in claim 1, characterized in that, Before receiving the second fragment ciphertext sent by the plurality of second participants respectively, the method further includes: Receive the second private key ciphertext sent by the plurality of second participants respectively; The private key of the first participant is homomorphically multiplied with the ciphertexts of the second private keys sent by the plurality of second participants respectively to obtain the second ciphertexts corresponding to the plurality of second participants respectively. Each of the multiple second participants sends its corresponding second ciphertext.

3. The method as described in claim 2, characterized in that, Sending the respective second ciphertexts to the plurality of second participants includes: For any one of the plurality of second participants, a first proof parameter is received from the second participant. The first proof parameter is used to characterize that the second private key ciphertext sent by the second participant is legally generated by the second participant, and the private key used to generate the second private key ciphertext is the private key of the second participant. Based on the first proof parameters sent by the second participant, verify the legitimacy of the second private key ciphertext sent by the second participant; If the legitimacy verification passes, the corresponding second ciphertext is sent to the second participant.

4. The method according to any one of claims 1-3, characterized in that, The step of generating a first key fragment based on the first ciphertext sent by the plurality of second participants and the private key of the first participant includes: The sum of the first ciphertexts sent by the plurality of second participants is decrypted to obtain the first plaintext; The first key fragment is generated based on the square of the first plaintext and the private key of the first participant.

5. The method according to any one of claims 1-4, characterized in that, Before generating the first key fragment based on the first ciphertext sent by the plurality of second participants and the private key of the first participant, the method further includes: The first participant's private key is encrypted using the first participant's public key to obtain the first private key ciphertext, and then the first private key ciphertext is broadcast.

6. The method as described in claim 5, characterized in that, The method further includes: Broadcast a second proof parameter, which is used to characterize that the first private key ciphertext was legally generated by the first participant and that the private key used to generate the first private key ciphertext is the private key of the first participant.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Obtain the initial private key of the first participant, and determine the initial private key as the private key of the first participant; or, The first participant's private key is generated by exchanging fragments of their respective initial private keys with the plurality of second participants. The fragments of the initial private key are obtained by splitting the corresponding initial private key based on a target number, which is the sum of the number of the first participant and the plurality of second participants.

8. The method as described in claim 7, characterized in that, The step of generating the private key of the first participant by exchanging fragments of their respective initial private keys with the plurality of second participants includes: Receive first private key fragments sent by the plurality of second participants respectively, wherein the first private key fragment is a fragment of the initial private key of the second participant that is allocated to the first participant; Based on the first private key fragments sent by the plurality of second participants, the private key of the first participant is generated.

9. A key generation method, characterized in that, A first participant in a multi-party secure computation system, wherein the multi-party secure computation system also includes multiple second participants, the method comprising: Receive first private key fragments sent by the plurality of second participants respectively, wherein the first private key fragment is a fragment of the initial private key of the second participant that is allocated to the first participant; Based on the first private key fragments sent by the plurality of second participants respectively, the private key of the first participant is generated; The private key of the first participant is encrypted to obtain the first private key ciphertext, and the first private key ciphertext is broadcast. Receive the second private key ciphertext sent by the plurality of second participants respectively, wherein the second private key ciphertext is obtained by encrypting the private key of the second participant; Based on the first private key ciphertext, the second private key ciphertexts sent by the plurality of second participants respectively, and the joint public key, a homomorphic computation key for the multi-party secure computation system is generated. The joint public key is determined based on the public key of the first participant and the public keys of the plurality of second participants.

10. The method as described in claim 9, characterized in that, Before generating the private key of the first participant based on the first private key fragments sent by the plurality of second participants respectively, the method further includes: The system receives fragmentation proof parameters sent by the plurality of second participants respectively. The fragmentation proof parameters are used to characterize that the first private key fragment is legally obtained by the second participant, and the sum of the first private key fragment and other private key fragments is the same as the initial private key of the second participant. The other private key fragments are fragments that are divided from the initial private key of the second participant and distributed to other participants other than the first participant. Based on the fragmentation proof parameters sent by the plurality of second participants respectively, the legality of the first private key fragments sent by each of the plurality of second participants is verified; If the legitimacy verification of the plurality of second participants is passed, then the step of generating the private key of the first participant based on the first private key fragment sent by the plurality of second participants is executed.

11. The method as described in claim 9 or 10, characterized in that, The first private key fragment is sent to the first participant via a secret sharing method of (t, n), where t and n are positive integers and 1 ≤ t ≤ n; Where n is the sum of the number of the first participant and the plurality of second participants, and (t, n) indicates that the initial private key of the second participant can be recovered if more than t participants provide corresponding private key fragments.

12. The method according to any one of claims 9-11, characterized in that, Before generating the homomorphic computation key for the multi-party secure computation system based on the first private key ciphertext, the second private key ciphertexts sent by the plurality of second participants respectively, and the joint public key, the method further includes: Obtain the joint parameters, which are determined jointly based on the random number generated by the first participant to generate its own public key and the random numbers generated by the multiple second participants to generate their own public keys respectively; Based on the joint parameters and the private key of the first participant, generate the public key of the first participant and broadcast the public key of the first participant; Receive the public keys of each of the plurality of second participants; The joint public key is generated based on the public keys of the various second participants and the public key of the first participant.

13. A key generation device, characterized in that, A first participant included in a multi-party secure computation system, the multi-party secure computation system further including multiple second participants, the device comprising: The ciphertext receiving module is used to receive the first ciphertext sent by the plurality of second participants respectively. The first ciphertext is obtained by performing a homomorphic multiplication operation on the private key of the second participant and the first private key ciphertext. The first private key ciphertext is obtained by encrypting the private key of the first participant. The fragmentation generation module is used to generate a first key fragment based on the first ciphertext sent by the plurality of second participants and the private key of the first participant respectively. The ciphertext generation module is used to encrypt the first key fragment using a joint public key to obtain the first fragment ciphertext, wherein the joint public key is determined based on the public key of the first participant and the public keys of the plurality of second participants; The fragment receiving module is used to receive second fragment ciphertext sent by the plurality of second participants respectively. The second fragment ciphertext is obtained by the second participant encrypting the second key fragment using the joint public key. The second key fragment is generated by the second participant based on the plurality of second ciphertexts and the private key of the second participant. The plurality of second ciphertexts are obtained by performing homomorphic multiplication operations between the private keys of the participants other than the second participant and the second private key ciphertexts respectively. The second private key ciphertext is obtained by encrypting the private key of the second participant. The key generation module is used to perform homomorphic addition operations on the second fragment ciphertext and the first fragment ciphertext sent by the multiple second participants respectively, to obtain the homomorphic computation key of the multi-party secure computation system.

14. The apparatus as claimed in claim 13, characterized in that, The ciphertext generation module is also used for: Receive the second private key ciphertext sent by the plurality of second participants respectively; The private key of the first participant is homomorphically multiplied with the ciphertexts of the second private keys sent by the plurality of second participants respectively to obtain the second ciphertexts corresponding to the plurality of second participants respectively. Each of the multiple second participants sends its corresponding second ciphertext.

15. The apparatus as claimed in claim 14, characterized in that, The ciphertext generation module is also used for: For any one of the plurality of second participants, a first proof parameter is received from the second participant. The first proof parameter is used to characterize that the second private key ciphertext sent by the second participant is legally generated by the second participant, and the private key used to generate the second private key ciphertext is the private key of the second participant. Based on the first proof parameters sent by the second participant, verify the legitimacy of the second private key ciphertext sent by the second participant; If the legitimacy verification passes, the corresponding second ciphertext is sent to the second participant.

16. The apparatus according to any one of claims 13-15, characterized in that, The sharding generation module is also used for: The sum of the first ciphertexts sent by the plurality of second participants is decrypted to obtain the first plaintext; The first key fragment is generated based on the square of the first plaintext and the private key of the first participant.

17. The apparatus according to any one of claims 13-16, characterized in that, The ciphertext generation module is also used for: The first participant's private key is encrypted using the first participant's public key to obtain the first private key ciphertext, and then the first private key ciphertext is broadcast.

18. The apparatus as claimed in claim 17, characterized in that, The ciphertext generation module is also used for: Broadcast a second proof parameter, which is used to characterize that the first private key ciphertext was legally generated by the first participant and that the private key used to generate the first private key ciphertext is the private key of the first participant.

19. The apparatus according to any one of claims 13-18, characterized in that, The key generation module is also used for: Obtain the initial private key of the first participant, and determine the initial private key as the private key of the first participant; or, The first participant's private key is generated by exchanging fragments of their respective initial private keys with the plurality of second participants. The fragments of the initial private key are obtained by splitting the corresponding initial private key based on a target number, which is the sum of the number of the first participant and the plurality of second participants.

20. The apparatus as claimed in claim 19, characterized in that, The key generation module is also used for: Receive first private key fragments sent by the plurality of second participants respectively, wherein the first private key fragment is a fragment of the initial private key of the second participant that is allocated to the first participant; Based on the first private key fragments sent by the plurality of second participants, the private key of the first participant is generated.

21. A key generation device, characterized in that, A first participant included in a multi-party secure computation system, the multi-party secure computation system further including multiple second participants, the device comprising: The fragment receiving module is used to receive the first private key fragments sent by the plurality of second participants respectively. The first private key fragment is a fragment of the initial private key of the second participant that is divided and assigned to the first participant. The private key generation module is used to generate the private key of the first participant based on the first private key fragments sent by the plurality of second participants respectively. The ciphertext generation module is used to encrypt the private key of the first participant to obtain the first private key ciphertext, and broadcast the first private key ciphertext. The ciphertext receiving module is used to receive the second private key ciphertext sent by the plurality of second participants respectively, wherein the second private key ciphertext is obtained by encrypting the private key of the second participant; A key generation module is used to generate a homomorphic computation key for the multi-party secure computation system based on the first private key ciphertext, the second private key ciphertexts sent by the plurality of second participants respectively, and a joint public key, wherein the joint public key is determined based on the public key of the first participant and the public keys of the plurality of second participants.

22. The apparatus as claimed in claim 21, characterized in that, The private key generation module is also used for: The system receives fragmentation proof parameters sent by the plurality of second participants respectively. The fragmentation proof parameters are used to characterize that the first private key fragment is legally obtained by the second participant, and the sum of the first private key fragment and other private key fragments is the same as the initial private key of the second participant. The other private key fragments are fragments that are divided from the initial private key of the second participant and distributed to other participants other than the first participant. Based on the fragmentation proof parameters sent by the plurality of second participants respectively, the legality of the first private key fragments sent by each of the plurality of second participants is verified; If the legitimacy verification of the plurality of second participants is passed, then the step of generating the private key of the first participant based on the first private key fragment sent by the plurality of second participants is executed.

23. The apparatus as claimed in claim 21 or 22, characterized in that, The first private key fragment is sent to the first participant via a secret sharing method of (t, n), where t and n are positive integers and 1 ≤ t ≤ n; Where n is the sum of the number of the first participant and the plurality of second participants, and (t, n) indicates that the initial private key of the second participant can be recovered if more than t participants provide corresponding private key fragments.

24. The apparatus according to any one of claims 21-23, characterized in that, The key generation module is also used for: Obtain the joint parameters, which are determined jointly based on the random number generated by the first participant to generate its own public key and the random numbers generated by the multiple second participants to generate their own public keys respectively; Based on the joint parameters and the private key of the first participant, generate the public key of the first participant and broadcast the public key of the first participant; Receive the public keys of each of the plurality of second participants; The joint public key is generated based on the public keys of the various second participants and the public key of the first participant.

25. A computer device, characterized in that, The computer device includes a processor and memory; The memory is used to store computer programs; The processor is configured to execute the computer program to implement the method of any one of claims 1-8, or to implement the method of any one of claims 9-12.

26. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-8, or the method described in any one of claims 9-12.

27. A computer program product, characterized in that, The computer program product stores computer instructions, which, when executed by a processor, implement the method described in any one of claims 1-8, or the method described in any one of claims 9-12.

Images