A two-party collaborative signature method and system based on combined ECDSA

Abstract

The present application belongs to the field of cryptography, and provides a two-party cooperative signature method and system based on combined ECDSA. The method comprises the following steps: a sender sends a commitment non-interactive zero-knowledge proof instruction to an ideal commitment non-interactive zero-knowledge proof function to generate a non-interactive zero-knowledge proof and make a commitment; a receiver receives the commitment of the proof, calculates a zero-knowledge proof instruction and sends it to an ideal zero-knowledge proof function to generate a zero-knowledge proof; the sender receives the zero-knowledge proof and verifies its correctness, if the correctness is incorrect, the protocol is aborted, otherwise the protocol is continued; the sender sends an instruction for opening the commitment of the zero-knowledge proof to an ideal commitment function to open the commitment; the receiver receives the zero-knowledge proof of the open commitment and verifies its correctness, if the correctness is incorrect, the protocol is aborted, otherwise the protocol is continued; the receiver receives a message to be signed, calculates a signature share and sends it to the sender; and the sender verifies the signature by using a signature verification public key.

Description

Technical Field

[0001] This invention belongs to the field of cryptography, and in particular relates to a two-party collaborative signature method and system based on combined ECDSA. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] The key is the core information of a cryptographic algorithm, and its generation, distribution, storage, and destruction mechanisms require specialized design and management. Traditional signature algorithms rely entirely on a single user for their private key, ensuring the non-repudiation of the signature operation but also facing security risks such as key loss, abuse of privileges, or control by attackers. Two-party collaborative signatures share the key information with two users for decentralized storage, allowing the signature function to be completed collaboratively by the two users. Even if a malicious adversary steals a single user's key, it is difficult for them to perform the signature operation, thus improving the security of the signature private key.

[0004] The ECDSA (Elliptic Curve Digital Signature Algorithm) is based on an elliptic curve structure and has advantages such as fast signing speed and small space occupation. It is an international standard for digital signature algorithms and is widely used in various application systems. However, the private key of the ECDSA signature algorithm is completely controlled by a single user, which makes it difficult to avoid security risks such as key loss, abuse of authority, or the user being controlled by an attacker due to a single user having complete control over the signing authority.

[0005] Currently, two-party ECDSA signature methods require complex secure multi-party computation techniques to achieve multiplication operations with shared secrets, and also require expensive zero-knowledge proofs to resist malicious adversaries, resulting in low application efficiency and making distributed upgrades to existing ECDSA signature systems less than ideal. Summary of the Invention

[0006] To address the technical problems existing in the background art, the present invention provides a two-party collaborative signature method and system based on combined ECDSA, which can improve the security of ECDSA signature private keys.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] The first aspect of the present invention provides a two-party collaborative signature method based on combined ECDSA.

[0009] A two-party collaborative signature method based on combined ECDSA, comprising:

[0010] The sender sends the instruction to commit to non-interactive zero-knowledge proof to the ideal commitment non-interactive zero-knowledge proof function to generate a non-interactive zero-knowledge proof and make a commitment.

[0011] The recipient receives the commitment to the proof, calculates the zero-knowledge proof instruction, and sends it to the ideal zero-knowledge proof function to generate the zero-knowledge proof.

[0012] The sender receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. The sender sends an instruction to the ideal commitment function to unlock the commitment containing the zero-knowledge proof.

[0013] The receiver receives the zero-knowledge proof to unravel the commitment and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. After receiving the message to be signed, the receiver uses the signing private key to calculate the signature share and sends the signature share to the sender.

[0014] The sender uses the signing public key to verify the signature. If the verification is successful, the signature value is output; otherwise, the protocol is terminated.

[0015] As one implementation, the signing private key and signing public key are generated by a two-party collaborative key generation protocol based on combined ECDSA signatures.

[0016] As one implementation method, the process of a two-party collaborative key generation protocol based on combined ECDSA signatures is as follows:

[0017] One party to the protocol runs the key generation algorithm for ECDSA signatures and sends the zero-knowledge proof instruction to the zero-knowledge proof generation function to generate the zero-knowledge proof;

[0018] The other party to the protocol receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the key generation algorithm for ECDSA signature is run, and the zero-knowledge proof instruction is sent to the zero-knowledge proof generation function to generate the zero-knowledge proof.

[0019] One party to the agreement receives a zero-knowledge proof and verifies its correctness. If it is incorrect, the agreement is terminated; otherwise, the agreement continues.

[0020] Both parties to the agreement calculate and store the private and public keys for signature verification.

[0021] As one implementation method, each session between the two parties to the protocol is assigned a unique session identifier.

[0022] As one implementation, the ideal commitment function is used for:

[0023] The receiving party sends a commitment instruction, records the sender, session identifier, and signing private key, and sends the commitment result to the other party; if the commitment instruction has been recorded before, it is ignored.

[0024] If the sender, session identifier, and signing private key have been previously recorded, the open commitment instruction sent by the receiving party to the other party of the protocol will be sent to the receiving party.

[0025] As one implementation method, the ideal zero-knowledge proof function is used for:

[0026] Upon receiving a zero-knowledge proof instruction from one party to the protocol: if the signing private key and the corresponding instruction parameters do not belong to a known hard relation or the session identifier has been used before, ignore the message; otherwise, send the zero-knowledge proof to the other party to the protocol.

[0027] As one implementation, the ideal commitment non-interactive zero-knowledge proof function is used for:

[0028] Upon receiving a commitment zero-knowledge proof instruction from one party to the protocol: if the signing private key and the corresponding instruction parameters do not belong to a known hard relation or the session identifier has been used before, ignore the message; otherwise, record the sender, session identifier, and signing private key, and send the commitment zero-knowledge proof to the other party to the protocol.

[0029] Upon receiving a commitment instruction from one party to open a zero-knowledge proof: if the sender, session identifier, and signing private key have been recorded, then send the zero-knowledge proof after the commitment to open it to the other party.

[0030] A second aspect of the present invention provides a two-party collaborative signature system based on combined ECDSA.

[0031] A two-party collaborative signature system based on combined ECDSA, comprising: a sender and a receiver communicating with each other;

[0032] The sender is configured to send the commitment non-interactive zero-knowledge proof instruction to the ideal commitment non-interactive zero-knowledge proof function to generate a non-interactive zero-knowledge proof and make a commitment.

[0033] The receiver is configured to receive a commitment to the proof, calculate the zero-knowledge proof instruction, and send it to the ideal zero-knowledge proof function to generate a zero-knowledge proof.

[0034] The sender is also configured to receive zero-knowledge proofs and verify their correctness. If the proof is incorrect, the protocol is terminated; otherwise, the protocol continues. The sender is also configured to send an instruction to open the commitment with zero-knowledge proof to the ideal commitment function to unlock the commitment.

[0035] The receiver is also configured to receive the zero-knowledge proof that unlocks the commitment and verify its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. The receiver is also configured to, after receiving the message to be signed, use the signing private key to calculate the signature share and send the signature share to the sender.

[0036] The sender uses the signature public key to verify the signature. If the verification is successful, it outputs the signature value; otherwise, it terminates the protocol.

[0037] As one implementation, the signing private key and signing public key are generated by a two-party collaborative key generation protocol based on combined ECDSA signatures.

[0038] As one implementation method, the process of a two-party collaborative key generation protocol based on combined ECDSA signatures is as follows:

[0039] One party to the protocol runs the key generation algorithm for ECDSA signatures and sends the zero-knowledge proof instruction to the zero-knowledge proof generation function to generate the zero-knowledge proof;

[0040] The other party to the protocol receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the key generation algorithm for ECDSA signature is run, and the zero-knowledge proof instruction is sent to the zero-knowledge proof generation function to generate the zero-knowledge proof.

[0041] One party to the agreement receives a zero-knowledge proof and verifies its correctness. If it is incorrect, the agreement is terminated; otherwise, the agreement continues.

[0042] Both parties to the agreement calculate and store the private and public keys for signature verification.

[0043] Compared with the prior art, the beneficial effects of the present invention are:

[0044] This invention utilizes the ideal commitment non-interactive zero-knowledge proof function, the ideal zero-knowledge proof function, and the ideal commitment function combined with ECDSA to generate non-interactive zero-knowledge proof, zero-knowledge proof, commitment decryption, and the private and public keys of the communicating parties, respectively. This improves the protocol security of the communicating parties. Moreover, when the receiver receives the message to be signed, it uses the signing private key to calculate the signature share and sends the signature share to the sender, who then uses the signing public key to verify the signature. It does not require complex MPC technology, and it simply and quickly realizes two-party collaborative signing, improving the security of the ECDSA signing private key.

[0045] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0046] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0047] Figure 1 This is a schematic diagram of the two-party collaborative signature method based on combined ECDSA according to an embodiment of the present invention. Detailed Implementation

[0048] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0049] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0050] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0051] Example 1

[0052] Symbol definition. In this invention, the symbol is defined as follows: Represent the set of natural numbers, for any Symbol 1 λ Let S represent a string of λ ones. For any finite set S, s←S means that an element s is randomly selected uniformly from S. Let G denote the elliptic curve group, and G denote the group. The point on the y-axis, k·G represents Perform a doubling operation on the number k and point G, R = (r x r y () represents a point R on an elliptic curve with x-coordinate r x and the ordinate r y The parties to the agreement are represented by P1 and P2, respectively.

[0053] Terminology Explanation:

[0054] Combined ECDSA signature schemes:

[0055] make G is an elliptic curve group of order q, and G is a group The base point, the publicly disclosed system parameters are H represents a hash function.

[0056] Construct the combined ECDSA signature Π = (KeyGen, Sign, Vrfy) as follows:

[0057] KeyGen(pp, 1) λ (Q, x): Input system parameters and security parameters for the key generation algorithm 1 λ Select random number Calculate Q1 = x1·G, Q2 = x2·G, Q add =Q2 + Q1, Q mul = x1·x2·G. Let the signing private key be x = (x1, x2), and the signature verification public key be Q = (Q add Q mul ).

[0058] Sign(x, m) → σ. The signature algorithm takes the signature private key x and the message value m as input and calculates the signature value as follows:

[0059] 1) Calculate the hash value of the message m′=H(m);

[0060] 2) Select random numbers Calculate the random point R = k·G = (r) on the elliptic curve group. x r y );

[0061] 3) Calculate r = r x mod q, if r = 0, then return 2); r represents the x-coordinate of the point R on the elliptic curve. x Perform modulo q operation;

[0062] 4) Calculate s′=k -1 Let (m′+r·x1)(m′+r·x2)mod q, let s=min{s′,Qs′}, and output the signature value σ=(r,s).

[0063] Vrfy(Q, m, σ) → 0 / 1. The signature verification algorithm takes the verification public key Q, the message m, and the signature value σ = (r, s) as input, and performs the verification operation as follows:

[0064] Calculate m′=H(m), (r′) x , r′ y ) = s -1 (m′ 2 ·G+r·m′·Q add +r 2 ·Q mul If r = r′ x The mod q function outputs 1 to indicate successful verification and 0 to indicate failed verification.

[0065] Combining ECDSA signatures can be viewed as a "product-like" combination of two ECDSA signatures, except that two dot multiplication and one dot addition operations are added during the key generation and signature verification stages. Table 1 shows a comparison of the various algorithms used in ECDSA signature schemes.

[0066] Table 1 Comparison of various algorithms for ECDSA signatures and combined ECDSA signatures

[0067]

[0068] Ideal Functionalities:

[0069] To construct a two-party collaborative signature based on combined ECDSA signatures, we first introduce three ideal features: ideal commitment features. Ideal zero-knowledge proof function And ideal commitment non-interactive zero-knowledge proof function

[0070] Ideal Commitment Function The definition is as follows:

[0071] Received P i The commitment instruction (commit, sid, x) sent for i∈{1,2} records (sid, i, x) and sends the commitment result (receipt, sid) to P. 3-i If the commitment instruction (commit, sid, *) has been previously logged, ignore this message.

[0072] Received P i The open commitment instruction (decommit, sid) sent for i∈{1,2} will be sent to P if (sid, i, x) has been recorded before. 3-i .

[0073] Ideal zero-knowledge proof function for difficult relation R The definition is as follows:

[0074] Received P i The zero-knowledge proof instruction (prove, sid, x, w) sent for i∈{1,2}: If If the sid has been used before, ignore the message; otherwise, send a zero-knowledge proof (proof, sid, x) to P. 3-i Where w is the instruction parameter.

[0075] For difficult relations R, use the ideal commitment function for non-interactive zero-knowledge proofs. The definition is as follows:

[0076] Received P i The commitment zero-knowledge proof instruction (com_prove, sid, x, w) sent for i∈{1,2}: if If sid has been used before, ignore the message. Otherwise, record (sid, i, x) and send the zero-knowledge proof (proof_receipt, sid) after the commitment to P. 3-i ;

[0077] Received P i The commitment instruction (decom_proof, sid) sent to P for opening the zero-knowledge proof for i∈{1,2}: If (sid, i, x) has already been recorded, then send the zero-knowledge proof (decom_proof, sfd, x) after opening the commitment to P. 3-i .

[0078] Two-party collaborative signature protocol based on combined ECDSA signatures:

[0079] Based on the three ideal functions mentioned above, a distributed design is carried out for the combined ECDSA to construct a two-party collaborative signature protocol. Specifically, the key generation algorithm and signature algorithm of the combined ECDSA signature scheme are designed in a distributed manner, while the signature verification algorithm remains unchanged.

[0080] Reference Figure 1 This embodiment provides a two-party collaborative signature method based on combined ECDSA, which specifically includes the following steps:

[0081] Step 1: The sender sends the commitment non-interactive zero-knowledge proof instruction to the ideal commitment non-interactive zero-knowledge proof function to generate a non-interactive zero-knowledge proof and make a commitment.

[0082] The ideal commitment non-interactive zero-knowledge proof function is used for:

[0083] Upon receiving a commitment zero-knowledge proof instruction from one party to the protocol: if the signing private key and the corresponding instruction parameters do not belong to a known hard relation or the session identifier has been used before, ignore the message; otherwise, record the sender, session identifier, and signing private key, and send the committed zero-knowledge proof to the other party to the protocol.

[0084] Upon receiving a commitment instruction from one party to open a zero-knowledge proof: if the sender, session identifier, and signing private key have been recorded, then send the zero-knowledge proof after the commitment to open it to the other party.

[0085] Step 2: The recipient receives the commitment to the proof, calculates the zero-knowledge proof instruction, and sends it to the ideal zero-knowledge proof function to generate the zero-knowledge proof.

[0086] The ideal zero-knowledge proof function is used for:

[0087] Upon receiving a zero-knowledge proof instruction from one party to the protocol: if the signing private key and the corresponding instruction parameters do not belong to a known hard relation or the session identifier has been used before, ignore the message; otherwise, send the zero-knowledge proof to the other party to the protocol.

[0088] Step 3: The sender receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. The sender sends the instruction to open the commitment of the zero-knowledge proof to the ideal commitment function to unlock the commitment.

[0089] Step 4: The receiver receives the zero-knowledge proof to unravel the commitment and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. After receiving the message to be signed, the receiver uses the signing private key to calculate the signature share and sends the signature share to the sender.

[0090] Step 5: The sender uses the signing public key to verify the signature. If the verification is successful, the signature value is output; otherwise, the protocol is terminated.

[0091] In the specific implementation process, based on the ideal commitment function Ideal zero-knowledge proof function And ideal commitment non-interactive zero-knowledge proof function A two-party collaborative signature protocol (ISign) based on a combined ECDSA signature scheme is presented. The specific protocol description is as follows:

[0092] ISign(sid, m) → σ. The collaborative signature protocol takes a collaborative key as input and generates a key and message m, along with a unique session identifier sid, which are calculated as follows:

[0093] (1) P1 selects a random number Calculate R1 = k1·G.P1 and send the commitment non-interactive zero-knowledge proof instruction (com-prove, sid||1, R1, k1) to... Generate non-interactive zero-knowledge proofs and commit to the proofs.

[0094] (2) P2 receives the commitment to the proof (proof-receipt, sid||1) and selects a random number. Calculate R² = k²·G, and send the zero-knowledge proof instruction (prove, sid||², R², k²) to... Generate zero-knowledge proofs.

[0095] (3) P1 receives the zero-knowledge proof (proof, sid||2, R2) and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. P1 sends the instruction to open the commitment to the zero-knowledge proof (decom-proof, sid||1) to... Unravel the promise.

[0096] (4) P2 receives the zero-knowledge proof (decom-proof, sid||1, R1) to unravel the commitment and verifies its correctness. If incorrect, the protocol is terminated; otherwise, the protocol continues. P2 calculates R = k2·R1 = (r x r y After receiving the message m to be signed, P2 calculates r = r x mod q, signature sharing P2 sends the signature sharing s2 to P1.

[0097] (5) P1 calculates the signature value as follows: P1 calculates R = k1·R2 = (r x r y Then, calculate r = r x mod q, final signature value And set s = min{s′, qs′}. P1 uses the signature verification public key Q to verify the signature σ = (r, s). If the verification is successful, the signature value σ = (r, s) is output; otherwise, the protocol is aborted.

[0098] In practice, the signing private key and signing public key are generated by a two-party collaborative key generation protocol based on combined ECDSA signatures.

[0099] The process of the two-party collaborative key generation protocol based on combined ECDSA signatures is as follows:

[0100] One party to the protocol runs the key generation algorithm for ECDSA signatures and sends the zero-knowledge proof instruction to the zero-knowledge proof generation function to generate the zero-knowledge proof;

[0101] The other party to the protocol receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the key generation algorithm for ECDSA signature is run, and the zero-knowledge proof instruction is sent to the zero-knowledge proof generation function to generate the zero-knowledge proof.

[0102] One party to the agreement receives a zero-knowledge proof and verifies its correctness. If it is incorrect, the agreement is terminated; otherwise, the agreement continues.

[0103] Both parties to the agreement calculate and store the private and public keys for signature verification.

[0104] For example:

[0105] Collaborative Key Generation Protocol:

[0106] Based on ideal zero-knowledge proof function Based on the ECDSA key generation algorithm, a two-party collaborative key generation protocol (IKeyGen) based on combined ECDSA signatures is presented. The specific protocol description is as follows:

[0107] IKeyGen(pp,1) λ ): Public parameters of the input system for the collaborative key generation protocol and safety parameter 1 λ The calculation is as follows:

[0108] (1) P1 runs the ECDSA signature key generation algorithm ECDSA.KeyGen(pp, 1) λ P1 sends the zero-knowledge proof instruction (prove, 1, Q1, x1) to (x1, Q1 = x1·G). Generate a zero-knowledge proof.

[0109] (2) P2 receives the zero-knowledge proof (proof, 1, Q1) and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, P2 runs the ECDSA signature key generation algorithm ECDSA.KeyGen(pp, 1) λ P2 sends the zero-knowledge proof instruction (prove, 2, Q2, x2) to (x2, Q2 = x2·G). Generate a zero-knowledge proof.

[0110] (3) P1 receives the zero-knowledge proof (proof, 2, Q2) and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues.

[0111] (4) Output: P1 calculates Q add =Q2 + Q1, Q mul =x1·Q2, Q = (Q add Q mul P2 calculates Q and stores (x1, Q). add =Q2 + Q1, Q mul =x2·Q1, Q = (Q add Q mul ), and store (x2, Q).

[0112] In practice, each session between the two parties to the agreement is assigned a unique session identifier.

[0113] The ideal commitment function is used for:

[0114] The receiving party sends a commitment instruction, records the sender, session identifier, and signing private key, and sends the commitment result to the other party; if the commitment instruction has been recorded before, it is ignored.

[0115] If the sender, session identifier, and signing private key have been previously recorded, the open commitment instruction sent by the receiving party to the other party of the protocol will be sent to the other party of the protocol.

[0116] Performance evaluation:

[0117] Combining ECDSA signatures can be viewed as a "product-like" combination of two ECDSA signatures, with the only difference being the addition of two dot multiplication and one dot addition operations during the key generation and verification phases. Although this adds a small number of operations, it significantly simplifies multi-party collaborative inversion and multiplication operations when designing two-party collaborative signature protocols, avoiding the use of complex secure multi-party computation techniques and expensive zero-knowledge proof techniques. Since the first three steps of the collaborative signature protocol are unrelated to the signature message, they can be performed offline by both parties. Upon receiving the message to be signed, both parties can use the information pre-computed offline to perform online signing.

[0118] To evaluate the performance of the proposed scheme, this invention implements an ECDSA signature scheme, a combined ECDSA (cECDSA) signature scheme, and a two-party collaborative signature (TP-cECDSA) scheme based on combined ECDSA on the standard elliptic curve NISTcurves NID.X9.62.prime256v1 using the OpenSSL library. The execution environment was: Intel Core i5 CPU 2.3GHz, 8GB RAM, macOS High Sierra 10.13.3 system.

[0119] Similar to existing distributed ECDSA algorithms, the computation process after receiving a message is considered an online operation, while the preprocessing of random numbers before receiving a message can be considered an offline operation. The running times of each algorithm are shown in Table 2.

[0120] Table 2 Comparison of computational efficiency of ECDSA, cECDSA and TP-cECDSA

[0121]

[0122] The symbol "—" indicates that the operation is not needed.

[0123] The following example illustrates the information exchange between the servers of two branches of a bank and the head office:

[0124] The sender (a branch of a bank's server) sends a commitment non-interactive zero-knowledge proof instruction to the ideal commitment non-interactive zero-knowledge proof function to generate a non-interactive zero-knowledge proof and make a commitment.

[0125] The receiving party (the server of a bank's headquarters) receives the commitment to the proof, calculates the zero-knowledge proof instruction, and sends it to the ideal zero-knowledge proof function to generate the zero-knowledge proof.

[0126] The sender (a branch of a bank's server) receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. The sender (a branch of a bank's server) sends the instruction to open the commitment of the zero-knowledge proof to the ideal commitment function to unlock the commitment.

[0127] The receiving party (the server of a bank's head office) receives the zero-knowledge proof to decrypt the commitment and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. After receiving the message to be signed (such as remittance information or transfer information), the receiving party (the server of a bank's head office) uses the signing private key to calculate the signature share and sends the signature share to the sending party (the server of a bank's branch).

[0128] The sender (a branch of a bank's server) uses the signature public key to verify the signature. If the verification is successful, the signature value is output; otherwise, the protocol is terminated.

[0129] Example 2

[0130] This embodiment provides a two-party collaborative signature system based on combined ECDSA, which includes a sender and a receiver communicating with each other;

[0131] The sender is configured to send the commitment non-interactive zero-knowledge proof instruction to the ideal commitment non-interactive zero-knowledge proof function to generate a non-interactive zero-knowledge proof and make a commitment.

[0132] The receiver is configured to receive a commitment to the proof, calculate the zero-knowledge proof instruction, and send it to the ideal zero-knowledge proof function to generate a zero-knowledge proof.

[0133] The sender is also configured to receive zero-knowledge proofs and verify their correctness. If the proof is incorrect, the protocol is terminated; otherwise, the protocol continues. The sender is also configured to send an instruction to open the commitment with zero-knowledge proof to the ideal commitment function to unlock the commitment.

[0134] The receiver is also configured to receive the zero-knowledge proof that unlocks the commitment and verify its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. The receiver is also configured to, after receiving the message to be signed, use the signing private key to calculate the signature share and send the signature share to the sender.

[0135] The sender uses the signature public key to verify the signature. If the verification is successful, it outputs the signature value; otherwise, it terminates the protocol.

[0136] As one implementation, the signing private key and signing public key are generated by a two-party collaborative key generation protocol based on combined ECDSA signatures.

[0137] As one implementation method, the process of a two-party collaborative key generation protocol based on combined ECDSA signatures is as follows:

[0138] One party to the protocol runs the key generation algorithm for ECDSA signatures and sends the zero-knowledge proof instruction to the zero-knowledge proof generation function to generate the zero-knowledge proof;

[0139] The other party to the protocol receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the key generation algorithm for ECDSA signature is run, and the zero-knowledge proof instruction is sent to the zero-knowledge proof generation function to generate the zero-knowledge proof.

[0140] One party to the agreement receives a zero-knowledge proof and verifies its correctness. If it is incorrect, the agreement is terminated; otherwise, the agreement continues.

[0141] Both parties to the agreement calculate and store the private and public keys for signature verification.

[0142] It should be noted that each module in this embodiment corresponds one-to-one with each step in Embodiment 1, and their specific implementation processes are the same, so they will not be repeated here.

[0143] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0144] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A two-party collaborative signature method based on combined ECDSA, characterized in that, include: The sender sends a commitment to a non-interactive zero-knowledge proof to the Ideal Commitment Non-Interactive Zero-Knowledge Proof Function to generate a non-interactive zero-knowledge proof and make a commitment; the Ideal Commitment Non-Interactive Zero-Knowledge Proof Function is used for: Upon receiving a commitment zero-knowledge proof instruction from one party to the protocol: if the signing private key and the corresponding instruction parameters do not belong to a known hard relation or the session identifier has been used before, ignore it; otherwise, record the sender, session identifier, and signing private key and send the commitment zero-knowledge proof to the other party to the protocol. Upon receiving a commitment instruction from one party to open a zero-knowledge proof: if the sender, session identifier, and signing private key have been recorded, then send the zero-knowledge proof after the commitment to open to the other party. The recipient receives the commitment to the proof, calculates the zero-knowledge proof instruction, and sends it to the ideal zero-knowledge proof function to generate the zero-knowledge proof. The sender receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. The sender sends an instruction to the ideal commitment function to unlock the commitment containing the zero-knowledge proof. The receiver receives the zero-knowledge proof to unravel the commitment and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. After receiving the message to be signed, the receiver uses the signing private key to calculate the signature share and sends the signature share to the sender. The sender uses the signing public key to verify the signature. If the verification is successful, the signature value is output; otherwise, the protocol is terminated. Constructing combined ECDSA signatures as follows: Key generation algorithm input system parameters and security parameters Select random number ,calculate , , Let the signing private key be The signature verification public key is ; The signature algorithm inputs the signature private key. and message value The signature value is calculated as follows: 1) Calculate the hash value of the message ; 2) Select random numbers Calculate random points on the elliptic curve group ; 3) Calculation ,if If so, then return 2); Represents the x-coordinate of a point R on an elliptic curve. Perform the model Operations; 4) Calculation ,make Output signature value ; : Signature verification algorithm input verification public key ,information and signature value The verification process is as follows: calculate , ;if Output 1 to indicate successful verification, otherwise output 0 to indicate failed verification; A two-party collaborative signature protocol based on a combined ECDSA signature scheme is presented. The specific agreement is described as follows: The collaborative signature protocol takes a collaborative key as input and generates a key and message as output. and a unique session identifier. The calculation is as follows: 1) Select random number ,calculate ; Will commit to non-interactive zero-knowledge proof instructions Send to Generate non-interactive zero-knowledge proofs and commit to the proofs; 2) Received commitment to the proof Select random number ,calculate Zero-knowledge proof instructions Send to Generate zero-knowledge proofs; 3) Accepting zero-knowledge proofs And verify its correctness; if it is incorrect, terminate the agreement; otherwise, continue the agreement. Instructions to enable commitments based on zero-knowledge proofs Send to Unravel the promise; 4) Received zero-knowledge proof to unravel the commitment And verify its correctness; if it is incorrect, terminate the agreement; otherwise, continue the agreement. calculate After receiving the message m to be signed, calculate Signature sharing ; Send the signature sharing s2 to ; 5) The signature value is calculated as follows: calculate Then, calculate Final signature value , and set ; Use signature verification public key Verify signature ; If verification is successful, output the signature value. Otherwise, the agreement will be terminated.

2. The two-party collaborative signature method based on combined ECDSA as described in claim 1, characterized in that, The signing private key and signing public key are generated by a two-party collaborative key generation protocol based on combined ECDSA signatures.

3. The two-party collaborative signature method based on combined ECDSA as described in claim 2, characterized in that, The process of a two-party collaborative key generation protocol based on combined ECDSA signatures is as follows: One party to the protocol runs the key generation algorithm for ECDSA signatures and sends the zero-knowledge proof instruction to the zero-knowledge proof generation function to generate the zero-knowledge proof; The other party to the protocol receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the key generation algorithm for ECDSA signature is run, and the zero-knowledge proof instruction is sent to the zero-knowledge proof generation function to generate the zero-knowledge proof. One party to the agreement receives a zero-knowledge proof and verifies its correctness. If it is incorrect, the agreement is terminated; otherwise, the agreement continues. Both parties to the agreement calculate and store the signature verification private key and public key.

4. The two-party collaborative signature method based on combined ECDSA as described in claim 1, characterized in that, Each session between the two parties to the agreement is assigned a unique session identifier.

5. The two-party collaborative signature method based on combined ECDSA as described in claim 1, characterized in that, The ideal commitment function is used for: The receiving party sends a commitment instruction, records the sender, session identifier, and signing private key, and sends the commitment result to the other party; if the commitment instruction has been recorded before, it is ignored. If the sender, session identifier, and signing private key have been previously recorded, the open commitment instruction sent by the receiving party to the other party of the protocol will be sent to the receiving party.

6. The two-party collaborative signature method based on combined ECDSA as described in claim 1, characterized in that, The ideal zero-knowledge proof function is used for: Upon receiving a zero-knowledge proof instruction from one party to the protocol: if the signing private key and the corresponding instruction parameters do not belong to a known hard relation or the session identifier has been used before, ignore the message; otherwise, send the zero-knowledge proof to the other party to the protocol.

7. A system for a two-party collaborative signature method based on combined ECDSA as described in any one of claims 1-6, characterized in that, include: The sender and receiver communicating with each other; The sender is configured to send the commitment non-interactive zero-knowledge proof instruction to the ideal commitment non-interactive zero-knowledge proof function to generate a non-interactive zero-knowledge proof and make a commitment. The receiver is configured to receive a commitment to the proof, calculate the zero-knowledge proof instruction, and send it to the ideal zero-knowledge proof function to generate a zero-knowledge proof. The sender is also configured to receive zero-knowledge proofs and verify their correctness. If the proof is incorrect, the protocol is terminated; otherwise, the protocol continues. The sender is also configured to send an instruction to open the commitment with zero-knowledge proof to the ideal commitment function to unlock the commitment. The receiver is also configured to receive the zero-knowledge proof that unlocks the commitment and verify its correctness. If it is incorrect, the protocol is terminated; otherwise, the protocol continues. The receiver is also configured to, after receiving the message to be signed, use the signing private key to calculate the signature share and send the signature share to the sender. The sender uses the signature public key to verify the signature. If the verification is successful, it outputs the signature value; otherwise, it terminates the protocol.

8. The system of the two-party collaborative signature method based on combined ECDSA as described in claim 7, characterized in that, The signing private key and signing public key are generated by a two-party collaborative key generation protocol based on combined ECDSA signatures.

9. The system of the two-party collaborative signature method based on combined ECDSA as described in claim 8, characterized in that, The process of a two-party collaborative key generation protocol based on combined ECDSA signatures is as follows: One party to the protocol runs the key generation algorithm for ECDSA signatures and sends the zero-knowledge proof instruction to the zero-knowledge proof generation function to generate the zero-knowledge proof; The other party to the protocol receives the zero-knowledge proof and verifies its correctness. If it is incorrect, the protocol is terminated; otherwise, the key generation algorithm for ECDSA signature is run, and the zero-knowledge proof instruction is sent to the zero-knowledge proof generation function to generate the zero-knowledge proof. One party to the agreement receives a zero-knowledge proof and verifies its correctness. If it is incorrect, the agreement is terminated; otherwise, the agreement continues. Both parties to the agreement calculate and store the private and public keys for signature verification.

Images