Three-party collaborative ECDSA signature generation method and system

Through the replication secret sharing technology, private key leakage and complexity problems in ECDSA signature technology are solved, and safe, reliable and fast digital signature generation in three-party environments are achieved, flexibility and robustness are improved, and communication volume is reduced, and the number of communications is improved. System performance.

CN119276507AActive Publication Date: 2025-01-07WUHAN UNIV
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
CN202411338809.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-09-25
Publication Date
2025-01-07
Estimated Expiration
2044-09-25

AI Technical Summary

Technical Problem

ECDSA signature technology faces problems of private key leakage and complexity, security, reliability and performance balance in practical applications, especially in the case of multiple parties participating, it is difficult to ensure safe, reliable and rapid generation of digital signatures.

Method used

Using the copy secret sharing technology, the three participants generate secret sharing of the signed private key through pseudo-random functions and shared keys, and when one party is disconnected or commits evil, it is converted into additional secret sharing between the two parties to ensure that any two participants are Secret values ​​can be restored and a complete digital signature can be generated.

Benefits of technology

It realizes that only two parties can generate complete digital signatures online in a three-party environment, which improves the flexibility and robustness of digital signatures, meets the balance of security and performance, and reduces the communication between participants. , improves system performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119276507A_ABST
    Figure CN119276507A_ABST
Patent Text Reader

Abstract

The invention discloses a three-party collaborative ECDSA signature generation method and system, and the method comprises the steps: three-party collaborative key generation, three-party collaborative signature, two-party collaborative key generation and two-party collaborative signating.According to the three-party collaborative ECDSA signature generation method and system, the situation that one party is offline or dislike can be tolerated, and any two participants can recover a secret value. Under the normal condition, the three parties share the collaborative signature based on the copied secret, and when one party is offline, the other two parties execute the collaborative signature protocol of the two parties to generate a complete digital signature. The security and performance requirements of the collaborative signature technology are fully balanced, and it is ensured that the digital signature is safely, reliably and rapidly generated in a three-party environment. The method has the advantages of high security, high flexibility, high performance and the like, and can be applied to any application scene supporting secure multi-party computing.
Need to check novelty before this filing date? Find Prior Art

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 that uses elliptic curve cryptography to implement digital signatures. It provides a secure and efficient digital signature method based on the mathematical properties of elliptic curves. Digital signature technology is widely used in fields such as cryptocurrency, digital certificates, and secure communications. Similar to traditional signatures, it simulates the function of paper signatures or seals through specific cryptographic algorithms to ensure the integrity, authenticity, and non-repudiation of digital resources. ECDSA signature technology is safe in theory, but it may face some threats and attacks in practical applications. The most serious security threat is the leakage of private keys. If the private key is leaked, hackers or attackers can use the private key to generate valid signatures and impersonate legitimate users to conduct fraudulent activities. Therefore, it is crucial to protect the security of private keys.

[0003] Collaborative signature technology allows multiple parties to jointly generate keys, preventing any single entity or a small number of colluders from obtaining the complete private key without permission. Multiple signers jointly complete the signature to ensure that multiple parties agree and authorize the content of the signature, preventing a single entity from abusing the signing authority. This technology is very useful in scenarios that require the participation and consent of multiple parties, such as multi-party contracts, multi-party authorization, etc. However, collaborative signature technology may also increase complexity and computational costs. Existing technologies cannot guarantee a balance in security, reliability, and performance when applying these technologies. Summary of the invention

[0004] The present invention proposes a three-party collaborative ECDSA signature generation method and system based on replicated secret sharing, which can tolerate the situation where one party is offline or acts maliciously (is malicious or corrupted by a malicious adversary), and any two participating parties can restore the secret value. When one party is offline, the remaining two parties still hold all shares for secret sharing, thereby collaboratively generating a complete digital signature. The security requirements and performance requirements of collaborative signature technology are fully balanced to ensure safe, reliable and fast generation of digital signatures in a three-party environment.

[0005] The technical solution adopted by 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 share of the signature private key held by each party;

[0008] The three parties use the replicated secret sharing technology to recover the secret value to be shared, calculate the intermediate variable of the complete signature through interaction, 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, three parties generate a secret share of a signature private key using a pseudo-random 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 password of the signature private key held by each participant, 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 implementation, 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 a 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 party, 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 there is a malicious participant who dishonestly executes 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 calculates the intermediate parameter 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, calculates a second signature parameter based on all signature parameter components, and the first signature parameter and the second signature parameter constitute a three-party collaborative generation of a first complete signature.

[0024] In one embodiment, 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, 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, a public second signature verification public key is calculated based on the public key component calculated based on the selected integer.

[0027] In one implementation, 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:

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

[0029] The two parties 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 of

[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 the fourth signature parameter, and construct the pre-signature value from the third signature parameter and the fourth signature parameter.

[0033] In one embodiment, the pseudo-random function is F(·), and each participant uses the pseudo-random 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 sharing of the random number ρ calculated by the first participant; H(·) is the cryptographic function derived from the cryptographic hash function, m is the message to be signed, and x1 and x2 are the secret sharing of the signature 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; 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 send the intermediate parameter β component β1 to the second and third participants, the second participant will send the intermediate parameter β component β2 to the first and third participants, and the third participant will send the intermediate parameter β component β3 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, including:

[0041] A three-party collaborative key generation module, which is used by the three parties to generate a secret sharing of a 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 password sharing of the signature private key held by each party;

[0042] A three-party collaborative signature module, which is used for the three parties to use the replicated secret sharing technology to recover the secret value to be shared, calculate the intermediate variable of the complete signature through interaction, 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;

[0043] Two-party collaborative key generation module, 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, the three-party collaborative ECDSA signature generation method described in the first aspect is implemented.

[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 executable on the processor, wherein 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] The present invention provides a three-party collaborative ECDSA signature generation method, which uses the replication secret sharing technology so that only any two parties in a three-party environment need to be online to generate a complete digital signature, thereby ensuring the flexibility and robustness of the digital signature; relying on the security of multi-certifier zero-knowledge proof and secure multi-party computing protocol, the correctness and privacy of the three-party collaborative signature can be met. The sharing of the secret component in the three-party signature is optimized, which reduces the communication volume between the participants and improves the communication efficiency. At the same time, a parallel strategy can be used to improve the 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 drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. 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 creative work.

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

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

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

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

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

[0055] Although collaborative signature techniques are very useful in scenarios where multiple parties need to participate and agree, they may also increase complexity and computational cost because multiple signature parts need to be managed and the security of the signatures is not compromised when they are merged. Therefore, when applying these techniques, the balance between security, reliability, and performance needs to be carefully considered.

[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, which can tolerate the situation where one party is offline or acts maliciously, and any two participating parties can restore the secret value. When one party is offline, the remaining two parties still hold all shares for secret sharing, thereby collaboratively generating a complete digital signature. Fully balance the security requirements and performance requirements of collaborative signature technology to ensure safe, reliable and fast generation of digital signatures in a three-party environment.

[0057] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are 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 creative work are within the scope of protection of the present invention.

[0058] Embodiment 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 technology 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 of the present invention are selected to be 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 share.

[0075] F(·): pseudo-random function PRF.

[0076] An algorithm for generating zero-knowledge proofs of 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 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 publishable signature verification public key Q (the first signature verification public key). Each signing participant is denoted 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 participating party 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, Q2 are sent to participants P2, P3, participant P2 sends Q2, Q3 to participants P3, P1, and participant P3 sends Q1, Q3 to participants P1, 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 protocol, 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 who dishonestly executes 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 a distributed signature generation protocol, use a replicated secret sharing technique to recover the secret value to be shared, and use an 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 protocol, the signature parameter component is valid, and the signature parameter is calculated. Let 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 held 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. i Hold the intermediate parameter α components α1, α2, α3, 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, and participant P3 calculates Calculate the intermediate parameter β component β3 = h3ρ3 + h3ρ1 + h1ρ3. And the participant P i The weight held i Send to P i-1 . So far, 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 party 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, the replicated secret sharing is converted into a two-party additive secret sharing. Assume that the participant P3 is offline. The two signing participants execute the two-party collaborative key generation protocol together to jointly generate a publicly releasable signature verification public key Q′ (second signature verification public key). The two signing participants are denoted as P1 and P2 and hold the signature private key components x1 and x2 respectively. See Figure 3 , which can be achieved through the following steps:

[0109] a) Participants P1 and P2 respectively Randomly select an integer x′1, x′2 as the 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, Q′=Q′1+Q′2 is calculated, and Q′ is published as the second signature verification public key.

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

[0112] a) Participants P1 and P2 respectively 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 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 the participants P1 and P2 respectively. The participant P1 calculates the intermediate parameter α component α1=ρ1·k1+τ1modq, and the 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 i Enter the ideal function Ideal function The second calculation results γ1 and γ2 are output and sent to the participants P1 and P2 respectively. The participant P1 calculates the intermediate parameter β component β1=ρ1·h1+γ1modq, and the 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, there are some challenges in meeting the security and performance requirements in specific business scenarios. This solution uses replicated secret sharing technology, so that in a three-party environment, only any two parties need to be online to generate a complete digital signature, ensuring the flexibility and robustness of the digital signature.

[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 the participants, improves communication efficiency, and can adopt parallel strategies to improve system performance.

[0125] Embodiment 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 a 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 password sharing of the signature private key 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, 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 variable 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 introduced in the second embodiment of the present invention is a system used to implement the three-party collaborative ECDSA signature generation method in the first embodiment of the present invention, based on the method introduced in the first embodiment of the present invention, those skilled in the art can understand the specific structure and deformation of the system, so it is not repeated here. All systems used in the method in the first embodiment of the present invention belong to the scope of protection of the present invention.

[0133] Embodiment 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 introduced in the third embodiment of the present invention is the computer-readable storage medium used to implement the three-party collaborative ECDSA signature generation method in the first embodiment of the present invention, based on the method introduced in the first embodiment of the present invention, those skilled in the art can understand the specific structure and deformation of the computer-readable storage medium, so it is not repeated here. All computer-readable storage media used in the method of the first embodiment of the present invention belong to the scope of protection of the present invention.

[0136] Embodiment 4

[0137] The present invention also provides a computer device, including 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 Embodiment 1 when executing the program.

[0138] Since the computer device introduced in the fourth embodiment of the present invention is a computer device used to implement the three-party collaborative ECDSA signature generation method in the first embodiment of the present invention, based on the method introduced in the first embodiment of the present invention, the person skilled in the art can understand the specific structure and deformation of the computer device, so it is not repeated here. All computer devices used in the method of the first embodiment of the present invention belong to the scope of protection of the present invention.

[0139] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, 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 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 flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, 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 flowchart and / or block diagram. 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, additional changes and modifications may be made to these embodiments by those skilled in the art once the basic creative concepts are known. 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, if these modifications and variations of the embodiments of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

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 share of the signature private key held by each party; The three parties use the replicated secret sharing technology to recover the secret value to be shared, calculate the intermediate variable of the first complete signature through interaction, 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 jointly generate a first signature verification public key based on the password sharing of the signature private key held by each party, 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 password of the signature private key held by each participant, 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 technology to recover the secret value to be shared, calculate the intermediate variable of the first complete signature through interaction, 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 a 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 party, 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 there is a malicious participant who dishonestly executes 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 calculates the intermediate parameter 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, calculates a second signature parameter based on all signature parameter components, and the first signature parameter and the second signature parameter constitute a three-party collaborative generation of a 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 into 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, a 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: The two participants each randomly select two integers, calculate the signature parameter components, and generate a zero-knowledge proof, and then send the generated signature parameter components and the zero-knowledge integers to the other party. The two parties 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 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 of 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 as claimed in claim 2, characterized in that: The pseudo-random function is F(·), and each participant uses the pseudo-random function and the shared key held 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 as claimed in claim 3 is 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 sharing of the random number ρ calculated by the first participant; H(·) is the cryptographic function derived from the cryptographic hash function, m is the message to be signed, and x1 and x2 are the secret sharing of the signature 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; 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 send the intermediate parameter β component β1 to the second and third participants, the second participant will send the intermediate parameter β component β2 to the first and third participants, and the third participant will send the intermediate parameter β component β3 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, which is used by the three parties to generate a secret sharing of a 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 password sharing of the signature private key held by each party; A three-party collaborative signature module, which is used for the three parties to use the replicated secret sharing technology to recover the secret value to be shared, calculate the intermediate variable of the complete signature through interaction, 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; Two-party collaborative key generation module, 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 as described in 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, characterized in that: When the processor executes the program, the three-party collaborative ECDSA signature generation method as described in any one of claims 1 to 7 is implemented.

Citation Information

Patent Citations

  • ECDSA digital signature method based on two-party collaboration

    CN109639439A

  • Anti-malicious enemy SM2 two-party adapter signature generation method and device

    CN115473635A

  • Secure fragment extension method and device for protecting private data

    CN118133330A

  • System and method for deterministic signing of a message using a multi-party computation (MPC) process

    US20200153640A1

  • A method for providing a digital signature to a message

    US20220150076A1