A three-party collaborative ECDSA signature generation method and system

Abstract

The present invention discloses a three-party collaborative ECDSA signature generation method and system, wherein the method includes: three-party collaborative key generation, three-party collaborative signature, two-party collaborative key generation and two-party collaborative signature. The present invention can tolerate the situation where one party is offline or acts maliciously, and any two parties can recover the secret value. Under normal circumstances, the three parties share a collaborative signature based on the copy secret. When one party is offline, the remaining two parties execute the two-party collaborative signature protocol to generate a complete digital signature. The security and performance requirements of the collaborative signature technology are fully balanced to ensure that digital signatures are generated safely, reliably and quickly in a three-party environment. The present invention has the advantages of high security, strong flexibility, high performance, etc., and can be applied to any application scenario that supports secure multi-party computing.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to a three-party collaborative ECDSA signature generation method and system. Background Art

[0002] ECDSA is an algorithm for implementing digital signatures using elliptic curve cryptography. Based on the mathematical properties of elliptic curves, it provides a secure and efficient digital signature method. Digital signature technology is widely used in fields such as cryptocurrency, digital certificates, and secure communications. Similar to traditional signatures, it uses specific cryptographic algorithms to simulate the function of a paper signature or seal, thereby ensuring the integrity, authenticity, and non-repudiation of digital resources. While ECDSA signature technology is theoretically secure, it may face certain threats and attacks in practice. The most serious security threat is the leakage of private keys. If a private key is leaked, hackers or attackers can use it to generate valid signatures and impersonate legitimate users to conduct fraudulent activities. Therefore, protecting the security of private keys is crucial.

[0003] Collaborative signature technology allows multiple parties to jointly generate keys, preventing any single entity or a small number of colluders from obtaining the full private key without permission. Multiple signers jointly complete the signature, ensuring that all parties agree and authorize the signed content, and preventing a single entity from abusing signing authority. This technology is very useful in scenarios requiring the participation and consent of multiple parties, such as multi-party contracts and multi-party authorizations. However, collaborative signature technology can also increase complexity and computational cost, and existing technologies cannot guarantee a balance between security, reliability, and performance when applying these technologies. Summary of the Invention

[0004] This paper proposes a three-party collaborative ECDSA signature generation method and system based on replicated secret sharing. This method can tolerate situations where one party is offline or acts maliciously (either maliciously or corrupted by a malicious adversary). Any two participating parties can recover the secret value. If one party is offline, the remaining two parties still hold all shares and share the secret, thereby collaboratively generating a complete digital signature. This method fully balances the security and performance requirements of collaborative signature technology, ensuring secure, reliable, and rapid digital signature generation in a three-party environment.

[0005] The technical solution adopted in the present invention is as follows:

[0006] A first aspect provides a three-party collaborative ECDSA signature generation method, including:

[0007] The three parties use a pseudo-random function and a shared key to generate a secret share of the signature private key, and jointly generate a first signature verification public key based on the cryptographic sharing of the signature private key held by each party;

[0008] The three parties use the replicated secret sharing technique to recover the secret value to be shared, interactively calculate the intermediate variable of the complete signature, and obtain the first complete signature based on the message to be signed, the first signature verification public key, and the intermediate variable of the first complete signature;

[0009] When one participant is offline or corrupted by a malicious adversary, the replicated secret sharing is converted into a two-party additive secret sharing, and the other two participants jointly generate a second signature verification public key;

[0010] The other two participants interactively calculate the intermediate variable of the second complete signature, and obtain the second complete signature based on the message to be signed, the second signature verification public key and the intermediate variable of the second complete signature.

[0011] In one embodiment, the three parties generate a secret share of the signature private key using a pseudorandom function and a shared key, and jointly generate a first signature verification public key based on the cryptographic share of the signature private key held by each party, including:

[0012] Each participant initializes a counter and generates their own shared key based on the initialization ideal function;

[0013] Each participant uses a pseudo-random function and the shared key they hold to calculate the secret share of the signature private key;

[0014] Each participant calculates the public key component based on the cryptographic sharing of the signature private key they hold, and sends the calculated public key component to other participants;

[0015] Each participant determines whether the public key component is valid based on whether the public key component calculated by itself is consistent with the received component. If each public key component is consistent, it indicates that each participant has honestly executed the protocol and the public key component is valid. At this time, the public signature verification public key is calculated based on each public key component. If there is an inconsistency in the public key components, it means that there is a malicious participant who dishonestly executes the protocol, the public key component is invalid, and the protocol terminates.

[0016] In one embodiment, the three parties use a replicated secret sharing technique to recover the secret value to be shared, interactively calculate the intermediate variable of the first complete signature, and obtain the first complete signature based on the message to be signed, the first signature verification public key, and the intermediate variable of the first complete signature, including:

[0017] Each participant updates the counter and uses the pseudo-random function and the shared key to calculate the secret share of the random number k;

[0018] Each participant calculates the signature parameter component based on the secret sharing of the random number k held by each participant, and sends the signature parameter component calculated by itself to other participants. Each participant determines the validity of the signature parameter component based on whether the signature parameter component calculated by itself is consistent with the received signature parameter component. If each signature parameter component is consistent, it means that each participant has honestly executed the protocol, the signature parameter component is valid, and the first signature parameter is calculated based on the signature parameter component. If there is a signature parameter inconsistency, it means that a malicious participant has dishonestly executed the protocol, the signature parameter component is invalid, and the protocol terminates;

[0019] Each participant updates the counter and uses the pseudo-random function and the shared key to calculate the secret share of the random number ρ;

[0020] Each participant calculates the intermediate parameter α component based on the secret sharing of the shared key and random number ρ held by each party;

[0021] Each participant sends the intermediate parameter α component to other participants, and the intermediate parameter is calculated based on the intermediate parameter α component;

[0022] Each participant calculates the intermediate parameter β component based on the first signature parameter, the hash function, and the secret sharing of the signature private key held by each participant, and sends the intermediate parameter β component calculated by itself to other participants;

[0023] Each participant calculates a signature parameter component based on the intermediate parameter β component, and sends the calculated signature parameter component to other participants. The second signature parameter is calculated based on all signature parameter components. The first signature parameter and the second signature parameter constitute the three-party collaborative generation of the first complete signature.

[0024] In one embodiment, when one participant is offline or corrupted by a malicious adversary, the replicated secret sharing is converted to a two-party additive secret sharing, and the other two participants jointly generate a second signature verification public key, including:

[0025] The other two participants each randomly select an integer as their own signature private key component, calculate the public key component and zero-knowledge proof based on the selected integer, and send the public key component and zero-knowledge proof calculated based on the selected integer to the other participant;

[0026] Each participant verifies whether the received zero-knowledge proof is legitimate one by one; if the verification is successful, the public second signature verification public key is calculated based on the public key component calculated based on the selected integer.

[0027] In one embodiment, the other two parties interactively calculate the intermediate variable of the second complete signature, and obtain the second complete signature based on the message to be signed, the second signature verification public key, and the intermediate variable of the second complete signature, including:

[0028] The two participants each randomly select two integers, calculate the signature parameter components, and generate a zero-knowledge proof. They then send the generated signature parameter components and the zero-knowledge integers to the other participant.

[0029] The two participants verify the legitimacy of the received zero-knowledge proof one by one; if the verification is successful, the third signature parameter is calculated based on the signature parameter components;

[0030] The two participants use the ideal function to obtain the first calculation result based on the signature private key component they hold and the selected random integer. The two participants calculate the intermediate parameter α component based on the first calculation result. The ideal function Defined as f((a1,b1),...,(a n ,b n ))=(c1,...,c n ),and Among them, (a1,b1), (a n ,b n ) is an ideal function The input parameters, (c1,...,c n ) is an ideal function The output result;

[0031] The two participants respectively use the ideal function to obtain a second calculation result based on the selected random number and the calculated intermediate variable, and the two participants respectively calculate the intermediate parameter β component based on the second calculation result.

[0032] The two participants send the intermediate parameter α component and the intermediate parameter β component they hold to each other, calculate and obtain the fourth signature parameter, and construct the pre-signature value by the third signature parameter and the fourth signature parameter.

[0033] In one embodiment, the pseudorandom function is F(·), and each participant uses the pseudorandom function and the shared key held to calculate the secret sharing of the signature private key, including:

[0034] The first participant P1 calculates x1=F(k 13 + count1) and x2 = F(k 12 + count1), the second participant P2 calculates x2 = F(k 12 + count2) and x3 = F(k 23 + count2), the third party P3 calculates x1 = F(k 13 + count3) and x3 = F(k 23 +count3), where x1 and x2 are the secret shares of the signature private key calculated by the first participant, k 13and k 12 is the shared key held by the first participant, count1 is the counter corresponding to the first participant, k 12 and k 23 is the shared key held by the second participant, count2 is the counter corresponding to the second participant, x2 and x3 are the secret sharing of the signature private key calculated by the second participant, count3 is the counter corresponding to the third participant, k 13 and k 23 is the shared key held by the third party, and x1 and x3 are the secret sharing of the signature private key calculated by the third party.

[0035] In one embodiment, each participant calculates the intermediate parameter β component based on the first signature parameter, the hash function, and the secret sharing of the signature private key held by each participant, and sends the intermediate parameter β component calculated by itself to other participants, including:

[0036] The first party P1 calculates Then calculate the intermediate parameter β component β1 = h1ρ1 + h1ρ2 + h2ρ1, where h1 and h2 are the intermediate parameters calculated by the first participant, ρ1 and ρ2 are the secret shares of the random number ρ calculated by the first participant; H(·) is a cryptographic function derived from the cryptographic hash function, m is the message to be signed, and x1 and x2 are the secret shares of the signing private key calculated by the first participant;

[0037] The second party P2 calculates Calculate the intermediate parameter β component β2 = h2ρ2 + h2ρ3 + h3ρ2, where h3 and h2 are the intermediate parameters calculated by the second participant, ρ2 and ρ3 are the secret sharing of the random number ρ calculated by the second participant, and x3 and x2 are the secret sharing of the signature private key calculated by the second participant;

[0038] Third-party P3 calculation Calculate the intermediate parameter β component β3 = h3ρ3 + h3ρ1 + h1ρ3, where h1 and h3 are the intermediate parameters calculated by the third party, ρ3 and ρ1 are the secret sharing of the random number ρ calculated by the third party; x1 and x3 are the secret sharing of the signature private key calculated by the third party;

[0039] The first participant will hold the intermediate parameter β component β1 and send it to the second and third participants. The second participant will hold the intermediate parameter β component β2 and send it to the first and third participants. The third participant will hold the intermediate parameter β component β3 and send it to the first and second participants. Then the first participant P1 holds (β1, β2), the second participant P2 holds (β2, β3), and the third participant P3 holds (β1, β3).

[0040] Based on the same inventive concept, the second aspect of the present invention provides a three-party collaborative ECDSA signature generation system, comprising:

[0041] A three-party collaborative key generation module is used by the three parties to generate a secret sharing of the signature private key using a pseudo-random function and a shared key, and to jointly generate a first signature verification public key based on the cryptographic sharing of the signature private key held by each party;

[0042] A three-party collaborative signature module, which is used by the three parties to recover the secret value to be shared using the replicated secret sharing technique, interactively calculate the intermediate variables of the complete signature, and obtain the first complete signature based on the message to be signed, the first signature verification public key, and the intermediate variables of the first complete signature;

[0043] A two-party collaborative key generation module, which is used to convert replicated secret sharing into two-party additive secret sharing when one participant is offline or corrupted by a malicious adversary, and the other two participants jointly generate a second signature verification public key;

[0044] The two-party collaborative signature module is used for the other two participants to interactively calculate the intermediate variables of the second complete signature, and obtain the second complete signature based on the message to be signed, the second signature verification public key and the intermediate variables of the second complete signature.

[0045] Based on the same inventive concept, the third aspect of the present invention provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it implements the three-party collaborative ECDSA signature generation method described in the first aspect.

[0046] Based on the same inventive concept, the fourth aspect of the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the program, the three-party collaborative ECDSA signature generation method described in the first aspect is implemented.

[0047] Compared with the prior art, the advantages and beneficial technical effects of the present invention are as follows:

[0048] This paper provides a three-party collaborative ECDSA signature generation method that utilizes replicated secret sharing technology, enabling the generation of a complete digital signature in a three-party environment with only two parties online, ensuring the flexibility and robustness of digital signatures. Relying on multi-prover zero-knowledge proofs and the security of secure multi-party computation protocols, the correctness and privacy of the three-party collaborative signature are guaranteed. By optimizing the sharing of the secret component in the three-party signature, the method reduces the amount of communication between the participating parties, improves communication efficiency, and allows the use of parallel strategies to enhance system performance. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0050] Figure 1 Flowchart of the three-party collaborative key generation protocol provided by an embodiment of the present invention;

[0051] Figure 2 Flowchart of the three-party collaborative signature protocol provided by an embodiment of the present invention;

[0052] Figure 3 Flowchart of a two-party collaborative key generation protocol provided by an embodiment of the present invention;

[0053] Figure 4 A flowchart of a two-party collaborative signature protocol provided by an embodiment of the present invention;

[0054] Figure 5 This is a diagram of the overall framework of the three-party collaborative ECDSA signature generation system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0055] While collaborative signature techniques are very useful in scenarios requiring multi-party participation and consent, they can also increase complexity and computational cost due to the need to manage multiple signature parts and ensure that the security of the signatures is not compromised when they are merged. Therefore, when applying these techniques, careful consideration should be given to balancing security, reliability, and performance.

[0056] Based on the above considerations, the present invention designs a three-party collaborative ECDSA signature generation method and system based on replicated secret sharing. This method can tolerate the situation where one party is offline or acts maliciously, allowing any two participating parties to recover the secret value. If one party is offline, the remaining two parties still hold all shares and share the secret, thereby collaboratively generating a complete digital signature. This method fully balances the security and performance requirements of collaborative signature technology, ensuring safe, reliable and fast digital signature generation in a three-party environment.

[0057] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0058] Example 1

[0059] The present invention discloses a three-party collaborative ECDSA signature generation method, comprising:

[0060] The three parties use a pseudo-random function and a shared key to generate a secret share of the signature private key, and jointly generate a first signature verification public key based on the cryptographic share of the signature private key held by each party;

[0061] The three parties use the replicated secret sharing technique to recover the secret value to be shared, and interactively calculate the intermediate variable of the complete signature, and obtain the first complete signature based on the message to be signed, the first signature verification public key, and the intermediate variable of the first complete signature;

[0062] When one participant is offline or corrupted by a malicious adversary, the replicated secret sharing is converted into a two-party additive secret sharing, and the other two participants jointly generate a second signature verification public key;

[0063] The other two participants interactively calculate the intermediate variable of the second complete signature, and obtain the second complete signature based on the message to be signed, the second signature verification public key and the intermediate variable of the second complete signature.

[0064] To ensure universality, the parameters selected in this invention are consistent with the standard parameters of the ECDSA signature algorithm. The specific symbols are described as follows:

[0065] P1, P2, P3: first party, second party, third party;

[0066] q: a large prime number.

[0067] The set of integers consisting of 1, 2, ..., q-1.

[0068] The elliptic curve group of order N.

[0069] G: elliptic curve Generator.

[0070] x i :Participant P i The signature private key.

[0071] Q: Digital signature verification public key.

[0072] k·P: k times the point P on the elliptic curve, where k is a positive integer.

[0073] H(·): A cryptographic function derived from a cryptographic hash function.

[0074] Initialize the ideal function and generate the seed key for replicating the secret sharing.

[0075] F(·): pseudorandom function PRF.

[0076] A zero-knowledge proof algorithm for generating statements about discrete logarithmic relations.

[0077] Zero-knowledge proof of discrete logarithm relations. m: the message to be signed.

[0078] Specifically, the three-party collaborative ECDSA signature generation method proposed in the present invention includes three-party collaborative key generation, three-party collaborative signature, two-party collaborative key generation and two-party collaborative signature steps.

[0079] In one embodiment, the three-party collaborative key generation step includes: the three signing parties initialize the ideal function The generated shared key, the participants use the pseudo-random function F(·) and the shared key to generate the secret sharing of the signature private key, and jointly generate a publicly releaseable signature verification public key Q (the first signature verification public key), and each signing participant is recorded as P i (u∈{1,2,3}). See Figure 1 , which can be achieved through the following steps:

[0080] a) Each participant P i Initialize the corresponding counter count i , and based on the ideal function Generate their own shared keys, P1 holds the shared key (k 12 ,k 13 ), P2 holds the shared key (k 12 ,k 23 ), P3 holds the shared key (k 13 ,k 23 ).

[0081] The random number

[0082] b) Each participant P i The secret sharing of the signature private key is calculated using the pseudo-random function F(·) and the shared key held. Where P1 calculates x1=F(k 13 + count1) and x2 = F(k 12 + count1), P2 calculates x2 = F(k 12 + count2) and x3 = F(k 23 + count2), P3 calculates x1=F(k 13 + count3) and x3 = F(k 23 + count3).

[0083] c) Each participant P i The public key components Q1, Q2, and Q3 are calculated based on the password sharing of the signature private key held by each party. P1 calculates Q1 = x1·G and Q2 = x2·G, P2 calculates Q2 = x2·G and Q3 = x3·G, and P3 calculates Q1 = x1·G and Q3 = x3·G. And the participant P i Will hold Q i ,Q i+1 Sent to participant P i+1 ,P i+2 . That is, participant P1 will

[0084] Q1 and Q2 are sent to participants P2 and P3, participant P2 sends Q2 and Q3 to participants P3 and P1, and participant P3 sends Q1 and Q3 to participants P1 and P2.

[0085] d) After step c), each participant P i Two signature verification public key components Q1, Q2, Q3 will be held to verify the consistency of the public key components. If each public key component is consistent, it means that each participant has honestly executed the agreement, the public key component is valid, and the public signature verification public key is calculated. If there is an inconsistency in the public key components, it means that there is a malicious party that is dishonestly executing the protocol, the public key components are invalid, and the protocol (three-party collaborative key generation step) is terminated.

[0086] In one embodiment, the three-party collaborative signing step includes: the three signing parties jointly execute the distributed signature generation protocol, use the replicated secret sharing technology to recover the secret value to be shared, and use the ideal function Interactively calculate the intermediate variables to obtain the complete signature value σ=(r,s). Figure 2 , which can be achieved through the following steps:

[0087] a) Each participant P i Update counter count i , and use the pseudo-random function F(·) and the shared key held to calculate the secret sharing of the random number k. Participant P1 calculates k1=F(k 13 + count1) and k2 = F(k 12 + count1), participant P2 calculates k2=F(k 12 +coumt2) and k3=F(k 23 + count2), participant P3 calculates k1=F(k 13 + count3) and k3=F(k 23 + count3).

[0088] b) Each participant Pi The signature parameter R components R1, R2, and R3 are calculated based on the secret sharing of the random number k held by each party. Participant P1 calculates R1 = k1·G and R2 = k2·G, participant P2 calculates R2 = k2·G and R3 = k3·G, and participant P3 calculates R1 = k1·G and R3 = k3·G. And participant P i Will hold R i ,R i+1 Send to participants

[0089] P i+1 ,P i+2 That is, participant P1 sends R1 and R2 to participants P2 and P3, and participant P2 sends R2 and R3 to participants

[0090] P3, P1, participant P3 sends R1, R3 to participants P1, P2.

[0091] c) After step b), each participant P i Two signature parameter components R1, R2, and R3 will be held, and the consistency of the signature parameter components will be determined. If each signature parameter component is consistent, it means that each participant has honestly executed the agreement, the signature parameter component is valid, and the signature parameter is calculated. Note that the first signature parameter r = R x (The value of the horizontal axis of R).

[0092] If there is inconsistency in the signature parameters, it means that there is a malicious party that is dishonestly executing the protocol and the signature parameters are invalid.

[0093] Termination of Agreement.

[0094] d) Each participant P i Update counter count i , and use the pseudo-random function F(·) and the shared key to calculate the secret sharing of the random number ρ. Where P1 calculates ρ1=F(k 13 + count1) and ρ2=F(k 12 + count1), P2 calculates ρ2 = F(k 12 + count2) and ρ3=F(k 23 + count2), P3 calculates ρ1=F(k 13 + count3) and ρ3=F(k 23 + count3).

[0095] e) Each participant P i Calculate the intermediate parameter α component α i =k i ρ i +k i ρi+1 +k i+1 ρ i Participant P1 calculates

[0096] α1=k1ρ1+k1ρ2+k2ρ1, participant P2 calculates α2=k2ρ2+k2ρ3+k3ρ2, participant P3 calculates

[0097] α3=k3ρ3+k3ρ1+k1ρ3. And the participant P i The weight α will be held i Send to P i-1 At this point, participant P1

[0098] Holds (α1, α2), participant P2 holds (α2, α3), and participant P3 holds (α1, α3).

[0099] f) Each participant P i The intermediate parameter α component α will be held i Sent to participant P i+1 That is, participant P1 sends α1 to participant P2, participant P2 sends α2 to participant P3, and participant P3 sends α3 to participant P1. So far, each participant P i Hold the intermediate parameter α components α1, α2, α3, and calculate the intermediate parameters And calculate α -1 modq.

[0100] g) Calculation by Party P1 Calculate the intermediate parameter β component

[0101] β1=h1ρ1+h1ρ2+h2ρ1, calculated by participant P2

[0102] Calculate the intermediate parameter β component β2=h2ρ2+h2ρ3+h3ρ2, participant P3 calculates

[0103] Calculate the intermediate parameter β component β3=h3ρ3+h3ρ1+h1ρ3. And the participant P i The component β i Send to P i-1 At this point, participant P1 holds (β1, β2), participant P2 holds (β2, β3), and participant P3 holds (β1, β3). Among them, ρ=ρ1+ρ2+ρ3;

[0104] h) Participant P1 calculates the signature parameter component s1 = α -1 β1,s2=α -1 β2, the signature parameter component calculated by participant P2

[0105] s2=α -1 β2,s3=α -1 β3, participant P3 calculates signature parameter component s1 = α -1 β1,s3=α -1 β3, and

[0106] Participant P i Will hold the signature parameter component s i Sent to participant P i+1 , that is, participant P1 sends s1 to participant

[0107] P2, participant P2 sends s2, to participant P3, and participant P3 sends s3 to participant P1. i Hold the signature parameter components s1, s2, s3 and calculate the second signature parameter The three parties collaborate to generate the first complete signature {r,s}.

[0108] In one embodiment, the two-party collaborative key generation step includes: if one party is offline or corrupted by a malicious adversary, converting the replicated secret sharing into a two-party additive secret sharing. Assume that party P3 is offline. The two signing parties jointly execute the two-party collaborative key generation protocol to jointly generate a publicly releasable signature verification public key Q′ (second signature verification public key). The two signing parties are denoted as P1 and P2, and they respectively hold the signature private key components x1 and x2. See Figure 3 , which can be achieved through the following steps:

[0109] a) Participants P1 and P2 are Randomly select an integer x′1, x′2 as your own signature private key component and calculate the intermediate variable Q′ i =x′ i G and zero-knowledge proof and will Sent to the other party. Where G is a base point of the elliptic curve with an order of integer n. is used to generate x′ i Evidence for a statement Q′ i =x′ i Zero-knowledge proof of G is a set of integers.

[0110] b) Participants P1 and P2 receive the other party's and After that, verify the zero-knowledge proof one by one and Is it legal? If the verification is successful, calculate Q′=Q′1+Q′2, and make Q′ public as the second signature verification public key.

[0111] In one embodiment, the two-party collaborative signature step includes: two signing parties jointly execute a two-party collaborative signature generation protocol, and use an ideal function Interactively calculate the intermediate variables of the second complete signature to obtain the second complete signature See Figure 4 , which can be achieved through the following steps:

[0112] a) Participants P1 and P2 are Randomly select two integers (k1, ρ1) and (k2, ρ2), calculate the intermediate variables R1 = k1·G, R2 = k2·G, and generate a zero-knowledge proof

[0113] and will Send to another party.

[0114] b) Participants P1 and P2 receive the other party's After that, verify the zero-knowledge proof one by one and Is it legal? If the verification is successful, calculate the intermediate variable R=R1+R2 and the third signature parameter (The value of the horizontal axis of R).

[0115] c) Participants P1 and P2 input the private key components x1 and x2 and random integers ρ1 and ρ2 into the ideal function respectively Ideal function

[0116] The first calculation results τ1 and τ2 are output and sent to participants P1 and P2 respectively. Participant P1 calculates the intermediate parameter α component α1 = ρ1·k1 + τ1modq, and participant P2 calculates the intermediate parameter α component α2 = ρ2·k2 + τ2modq.

[0117] Among them, the ideal function Defined as f((a1,b1),...,(a n ,b n ))=(c1,...,c n ),and

[0118]

[0119] d) Participants P1 and P2 calculate the intermediate variables separately And ρ i ,h iEnter the ideal function Ideal function The second calculation results γ1 and γ2 are output and sent to participants P1 and P2 respectively. Participant P1 calculates the intermediate parameter β component β1 = ρ1·h1 + γ1modq, and participant P2 calculates the intermediate parameter β component β2 = ρ2·h2 + γ2modq.

[0120] e) Participants P1 and P2 send their intermediate parameter components (α1, β1) and (α2, β2) to each other to calculate the fourth signature parameter At this point, the three parties collaborate to generate the second complete signature

[0121] In general, the present invention has the following advantages and beneficial effects compared with the prior art:

[0122] 1. Flexibility. With the development of collaborative signature technology, meeting the security and performance requirements in specific business scenarios faces some challenges. This solution uses replicated secret sharing technology to enable a complete digital signature to be generated in a three-party environment with only two online parties, ensuring the flexibility and robustness of digital signatures.

[0123] 2. Security. Security dependency directly relies on the security of multi-prover zero-knowledge proof and secure multi-party computing protocol, which can meet the correctness and privacy of three-party collaborative signature.

[0124] 3. High performance: Optimizes the sharing of secret components in the three-party signature, reduces the amount of communication between participants, improves communication efficiency, and can adopt parallel strategies to improve system performance.

[0125] Example 2

[0126] Based on the same inventive concept, this embodiment discloses a three-party collaborative ECDSA signature generation system, see Figure 5 ,include:

[0127] The three-party collaborative key generation module 101 is used for the three parties to generate a secret sharing of the signature private key using a pseudo-random function and a shared key, and to jointly generate a publicly released signature verification public key based on the cryptographic sharing of the signature private keys held by each party;

[0128] The three-party collaborative signature module 102 is used for the three parties to use the replicated secret sharing technology to recover the secret value to be shared, and interactively calculate the intermediate variables of the complete signature to obtain the complete signature value;

[0129] Two-party collaborative key generation module 103, which is used to convert replicated secret sharing into two-party additive secret sharing when one participant is offline or corrupted by a malicious adversary, and the other two participants jointly generate a publicly released signature verification public key;

[0130] The two-party collaborative signature module 104 is used for the other two participants to interactively calculate the intermediate variables of the pre-signature to obtain the pre-signature value.

[0131] Among them, the three-party collaborative key generation module 101 is used to execute the three-party collaborative key generation steps or protocol, the three-party collaborative signature module 102 is used to execute the three-party collaborative signature steps or protocol, the two-party collaborative key generation module 103 is used to execute the two-party collaborative key generation steps or protocol, and the two-party collaborative signature module 104 is used to execute the two-party collaborative signature steps or protocol.

[0132] Since the system described in Example 2 of the present invention is the system used to implement the three-party collaborative ECDSA signature generation method described in Example 1 of the present invention, those skilled in the art will be able to understand the specific structure and variations of this system based on the method described in Example 1 of the present invention, and therefore will not be described in detail here. All systems used in the method described in Example 1 of the present invention fall within the scope of protection of the present invention.

[0133] Example 3

[0134] Based on the same inventive concept, the present invention further provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method described in the first embodiment is implemented.

[0135] Since the computer-readable storage medium described in Example 3 of the present invention is the computer-readable storage medium used to implement the three-party collaborative ECDSA signature generation method described in Example 1 of the present invention, the specific structure and variations of the computer-readable storage medium are readily understood by those skilled in the art based on the method described in Example 1 of the present invention, and thus will not be further described here. All computer-readable storage media used in the method of Example 1 of the present invention fall within the scope of protection of the present invention.

[0136] Example 4

[0137] The present invention also provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in the first embodiment when executing the program.

[0138] Since the computer device described in Example 4 of the present invention is the computer device used to implement the three-party collaborative ECDSA signature generation method described in Example 1 of the present invention, the specific structure and variations of the computer device are readily understood by those skilled in the art based on the method described in Example 1 of the present invention, and therefore will not be described in detail here. All computer devices used in the method described in Example 1 of the present invention fall within the scope of protection of the present invention.

[0139] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0140] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0141] Although preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they are aware of the basic inventive concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention. Obviously, those skilled in the art may make various changes and modifications to the embodiments of the present invention without departing from the spirit and scope of the embodiments of the present invention. Thus, the present invention is intended to include such changes and modifications to the embodiments of the present invention if they fall within the scope of the claims and their equivalents.

Claims

1. A three-party collaborative ECDSA signature generation method, characterized in that: include: The three parties use a pseudo-random function and a shared key to generate a secret share of the signature private key, and jointly generate a first signature verification public key based on the cryptographic sharing of the signature private key held by each party; The three parties use the replicated secret sharing technique to recover the secret value to be shared, interactively calculate the intermediate variable of the first complete signature, and obtain the first complete signature based on the message to be signed, the first signature verification public key, and the intermediate variable of the first complete signature; When one participant is offline or corrupted by a malicious adversary, the replicated secret sharing is converted into a two-party additive secret sharing, and the other two participants jointly generate a second signature verification public key; The other two participants interactively calculate the intermediate variable of the second complete signature, and obtain the second complete signature based on the message to be signed, the second signature verification public key and the intermediate variable of the second complete signature.

2. The three-party collaborative ECDSA signature generation method according to claim 1, characterized in that: The three parties use a pseudo-random function and a shared key to generate a secret share of the signature private key, and based on the cryptographic sharing of the signature private key held by each party, jointly generate a first signature verification public key, including: Each participant initializes a counter and generates their own shared key based on the initialization ideal function; Each participant uses a pseudo-random function and the shared key they hold to calculate the secret share of the signature private key; Each participant calculates the public key component based on the cryptographic sharing of the signature private key they hold, and sends the calculated public key component to other participants; Each participant determines whether the public key component is valid based on whether the public key component calculated by itself is consistent with the received component. If each public key component is consistent, it indicates that each participant has honestly executed the protocol and the public key component is valid. At this time, the public signature verification public key is calculated based on each public key component. If there is an inconsistency in the public key components, it means that there is a malicious participant who dishonestly executes the protocol, the public key component is invalid, and the protocol terminates.

3. The three-party collaborative ECDSA signature generation method according to claim 1, characterized in that: The three parties use the replicated secret sharing technique to recover the secret value to be shared, interactively calculate the intermediate variable of the first complete signature, and obtain the first complete signature based on the message to be signed, the first signature verification public key, and the intermediate variable of the first complete signature, including: Each participant updates the counter and uses the pseudo-random function and the shared key to calculate the secret share of the random number k; Each participant calculates the signature parameter component based on the secret sharing of the random number k held by each participant, and sends the signature parameter component calculated by itself to other participants. Each participant determines the validity of the signature parameter component based on whether the signature parameter component calculated by itself is consistent with the received signature parameter component. If each signature parameter component is consistent, it means that each participant has honestly executed the protocol, the signature parameter component is valid, and the first signature parameter is calculated based on the signature parameter component. If there is a signature parameter inconsistency, it means that a malicious participant has dishonestly executed the protocol, the signature parameter component is invalid, and the protocol terminates; Each participant updates the counter and uses the pseudo-random function and the shared key to calculate the secret share of the random number ρ; Each participant calculates the intermediate parameter α component based on the secret sharing of the shared key and random number ρ held by each party; Each participant sends the intermediate parameter α component to other participants, and the intermediate parameter is calculated based on the intermediate parameter α component; Each participant calculates the intermediate parameter β component based on the first signature parameter, the hash function, and the secret sharing of the signature private key held by each participant, and sends the intermediate parameter β component calculated by itself to other participants; Each participant calculates a signature parameter component based on the intermediate parameter β component, and sends the calculated signature parameter component to other participants. The second signature parameter is calculated based on all signature parameter components. The first signature parameter and the second signature parameter constitute the three-party collaborative generation of the first complete signature.

4. The three-party collaborative ECDSA signature generation method according to claim 1, characterized in that: When one participant is offline or corrupted by a malicious adversary, the replicated secret sharing is converted to a two-party additive secret sharing, and the other two participants jointly generate a second signature verification public key, including: The other two participants each randomly select an integer as their own signature private key component, calculate the public key component and zero-knowledge proof based on the selected integer, and send the public key component and zero-knowledge proof calculated based on the selected integer to the other participant; Each participant verifies whether the received zero-knowledge proof is legitimate one by one; if the verification is successful, the public second signature verification public key is calculated based on the public key component calculated based on the selected integer.

5. The three-party collaborative ECDSA signature generation method according to claim 1, characterized in that: The other two participants interactively calculate the intermediate variable of the second complete signature, and obtain the second complete signature based on the message to be signed, the second signature verification public key, and the intermediate variable of the second complete signature, including: Each of the two participants randomly selects two integers, calculates the signature parameter components, and generates a zero-knowledge proof. The generated signature parameter components and the zero-knowledge integer are then sent to the other participant. The two participants verify the legitimacy of the received zero-knowledge proof one by one; if the verification is successful, the third signature parameter is calculated based on the signature parameter components; The two participants use the ideal function to obtain the first calculation result based on the signature private key component they hold and the random integer they choose. The two participants calculate the intermediate parameter α component based on the first calculation result. The ideal function Defined as f((a1,b1),...,(a n ,b n ))=(c1,...,c n ),and Among them, (a1,b1), (a n ,b n ) is an ideal function The input parameters, (c1,...,c n ) is an ideal function The output result; The two participants respectively use the ideal function to obtain a second calculation result based on the selected random number and the calculated intermediate variable, and the two participants respectively calculate the intermediate parameter β component based on the second calculation result. The two participants send the intermediate parameter α component and the intermediate parameter β component they hold to each other, calculate the fourth signature parameter, and the third signature parameter and the fourth signature parameter constitute a second complete signature.

6. The three-party collaborative ECDSA signature generation method according to claim 2, characterized in that: The pseudo-random function is F(·). Each participant uses the pseudo-random function and the shared key they hold to calculate the secret sharing of the signature private key, including: The first participant P1 calculates x1=F(k 13 + count1) and x2 = F(k 12 + count1), the second participant P2 calculates x2 = F(k 12 + count2) and x3 = F(k 23 + count2), the third party P3 calculates x1 = F(k 13 + count3) and x3 = F(k 23 +count3), where x1 and x2 are the secret shares of the signature private key calculated by the first participant, k 13 and k 12 is the shared key held by the first participant, count1 is the counter corresponding to the first participant, k 12 and k 23 is the shared key held by the second participant, count2 is the counter corresponding to the second participant, x2 and x3 are the secret sharing of the signature private key calculated by the second participant, count3 is the counter corresponding to the third participant, k 13 and k 23 is the shared key held by the third party, and x1 and x3 are the secret sharing of the signature private key calculated by the third party.

7. The three-party collaborative ECDSA signature generation method according to claim 3, characterized in that: Each participant calculates the intermediate parameter β component based on the first signature parameter, the hash function, and the secret sharing of the signature private key held by each participant, and sends the intermediate parameter β component calculated by itself to other participants, including: The first party P1 calculates Then calculate the intermediate parameter β component β1 = g1ρ1 + h1ρ2 + h2ρ1, where h1 and h2 are the intermediate parameters calculated by the first participant, ρ1 and ρ2 are the secret shares of the random number ρ calculated by the first participant; H(·) is a cryptographic function derived from the cryptographic hash function, m is the message to be signed, and x1 and x2 are the secret shares of the signing private key calculated by the first participant; The second party P2 calculates Calculate the intermediate parameter β component β2 = h2ρ2 + h2ρ3 + h3ρ2, where h3 and h2 are the intermediate parameters calculated by the second participant, ρ2 and ρ3 are the secret sharing of the random number ρ calculated by the second participant, and x3 and x2 are the secret sharing of the signature private key calculated by the second participant; Third-party P3 calculation Calculate the intermediate parameter β component β3 = h3ρ3 + h3ρ1 + h1ρ3, where h1 and h3 are the intermediate parameters calculated by the third party, ρ3 and ρ1 are the secret sharing of the random number ρ calculated by the third party; x1 and x3 are the secret sharing of the signature private key calculated by the third party; The first participant will hold the intermediate parameter β component β1 and send it to the second and third participants. The second participant will hold the intermediate parameter β component β2 and send it to the first and third participants. The third participant will hold the intermediate parameter β component β3 and send it to the first and second participants. Then the first participant P1 holds (β1, β2), the second participant P2 holds (β2, β3), and the third participant P3 holds (β1, β3).

8. A three-party collaborative ECDSA signature generation system, characterized in that: include: A three-party collaborative key generation module is used by the three parties to generate a secret sharing of the signature private key using a pseudo-random function and a shared key, and to jointly generate a first signature verification public key based on the cryptographic sharing of the signature private key held by each party; A three-party collaborative signature module, which is used by the three parties to recover the secret value to be shared using the replicated secret sharing technique, interactively calculate the intermediate variables of the complete signature, and obtain the first complete signature based on the message to be signed, the first signature verification public key, and the intermediate variables of the first complete signature; A two-party collaborative key generation module, which is used to convert replicated secret sharing into two-party additive secret sharing when one participant is offline or corrupted by a malicious adversary, and the other two participants jointly generate a second signature verification public key; The two-party collaborative signature module is used for the other two participants to interactively calculate the intermediate variables of the second complete signature, and obtain the second complete signature based on the message to be signed, the second signature verification public key and the intermediate variables of the second complete signature.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the three-party collaborative ECDSA signature generation method according to any one of claims 1 to 7 is implemented.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the three-party collaborative ECDSA signature generation method according to any one of claims 1 to 7 is implemented.

Images