Generating a digital signature

Abstract

A computer-implemented method for generating digital signatures for signing a message, performed by a coordinating party, comprising the steps of obtaining at least a threshold number of respective signature shares; obtaining, for each of the respective signature shares, a respective commitment for the respective signature share, the respective commitment being generated by a respective participant that generated the respective signature share; generating a Merkle tree, wherein at least a threshold number of respective leaf nodes of the Merkle tree include a respective hash of the respective signature commitment combined with a respective participant index, the respective participant index being associated with a respective participant that generated the respective signature commitment; generating a signature based on at least the threshold number of respective signature shares; and making the Merkle root of the Merkle tree available to at least each participant that generated a signature share.

Description

[Technical Field]

[0001] This disclosure relates to a method for generating a digital signature and a method for proving that a participant has provided a share of the digital signature. [Background technology]

[0002] Generally, shared secrets may be used to share data items distributed among a group of participants. Each participant has a different share of the secret. Typically, the secret can only be reconstructed when a certain number of participants (called the "threshold") have enough of their respective shares to be used, for example, to combine together in order to compute the secret.

[0003] Public-key cryptography is a type of cryptographic system that uses a pair of keys: a private key known only to its owner, and a public key generated based on the corresponding private key, which may be disseminated without compromising the security of the private key.

[0004] Public-key cryptography allows a sender to encrypt a message using the recipient's public key (i.e., a public key corresponding to a private key known only to the recipient). The encrypted message can then only be decrypted using the recipient's private key.

[0005] Similarly, a sender can sign a message using their private key, for example, to prove that the message was sent by them and / or to indicate that the sender agrees to the message. A signer (i.e., the one who generates the signature) uses their private key to create a digital signature based on the message. Creating a digital signature based on a message means supplying the message and the private key to a function that generates a signature based on both the message and the private key. The signature is either added to the message (e.g., tagged in the message) or otherwise associated with the message. Anyone with the signer's corresponding public key can use the same message and the digital signature to verify whether the signature was validly created, i.e., whether the signature was truly created using the signer's private key. In addition to guaranteeing the authenticity of the message, a digital signature also guarantees the integrity and non-repudiation of the message. That is, a digital signature can be used to prove that the message has not been altered since it was signed and that the creator of the signature cannot deny in the future that they created the signature.

[0006] A digital signature scheme typically involves three steps, namely, an algorithm. The key generation algorithm is used to generate a random private key and its corresponding public key. The signature algorithm is used to generate a signature based on the message and the private key. The verification algorithm is used to verify, given the public key and message, whether the signature was generated according to the signature algorithm using the corresponding private key.

[0007] A common use of a shared secret is as the shared private key in a private-public key pair. That is, the private key may be distributed among a group of participants in such a way that no single participant can access it. Therefore, no single participant can generate a valid signature for a message. Instead, for a signature to be generated, some or all of the participants must generate the private key together.

[0008] Instead of participants sharing their private key shares to generate signatures, they may use a threshold signature scheme. A threshold signature scheme allows a threshold number of participants in a group to create a digital signature on a message using their individual shares of a shared private key, without the private key being made available to any single participant. Here, the digital signature is the signature generated based on the message to be signed. In such a scheme, a signature can only be generated if a threshold number of participants agree to generate a signature on the message. Any attempt to generate a signature using fewer participants will not produce a valid signature. Thus, a valid signature by a group (i.e., a signature generated using the message and the shared private key) clearly requires the agreement of a threshold number of people to generate the signature. This also suggests that any adversary would need to obtain a threshold number of shares of the private key to forge a signature with that private key. [Overview of the project] [Problems that the invention aims to solve]

[0009] As described above, threshold signature schemes require participants to provide their respective signature shares in order to generate a valid signature. A valid signature proves that at least a threshold number of participants provided signature shares, but it does not prove which participants in the group provided which shares. In other words, in a threshold signature scheme, there is no way to determine who created a given signature, and the resulting signature will always be the same regardless of which shares were used to create it. Therefore, a threshold signature scheme is needed that allows signers (i.e., participants who contributed to the signature) to prove that they truly provided signature shares. Such a scheme could be used to prevent other participants from making false claims that they contributed to the signature, or that the party they are proving did not contribute to the signature. [Means for solving the problem]

[0010] According to one aspect disclosed herein, a method is provided which is performed by a computer to generate a digital signature for signing a message, wherein each participant in a group of participants has a private key share of a shared private key, the shared private key can only be generated in at least a threshold number of each private key share, each participant is associated with a respective participant index, and the method is performed by a coordinating party and includes the steps of: obtaining at least a threshold number of each signature share, wherein each signature is generated by the respective participant based on their respective private key share; obtaining, with respect to each of the respective signature share, each commitment for each signature share, wherein each commitment is generated by the respective participant that generated the respective signature share; generating a Merkle tree, wherein at least a threshold number of each leaf node of the Merkle tree contains the respective hash of each signature commitment combined with the respective participant index, and each participant index is associated with the respective participant that generated the respective signature commitment; generating a signature based on at least a threshold number of each signature share; and making the Merkle root of the Merkle tree available to at least the respective participant that generated each signature share.

[0011] According to one embodiment disclosed herein, a computer-based method is performed by a first participant of a group of participants, which certifies that the first participant has generated each signature share of a digital signature for signing a message, wherein each participant of the group has each private key share of a shared private key, and the shared private key can only be generated in at least a threshold number of each private key share, and each participant is associated with their respective participant index, and the method comprises the steps of: generating a first signature share based on the first private key share and the message; generating a first commitment of the first signature share; and a) at least a threshold number A method is provided which includes the steps of: providing a) a first signature share and b) a first commitment to a coordinating party in order to generate a signature based on each signature share and a) a Merkle tree, wherein at least a threshold number of leaf nodes in the Merkle tree each contain a hash of each signature commitment combined with each participant index, and each participant index is associated with each participant that generated each signature commitment; obtaining the Merkle root of the Merkle tree; obtaining a Merkle proof based on each leaf node of the Merkle tree generated based on each participant index associated with the first participant; and verifying that the leaf nodes of the Merkle tree having the Merkle root were generated based on the first commitment and the first participant index, thereby providing a verifying party with at least the Merkle proof, the first commitment and the first participant index in order to verify that the coordinating party generated a signature based on the first signature share.

[0012] Each participant is associated with an index. The coordinating party (or coordinator) receives a threshold number of signature shares or more signature shares and constructs signatures based on those signature shares. Generally, any threshold signature scheme may be used to generate signature shares and construct signatures. The coordinator also receives commitments for signature shares from each participant providing them. In some examples, the commitment is the signature share itself or a hash of the signature share. In other examples, the commitment may not be based on signature shares but may be linked to or associated with signature shares based on data specific to the participant. The coordinator constructs a Merkle tree using the commitments, and at least some (or each, depending on the number of signature shares received) leaf hashes of the Merkle tree are based on their respective indexes and their respective commitments, with the index being associated with the participant who provided the commitment. The coordinator provides the Merkle root of the tree to participants, for example, by publishing the Merkle root on the blockchain.

[0013] When a participant wants to prove that they contributed to the signature share, they can provide the verifying party with i) their index, ii) their commitment, and iii) their Merkle proof to prove that their index and commitment were used to generate leaf hashes that form part of a Merkle tree with a (publicly available) Merkle root. In this way, only the proving participant (among the participants excluding the coordinator) can access their commitment that was used by the coordinator to build the Merkle tree, so the proving participant can prove that the coordinator generated the signatures based on the proving participant's signature share.

[0014] To aid in understanding embodiments of the present disclosure and to illustrate how such embodiments may be carried out, the accompanying drawings are referenced only as examples. [Brief explanation of the drawing]

[0015] [Figure 1] This is a schematic block diagram of a system for carrying out an embodiment of the present invention. [Figure 2] This diagram schematically represents the Merkle tree corresponding to eight signatories in a threshold signature scheme. [Figure 3] This is a flowchart illustrating an exemplary embodiment of the present invention. [Figure 4] This flowchart illustrates an exemplary signature generation method according to some embodiments of the present invention. [Modes for carrying out the invention]

[0016] 1. Basic knowledge of cryptography The following examples are described in terms of elliptic curve cryptography, but the present invention is not limited to any one particular cryptographic scheme and may generally be applied to any cryptographic scheme, such as RSA or other public-key cryptography schemes.

[0017] 1.1 Elliptic Curve Group The elliptic curve E is given by: y 2 = x 3 + ax + b mod p Satisfying the conditions, here,

[0018]

number

[0019] And a and b are 4a 3 + 27b 2 It is a constant that satisfies ≠ 0. The group on this elliptic curve is defined as the set of elements (x, y) that satisfy this equation, with the identity element being the point O at infinity. The group operation on the elements of this group is called elliptic curve point addition and is denoted by +. This group is,

[0020]

number

[0021] It is shown by and its order is shown by n.

[0022] This group operation can be used to define another operation on an element called point multiplication, indicated by ·.

[0023]

number

[0024] and scalar

[0025]

number

[0026] For this, point k·G is defined as point G itself plus k times.

[0027] In elliptic curve cryptography, the secret key is a scalar.

[0028]

number

[0029] It is defined as such, and here,

[0030]

number

[0031] is the notation for the set {1, ..., n-1}, and the corresponding public key is the point k·G on the elliptic curve. For example, in some blockchain protocols, the elliptic curve is selected to be the secp256k1 elliptic curve, and the values a, b, and p are fully specified by this elliptic curve. The order n of this group is calculated based on these values and is prime in the case of this curve. The secp256k1 standard also specifies the point G to be used as the generator of this group.

[0032] 1.2 Elliptic Curve Digital Signature Algorithm To create a signature for a message msg with the private key a, the following steps are performed. 1. Calculate the message digest e = hash(msg), where hash can be any hash function. For example, in some cases, hash(msg) = SHA256(SHA256(msg)), where SHA256( ) is the SHA-256 hash function. Note that instead, the message may be hashed only once, or may be hashed three or more times with the same or different hash functions. 2. Select a random integer k ∈ {1, ..., n-1}, where n is the order of the elliptic curve, e.g., the secp256k1 curve. Below, k is called the ephemeral private key. 3. Calculate the ephemeral public key k·G = (R x , R y ) corresponding to this ephemeral private key. 4. Calculate r = R x mod n. If r = 0, return to step 2. 5. Calculate the multiplicative inverse k -1 mod n of the ephemeral key. 6. Calculate s = k -1 (e + ar) mod n. If s = 0, return to step 2. 7. The signature of message msg is (r, s).

[0033] The temporary key must be kept secret; otherwise, the private key can be calculated with the message and signature. Furthermore, a different temporary key must be used each time a signature is generated. Otherwise, it is possible to derive private key a with two different signatures and their corresponding messages.

[0034] Given the message msg, the public key P = a·G, and the corresponding signature (r, s), the signature can be verified by completing the following steps. 1. Calculate the message digest e = hash(msg), for example, e = SHA256(SHA256(msg)). 2. The multiplicative inverse of s -1 Calculate the modulo n. 3. j1 = es -1 mod n and j2 = rs -1 Calculate modulo n. 4. Calculate point Q = j1·G + j2·P. 5. If Q = O(point at infinity), the signature is invalid. 6. If Q ≠ O, then Q := (Q x , Q y ) and u = Q x Calculate modulo n. If u = r, the signature is valid.

[0035] In a threshold signature scheme, this private key a is divided into key shares that are distributed among the participants in the threshold scheme group.

[0036] 1.3 Joint Verifiable Random Secret Sharing Suppose N participants want to create a joint secret that, in this scheme, can only be regenerated by at least (t + 1) of the participants. The following steps are taken to create the shared secret. 1. Participants agree on a unique label i for each participant. Each participant i is assigned (t + 1) random numbers.

[0037]

number

[0038] This generates, where ∈ R is a set

[0039]

number

[0040] This means a randomly generated source, where,

[0041]

number

[0042] This is a notation for the set {1, ..., n-1}. Then, each participant has a secret polynomial of degree t for i = 1, ..., N. f i (x) = a i0 + a i1 x + ···+ a it x t mod n It has [this property]. Note that from this point forward, mod n notation will be omitted, and all arithmetic operations on integers will be assumed to be performed modulo n. 2. Each participant i communicates with participant j only, for example, using a secure communication channel with participant j. i Send (j). 3. Each participant i shares their private secret polynomial.

[0043]

number

[0044] Calculate as follows.

[0045] The shared secret is (i, a i ) is a point in the form, where i is the label of the participant in the form. This method for creating a secret share a as described in steps 1-3 is referred to herein as a with respect to participant i. i = As shown by JVRSS(i). Note that JVRSS usually stands for "Joint verification random secret sharing" and also includes steps 4 and 5. However, throughout this specification, JVRSS is understood to mean performing at least steps 1 through 3, with steps 4 and 5 being optional steps.

[0046] Now that the participants have generated a shared polynomial, they can verify that other participants have shared the correct information with all participants, and that all participants have the same shared polynomial. This is done as follows: 4. Each participant i has an obfuscated coefficient for k = 0, ..., t. a ik ·G Broadcast this to all participants. 5. Each participant i, f j (i) Calculate G,

[0047]

number

[0048] By verifying that each participant j is a point f of the polynomial, j Check that (i) was calculated correctly. If all participants find that this equation holds for each polynomial, the group can be collectively confident that all participants have created the same shared polynomial.

[0049] 1.4 Reconstructing Shared Secrets Assume that the participants want to reconstruct a shared secret a, which is a zero-degree polynomial. (1, a1), ..., ((t + 1), a t+1 ) Given (t + 1) points on this polynomial of the form, to obtain the shared secret a, we derive from a general formula known as "Lagrangian interpolation"

[0050]

number

[0051] Calculate.

[0052] 1.5 Public Key Calculation The public key a of the coefficients of N zero-degree private polynomials for j = 1, ..., N, shared in step 4 of JVRSS. j0 Given G, each participant corresponds to the shared secret a.

[0053]

number

[0054] The shared public key P is calculated using this method.

[0055] 1.6 Addition of shared secrets Given that each secret polynomial has degree t, the following steps are taken to calculate the sum of two shared secrets shared within a group of N participants, without anyone knowing the individual secrets. 1. Generate a first shared secret a, where the share of participant i is a threshold (t + 1) for i = 1, ..., N. i = Given by JVRSS(i). 2. Generate a second shared secret b, and the share of participant i is at the threshold (t + 1), where b i = Given by JVRSS(i). 3. Each participant i has their own additive share. ν i = a i + b i mod n Calculate. 4. All participants have their additive share ν i Broadcast this to all other participants. 5. Each participant interpolates at least (t + 1) of the shares, ν = computee(ν1, ...,ν t+1 ) = a + b Calculate. This method for the sum of shared secrets is shown by ADDSS(i) with respect to participant i, and as a result, each participant i knows ν = (a + b).

[0056] 1.7 The product of shared secrets Given that each secret polynomial has degree t, to compute the product of two shared secrets that are both shared within a group of N participants, the group takes the following steps: 1. Generate a first shared secret a, and the share of participant i is a for i = 1, ..., N. i = Given by JVRSS(i). The shared secret polynomial has degree t, meaning that (t + 1) participants are required to recreate the shared secret polynomial. 2. Generate a second shared secret b, and the share of participant i is b i = The secret polynomial given by JVRSS(i) and shared also has degree t. 3. Each participant, μ i = a i b i Use your multiplicative share μ i Calculate. 4. All participants have their multiplicative share μ i Broadcast this to all other participants. 5. Each participant shares μ at 0. i Interpolate at least (2t + 1) of them, μ = interpolate(μ i , ...,μ 2t+1 ) = ab Calculate. This method for calculating the product of two shared secrets is shown herein by μ = ab = PROSS(i) with respect to participant i.

[0057] 1.8 Shared secret inverse To compute the inverse of the shared secret a, the following steps are taken. 1. All participants calculate a shared secret product PROSS(i), the result of which μ = ab mod n. 2. Each participant calculates the modular inverse of μ, and as a result, μ -1 = (ab) -1 mod n This is the result. 3. Each participant i will share their inverse secret.

[0058]

number

[0059] It is calculated by calculating [this]. This method for calculating the inverse of a shared secret is, with respect to participant i

[0060]

number

[0061] This is shown by.

[0062] 1.9 Generating and verifying shared private keys To compute the shared private key a among N≧2t+1 participants (of which t+1 are required to create signatures), participants perform JVRSS and public key computation with threshold t+1 as described above. As a result, every participant i = 1, ..., N has a private key share a i It has a corresponding shared public key P = (a·G).

[0063] 1.10 Generating a temporary key share A group of size N using a shared secret key a with threshold (t + 1) to generate a temporary key share and the corresponding r required for signing performs the following steps: 1. Inverse sharing of shared secrets

[0064]

number

[0065] This generates a variable where (t + 1) shares are needed to recreate it. 2. Each participant, k i Using the obfuscated coefficients shared in the verification

[0066]

number

[0067] Calculate, and then, r = x mod n Calculate. 3. Each participant i,

[0068]

number

[0069] Remember this.

[0070] 1.11 Non-optimal signature generation Assume that at least 2t + 1 participants want to create a signature for the message, and one of the participants chooses to coordinate this. The following steps are taken for the group to create a signature with the shared private key a. 1. The coordinator will request that at least 2t + 1 participants sign the message. 2. Each participant i is the temporary key calculated in the previous section.

[0071]

number

[0072] To recover it, all users must use the same temporary key corresponding to the share. 3. Each participant calculates the message digest e = SHA-256(SHA-256(message)). 4. Each participant i shares their signature s i , in other words,

[0073]

number

[0074] Calculate, here, a i This is the sharing of private keys among the participants. 5. Each participant shares their signature (r, s i Send this to the coordinator. 6. When the coordinator receives 2t + 1 signature shares, s = interpolate(s1, ..., s 2t+1 ) Calculate the value and output the signature as (r, s). 7. The coordinator verifies the signature using standard ECDSA verification. If this fails, at least one of the shares must be incorrect, and the signature generation algorithm should be run again.

[0075] 1.12 Secret addition with different thresholds In the case of secret addition of orders t and t', the addition of two secrets requires max(t, t') + 1 shares to compute it. This is because the addition step of the shared secret shares creates a new polynomial share. This new additive polynomial is equivalent to the result of adding the individual polynomials of the two shared secrets. Adding two polynomials is equivalent to adding the corresponding coefficients of each degree of x. Therefore, the degree of the additive polynomial must be the same as the highest degree of the two polynomials. This can be generalized to the addition of three or more polynomials, and the degree of the resulting polynomial will be the same as the degree of the individual polynomials of the highest degree.

[0076] When the sum of two secrets with different thresholds is calculated, the security of the secret with the higher threshold is reduced. This is because, now knowing the result (a + b) along with their respective thresholds t and t', assuming t < t', we can calculate a with t shares and then calculate (a + b) - a = b, and thus the value b is calculated with only t shares. This lower threshold will be referred to below as the "implicated threshold" of b.

[0077] 1.13 Secret multiplication with different thresholds For two secret multiplications with thresholds t and t', the calculation of the multiplication requires t + t' + 1 shares. In this case, the multiplication of the shares of the two polynomials yields a share on a new polynomial. This new polynomial is the result of multiplying the two individual polynomials, and therefore the degree of the result is the sum of the degrees of the two individual polynomials.

[0078] Multiplication can also be generalized to any number of shared secrets, and the resulting threshold is the sum of the individual thresholds plus 1, Σ ρ t ρ + 1, where ρ moves within the range of individual shared secrets.

[0079] Similar to addition, the multiplication of two secrets with different thresholds results in an implicit threshold of the secret with the higher threshold. As previously mentioned, if a and b are known, where a has a threshold t and b has a threshold t', then both a and b can be computed in t shares. First compute a, then (ab)a -1 Using this method, we can obtain b with only t secret shares.

[0080] 1.14 Combining shared secret addition and multiplication in one step Generalizing the above, it is possible to compute any combination of addition and multiplication in a single step. A group of N participants wants to compute the result ab + c, where a, b, and c are each a threshold (t a + 1), (t b + 1), (t c Assume it is a shared secret with (t + 1). a + t b , t c The condition exists that < N, that is, the number of participants in this scheme must be greater than the largest of the order of secret c and the order of the result of multiplying secrets a and b. 1. Each participant i is at a threshold (t a + 1), (t b + 1), (t c+ 1) My secret share a i = JVRSS(i), b i = JVRSS(i), c i = Calculate JVRSS(i). 2. Each participant i has λ i = a i b i + c i Calculate. 3. Each participant i and each other have a result λ i Share. 4. Each participant has max(t a + t b , t c Interpolating the shares of ) + 1, the result is λ = int(λ1, ...,λ i , ...) = ab + c is obtained. This is done in the calculation of shared signatures according to some of the embodiments below. That is,

[0081]

number

[0082] Interpolation exists. This is basically,

[0083]

number

[0084] and

[0085]

number

[0086] The above is the case. In this case, t a + t b = 2t and t c = t, and interpolation is max(t a + t b , t c) + 1 = 2t + 1 share.

[0087] 1.16 Merkle tree A Merkle tree is a hierarchical data structure that enables secure validation of a collection of data. In a Merkle tree, each node in the tree is given an index pair (i,j) and is represented as N(i,j). The indices i and j are simply numerical labels associated with a particular location within the tree.

[0088] A characteristic of a binary Merkle tree (a specific type of Merkle tree) is that the construction of each node is as follows:

[0089]

number

[0090] This is determined by the cryptographic hash function, where H is the cryptographic hash function.

[0091] A binary Merkle tree constructed according to these formulas is shown in Figure 2. As shown, when i = j, it corresponds to a leaf node, and the leaf node is simply the i-th packet D of the corresponding data. i This is the hash. If i ≠ j, it corresponds to an internal or parent node, which is generated by recursively hashing and concatenating the child nodes until one parent (Merkle root) is found.

[0092] For example, node N(0,3) receives four data packets D0, ..., D3 N(0,3) = H(N(0,1) || N(2,3)) = [H(N(0,0) || N(1,1)) || H(N(2,2) || N(3,3))] = [H(H(D0) || H(D1)) || H(H(D2) || H(D3))] It is constructed as follows.

[0093] The depth M of the tree is defined as the lowest level of the nodes within the tree, and the depth m of a node is the level at which the node exists. For example, m root = 0 and m leaf = M, where in Figure 5, M = 3.

[0094] For Merkle trees in Bitcoin and some other blockchains, the hash function is double SHA256, which applies the standard hash function SHA-256 twice, i.e., H(x) = SHA256(SHA256(x)).

[0095] 1.17 Merkle Proof The main function of a Merkle tree is to verify that a certain data packet D i is a member of a list or set of N data packets D ∈ {D0, ..., D N-1}. The verification mechanism is known as a Merkle proof and involves obtaining a set of hashes known as a Merkle path for a given data packet D i and the Merkle root R. Simply put, a Merkle proof for a data packet is the smallest list of hashes required to reconstruct the root R by repeated hashing and concatenation, often referred to as an "authentication proof".

[0096] If all packets D0, ..., D N-1 and their order are known to the prover, the proof of existence can be easily executed. However, this not only requires that the entire data set be available to the prover but also requires a much larger storage overhead than a Merkle proof. A comparison between using a Merkle proof and using the entire list is shown in the following table, in which a binary Merkle tree is used and it is assumed that the number N of data blocks is exactly equal to a power of 2.

[0097] Given a Merkle root R, the data block D0 is an ordered list D ∈ {D0, ..., D} represented by R. N-1 If you want to prove that something belongs to}, you can perform a Merkle proof as follows, and the example Merkle tree contains eight leaf hashes identified by indices (0,0) through (7,7). That is, i. Obtain the Merkle root R from a reliable source. ii. Obtain the Merkle proof Γ from the source. In this case, Γ is a set of hashes. That is, Γ = {N(1,1), N(2,3), N(4,7)} iii. Using D1 and Γ, we compute the Merkle proof as follows: a. Hash the data block N(0,0) = H(D0) Obtain it. b. Concatenate with N(1,1) and hash N(0,1) = H(N(0,0) || N(1,1)) Obtain it. c. Concatenate with N(2,3) and hash N(0,3) = H(N(0,1) || N(2,3)) Obtain it. d. Concatenate N(4,7) and hash to obtain the route. N(0,7) = H(N(0,3) || N(4,7)) R' = N(0,7) e. Compare the calculated square root R' with the square root R obtained in (i). 1. If R' = R, then the existence of D0 in the tree and therefore in the data set D is confirmed. 2. If R'≠R, the proof fails, and D0 is not confirmed to be an element of D. This is an efficient mechanism for providing proof of the existence of data as part of a data set represented by a Merkle tree and its root.

[0098] 2. Generating signature shares Figure 1 shows an exemplary system 100 for implementing an embodiment of the present invention. As shown, system 100 includes a number of parties (also referred to herein as “Participants”) 102. Although only three Participants 102a, 102b, and 102c are shown in Figure 1, it will be understood that, in general, the system may include any number of Participants. System 100 also includes a coordinating party 104 (or simply a “coordinator”), which may be one of the Participants 102 or not one of the Participants 102. Each of the Participants 102 and the coordinating party 104 operates its respective computing equipment.

[0099] Each computing device includes one or more processors, such as one or more central processing units (CPUs), accelerator processors such as graphics processing units (GPUs), other application-specific processors, and / or field-programmable gate arrays (FPGAs). Each computing device may also include memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. The memory may include one or more memory units employing one or more memory media, such as magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROM, and / or optical media such as optical disc drives. Each computing device may include at least one user terminal, such as a desktop or laptop computer, tablet, smartphone, or wearable device such as a smartwatch. Alternatively or additionally, each computing device may include one or more other networked resources, such as cloud computing resources (cloud computing resources including resources of one or more physical server devices implemented in one or more locations), accessed via the user terminal. It will be understood that all actions described as being performed by parties to System 100 may be performed by the respective computing devices operated by those parties.

[0100] Each participant 102 may be configured to transmit data to one, some, or all of the other participants 102 via a network such as the Internet using a LAN or WAN connection, or via alternative wired or wireless communication means. Unless otherwise specified in the context, a reference to a participant 102 transmitting data may be understood as, for example, sending data individually to other participants 102 via a secure communication channel between the first participant 102a and the second participant 102b, or broadcasting to the entire group via, for example, email or other means. Also, unless otherwise specified in the context, each participant 102 may transmit data in raw or encrypted form. For example, data may be encrypted using the receiving participant's public key before being sent to the receiving participant. The same applies to the coordinator 104 sending and receiving data to one, some, or all of the participants 102.

[0101] Embodiments of the present invention will be described primarily in terms of the first participant 102a. However, it will be understood that, generally speaking, the steps of the described method may be similarly performed by other participants, such as the second participant 102b or the third participant 102c. It will also be understood that terms such as “first,” “second,” and “third” are used herein simply as distinguishing labels and do not necessarily indicate order, unless otherwise required by the specific context in which these terms are used.

[0102] The present invention enables each participant 102 in the group of participants 102 to generate their respective share of the threshold signature for the coordinator 104. Furthermore, the present invention enables participants 102 to prove that they contributed their respective share used to generate the threshold signature.

[0103] Each participant 102 can access their respective share of the shared secret key (for example, by storing it in the memory of their own computing device). These secret key shares may be generated using a secret sharing scheme such as JVRSS (mentioned above) or Shamir's Secret Sharing Scheme (SSSS). Alternative methods for generating the shared secret key shares may be used.

[0104] In some embodiments, each participant 102 may also have access to their respective share of the shared temporary private key. The temporary private key share may be generated using JVRSS, SSSS, or an alternative method. Each participant 102 may also have access to the inverse of their respective temporary private key share, or the inverse may be generated when needed, for example, using the INVSS function described above. Each participant may also have access to a temporary public key, i.e., the public key corresponding to the shared temporary private key. As is known in the art, the public key includes a first (x) coordinate and a second (y) coordinate, the first coordinate being used to generate the signature share, as described below. Each participant 102 may also have access to their respective message-independent component (MIC) of the signature share, i.e., the signature share is generated based on their respective MIC. The MIC itself may be generated by a given participant 102 based on their respective private key share and their respective temporary private key, and further on the first coordinate of the temporary public key. The data required by each participant 102 depends on the specific format of the signature to be generated, for example, an ECDSA signature.

[0105] All of the above data items (e.g., private key share, temporary key share, etc.) may be generated during the setup phase prior to the signing phase. For example, the data items may be generated before receiving a request from Coordinator 104 to provide the signature share.

[0106] Each participant is associated with a corresponding index, referred to herein as the “Participant Index.” For example, the first participant 102a is associated with the first participant index, the second participant 102b is associated with the second participant index, and so on. Each participant index may be an integer, for example, “1” for the first participant 102a, “2” for the second participant 102b, and so on. The specific value of the participant index is not important; rather, it is important that each participant has a unique participant index.

[0107] A shared private key has a threshold; that is, a private key can only be successfully generated based on private key shares of at least a threshold number. Similarly, a signature has a threshold; that is, at least a threshold number of signature shares are required to generate a valid signature. It should be understood that all references to "threshold" are to be taken as meaning the number corresponding to the threshold of the private key. For example, the threshold could be 2, or 3, or 10, etc.

[0108] The first participant 102a generates its own signature share based on the message. The message may have been obtained from the coordinator 104 (for example, as part of a request for a signature share) or may have been known to the first participant 102 in advance. The signature share is generated based on (i.e., a function of) at least the first private key share. In some embodiments, the signature share is also generated based on the first temporary key share (or more specifically, its inverse), the first coordinates of the temporary public key (or more specifically, the first coordinates mod n, where n is the order of the elliptic curve), the child private key, the message (or more specifically, the hash of the message), and the first MIC share.

[0109] Other participants intending to generate their respective signature shares (for example, a second participant 102b) perform an equivalent process to generate their respective signature shares.

[0110] The first participant 102a may send its first signature shares to the coordinator 104 in order to generate a signature based on at least a threshold number of signature shares. Alternatively, the first participant 102a may be the coordinator 104, in which case the first participant 102a may obtain each signature share from each participant and then generate a signature based on each signature share.

[0111] The coordinator 104 obtains at least a threshold number of signature shares. The coordinator 104 may obtain more than the threshold number, for example, one from each participant 102.

[0112] The coordinator 104 also obtains the respective signature commitments for each signature share provided by the participants. In some examples, the signature share itself is the commitment. In other examples, the commitment may be based on the signature share, for example, the commitment may be a hash of the signature share.

[0113] In other examples, commitments may be based on the data used to derive the signature share. For example, the commitment for each signature share may be based on the respective temporary private key share and the respective MICs used to derive the signature share. Commitments may also be based on the x-coordinate of a temporary public key, such as the r-value of the public key, where r = x mod n. Specific examples of this form of commitment are further given below. This form of commitment may be used to prove that a participant has provided a signature share without revealing the signature share itself.

[0114] Once the respective commitments for each signature share are obtained, the coordinator 104 constructs a Merkle tree based on the respective commitments and respective indices of the participants who provided each signature share. More specifically, each commitment is mapped to the index of the participant 102 who provided the commitment (e.g., by concatenation) to form the respective leaf hash of the Merkle tree, and then hashed. An exemplary Merkle tree constructed in this way is shown in Figure 2. In Figure 2, each leaf hash of the Merkle tree corresponds to the respective data D i Based on this, the data includes hashes of each commitment and each participant index. The exemplary Merkle tree in Figure 2 corresponds to a scenario where 8 participants 102 each provide their signatures.

[0115] Coordinator 104 (in the example in Figure 2, node h 18 The Merkle root (which is the Merkle root) is made available to each participant 102 who provided their respective signature shares. The coordinator 104 may send the Merkle root directly to the participants 102, or the Merkle root may be stored on a resource accessible to the participants, such as a web page, or on 106. That is, the coordinator 104 may submit a blockchain transaction to the blockchain network 106, and the transaction may include the Merkle root in its output, for example.

[0116] Coordinator 104 may send each participant 102 who provided a signed share a Merkle proof to prove that each participant 102's respective index and commitment were used to form a leaf hash of a Merkle tree having a Merkle root. In other examples, Coordinator 104 may send Merkle proofs only to participants who request them. A Merkle proof on a given leaf hash includes the set of hashes needed to derive the Merkle root of a Merkle tree starting from that leaf hash. Typically, a given leaf hash itself is not included in a Merkle proof because it is known to or can be derived by the prover (in this case, the participant who wants to prove that they provided a signed share). However, it is not ruled out that in some examples, a Merkle proof may include a given leaf hash. In other examples, a participant may obtain a Merkle proof in an alternative way. For example, Coordinator 104 may (Data D i In some cases, the entire Merkle tree (excluding the individual element) may be made public.

[0117] In some cases, Coordinator 104 may make the Merkle root (or Merkle tree) available to participants (for example, by making it public on the blockchain) before generating the signature. This may allow participants to verify that the Merkle root was computed correctly and to object if it was not computed correctly. In some cases, each participant may use their own Merkle proof to verify that the Merkle root was computed based on their signature commitment.

[0118] In some examples, participant 102 may send their signature commitment to coordinator 104 before sending their signature share (of course, in these examples, the signature commitment cannot be the signature share itself). For example, participant 102 may send hashes of each of their signature shares. In other examples where the signature commitment is not based on the signature share itself, participant 102 may receive a Merkle root and include the Merkle root in the message to be signed so that the signature share signs the Merkle root. In this way, participant 102 verifies the Merkle root.

[0119] As further explained below, a signed message may contain at least a portion of a blockchain transaction, for example, one or more inputs and one or more outputs of a transaction. Depending on the signing commitment used, a signed transaction may contain a Merkle root.

[0120] When a participant, for example, the first participant 102a, wants to prove or needs to prove that they provided a share of the signature, participant 102 provides the necessary information to the verifying party (not shown in Figure 1). That is, the participant provides the verifying party with their respective commitments (e.g., a signature share or its hash), their respective index, and their respective Merkle proof in order to verify that the Merkle tree corresponding to the Merkle root was generated based on the participant's respective commitment and index. The participant may also provide the verifying party with the Merkle root of the Merkle tree, or the Merkle root may be obtained from elsewhere, for example, from the blockchain or from the coordinator 104.

[0121] Figure 3 shows an exemplary method 300 according to some embodiments of the present invention. Steps S301 to S305 are performed by the adjuster 104. Note that at least some of the steps may be performed in an order different from that shown in Figure 3. In step S301, the adjuster 104 obtains at least a threshold number of signature shares from the participant 102, and in step S302, the adjuster 104 generates a signature based on those signature shares. In step S303, the adjuster 104 obtains respective commitments from each of the participants 102 who provided (or intended to provide) the signature shares. In step S304, the adjuster 104 constructs a Merkle tree based on those commitments, and in step S305, the adjuster publishes the Merkle root of the Merkle tree on the blockchain.

[0122] The following gives further specific examples of the described embodiments.

[0123] As discussed above, a Merkle tree (or its root) of signers' signature shares and indices can be created and stored in a blockchain transaction, such as an OP_RETURN output. And anyone who wants to prove that they signed a message (e.g., a blockchain transaction) may prove that their index and signature share are within the Merkle tree. An example of the structure of such a Merkle tree for eight signers is shown in Figure 2. In Figure 2, node D i represents data that is the index and signature share of participant i. Node h ii is the hash hash(D i ) of the data, and h ij is the notation for hash(h ik || h (k+1)j ), where

[0124]

Number

[0125] For example, to prove that participant 5 provided the signature, participant 5 simply sends a message to node D5, h 66 h 78 , and h 14 All you need to do is provide the data. Then the verifier can calculate the result h18 and verify that it is the same as Merkle root. The verifier can then provide other data D i No information regarding this will be known without the data being explicitly provided. The number of data items required to be included in the route is 2 x If it is not in the form (where x is any positive integer), then 2 x Note that there are padded zeros as extra leaves in order to create the next number of leaves that can be written as . As another example, an extra leaf may be padded in a Merkle tree, and instead of the leaves becoming zero, all leaf hashes that are not paired with a leaf hash may be paired with themselves. In other words, a leaf hash may be concatenated with itself (i.e., the leaf hash is duplicated) and then hashed in order to form a node in the next layer of the Merkle tree.

[0126] When the group coordinator 104 receives a sufficient number of signatures, D i = (i, s i Compute this Merkle tree, which is ( ). If more participants than the threshold respond, the coordinator 104 may still include those participants in the Merkle tree. This can then be used as evidence that the participants agreed to sign.

[0127] When the harmonizer 104 creates this Merkle tree, it returns the relevant data (e.g., Merkle root, Merkle proof, etc.) to each participant and may also broadcast the Merkle root. At that time, each participant 102 may verify that all participants 102 have the same broadcasted Merkle root to ensure that participants 102 have been given the correct information. If it is found that the harmonizer has generated an incorrect tree, the harmonizer will be punished, thereby deterring them from cheating.

[0128] In some use cases, it can be beneficial to be able to provide proof that the Merkle root was created before the signature. If the Merkle root is created after the signature, there is no proof from the signer that the signer validated this Merkle root. By creating the Merkle root before the signature, the act of signing becomes a form of proof that the Merkle root is correct. The timestamp when the Merkle root was generated can be obtained by storing the Merkle root on the blockchain.

[0129] If the signed message is a regular message (i.e., not necessarily a blockchain transaction), this Merkle root may be stored as data within the (OP_RETURN) output of the transaction on the blockchain, which can be referenced when needed. This may be a service provided by a trusted third party to verify that the signer is the person claimed to be. On the other hand, if threshold signatures are signing a message that will contain a Merkle root, such as a blockchain transaction, there are several nuances to consider. If the group attempts to directly include this Merkle root in the signed message, they must be careful not to invalidate the signature, for example, by having Coordinator 104 request a signature on a message and sending the message to be signed to a participant. Participant 102 creates their signature share and returns it to Coordinator. Coordinator 104 creates the signature and Merkle tree. The Coordinator then attempts to include this Merkle root in the message, for example, by concatenating it to the end of the message, or, if the message is a blockchain transaction, the Merkle root may be included in the output field of the transaction. If the coordinator does this, they will invalidate the signature on the message and must request that each participant share another signature.

[0130] One way to avoid this is for the coordinator to first give commitment k to the participants who agree to sign. i rσ i The task is to create G and request that it be returned to the coordinator. This particular commitment is chosen because it is message-independent and can be verified when the coordinator receives participant i's signature share. The signature share in this example is:

[0131]

number

[0132] Please note that it is generated as follows. This is, s i k i = e + k i rσ i This means that... Therefore, s i k i G - eG = k i rσ i G That is the case.

[0133] The last expression is, after the signature share is sent, s i , k i G, e, G, and k i rσ i Since the value of G is known to the adjuster, it can be used to verify the commitment of message-independent components.

[0134] This means that the participant has this value k i rσ i When sharing G, note that the value is their commitment to signing, so we assume that the participant will not change their mind. The coordinator selects the first t+1 people who respond to this request, and leaves D of those participants. i Create a Merkle tree containing these values, for example, D i is, k i rσ i This is "Participant i contributed to this signature" linked to G. The coordinator broadcasts this to the group, and t + 1 selected signers verify their Merkle branch and Merkle root. If the tree is built correctly, the signers create a signature share for the message containing the Merkle root to create the signature and return their share to the coordinator. Note that the Merkle root may be used whenever a signer is asked to prove their contribution.

[0135] One attack on this technique is that if the harmonizer receives more than 2t commitments, it will be able to compute the commitments of each participant in the group. The harmonizer could collude with contributing signers and construct a tree that includes non-signers in place of the colluding signers. To mitigate this problem, a limit may be imposed on the number of commitments that the harmonizer receives. For example, a single-threaded process with a counter could be implemented on the harmonizer side to process incoming messages containing commitments.

[0136] An alternative to the above method is to assume that there are at most t fraudulent participants, and that all honest signers verify the entire Merkle tree to ensure that the Merkle tree captures both signers and non-signers before creating their signature share. This would allow the group to identify not only those who contributed to the generation of the signature, but also those who had the intention to sign it.

[0137] To do this, participants may instead create a Merkle route indicating who they intend to sign and sign it. As described above, the coordinator first requests the signature, and the person who wishes to sign sends a message stating their desire to sign with value k i rσ i Return with G. The adjuster will use data D. i However, the value k i rσ i A Merkle tree is created, consisting of sentences such as "Participant i agrees to this signature" combined with G. The coordinator broadcasts this to the group, and all respondable participants verify that the correct intended signers are included and all non-signers are excluded. If the tree is constructed correctly, signers create their signature share for the message containing this Merkle tree (or Merkle root only). In this process, signers sign the Merkle root to validate its authenticity. Non-signers should note that verifying the Merkle tree and validating its authenticity depends on the sincerity and honesty of the contributing signers.

[0138] One might think there's a risk of incorrect Merkle roots being signed. However, assuming a maximum of t fraudulent participants, signatures will never be created with incorrect Merkle roots. This is because messages containing incorrect Merkle roots will not reach the threshold required to create a signature. This would require honest participants to deviate from the protocol, which contradicts the definition of an honest participant.

[0139] A Merkle tree of signatories can be considered proof of a signature. Given a signature and a Merkle tree, a verifier (e.g., an auditor) may verify that the leaves of the Merkle tree do indeed contain the signatories.

[0140] Figure 4 shows an exemplary method 400 for generating a signature for a message according to an embodiment of the present invention. Steps S401 to S408 are performed in this example by each of the threshold number of participants 102 (including a first participant 102a). Step S409 is performed by a coordinator 101, which may be one of the participants performing steps S401 to S408. It will be understood that some steps may be omitted or performed in a different order.

[0141] Exemplary method 400 enables the creation of a shared secret with a threshold of (t + 1) in a group of N ≥ 2t + 1 participants, where the signature threshold is also (t + 1).

[0142] set up: In step S401, each participant 102 shares a private key. i and compute the corresponding public key. The private key share may be generated using JVRSS as described above. At this point, each participant i has the private key share and public key (a i The shared private key has a threshold (t + 1), where P is the notation for the public key corresponding to the shared private key.

[0143] Pre-calculation: In step S402, each participant 102 calculates the shared temporary key share and the corresponding public key. For example, each participant 102 may calculate the shared temporary key using the JVRSS and public key calculations given in the prior knowledge. Then, each participant 102 may calculate the inverse share based on the temporary private key. As a result, each participant has an inverse share of threshold (t + 1).

[0144]

number

[0145] It has.

[0146] In step S403, each participant 102 creates two different shared blinding key shares. For example, each participant 102 may create two shared secrets, and as a result, participant i has share α. i = JVRSS(i) and β i = JVRSS(i) is defined, and each shared secret has a threshold (t + 1). Note that in some examples, not all shared secrets need to have the same threshold.

[0147] In step S404, each participant 102 calculates their median share and broadcasts their median share to the other participants. For example, each participant i calculates their median share

[0148]

number

[0149] This value may be calculated. This value has a threshold (2t + 1).

[0150] In step S405, the first participant 102a calculates an intermediate value based on at least the intermediate share. For example, the first participant 102a interpolates the (2t + 1) shares λ = interpolate(λ1, ...,λ 2t+1 ) = k -1 Sometimes, the intermediate value is calculated using ar + β.

[0151] In step S406, the first participant 102a,

[0152]

number

[0153] They know this and use it for private key sharing and the corresponding public key (a i Remember it together with P).

[0154] Since a different temporary key is used for each signature, it is possible to set up multiple temporary keys at once; that is, steps S402 to S406 can be repeated to create multiple temporary keys during pre-computation and store those temporary keys for later use. These can be performed concurrently, and therefore there are no additional rounds of communication. Preferably, different values ​​for α and β should be used for each signature.

[0155] Signature generation To sign the message msg, at least (t + 1) participants must perform steps S407 and S408. In step S407, at least a threshold number of participants 102 obtain the message to be signed and compute the message digest. For example, a coordinator 104 may send a request to (t + 1) participants to create a signature share for the message msg. Each participant i may compute the message digest e = hash(msg). In some examples, this hash function is a double SHA-256 hash function. Alternative hash functions may be used.

[0156] In step S408, at least a threshold number of participants 102 calculate their signature share and send that signature share to the coordinator 104. For example, each participant i calculates their signature share

[0157]

number

[0158] Calculate this signature share (r, s i The value r may be sent to the coordinator. Please note that the value r may not be sent by all participants.

[0159] In step S409, the modifier 101 calculates the signature. For example, modifier 101 calculates s = interpolate(s1, ..., s t+1 ).+λ= k -1 e + k -1 We compute ar, and finally the signature (r, s). This yields the expected signature share because the β term cancels out. (kα) -1 A similar modification to this protocol, which explains the case where r is included in the calculation, can be made as described above.

[0160] It should be noted that secret thresholds can vary. That is, the thresholds for a, k, α, and β themselves do not necessarily have to be the same in order to run the signature generation scheme. For example, if there is a group of six people and three are needed to create the signature and / or secret key, the participants could perform the calculation such that, strictly speaking, the threshold for k is 4 and the threshold for the other shared secrets is 3, and still have a threshold-optimal scheme.

[0161] It should be noted that the present invention may be applied to any threshold signature scheme (whether optimal or not) and is not limited to the example shown in Figure 4 above.

[0162] In general, embodiments of the present invention can be used to generate signatures for arbitrary messages. In a particular exemplary use case, as shown in Figure 1, the message may be part or all of a blockchain transaction. That is, a signature may be used to sign one or more inputs and / or one or more outputs of a blockchain transaction. For example, a generated signature may be used at least in part to unlock an output of a blockchain transaction. In a particular example, the output of a previous transaction may be a pay-to-public-key-hash (P2PKH) output that is locked to a hash of a public key. For the lock to be released, the input of a subsequent transaction referencing the P2PKH output must include a (unhashed) public key and a signature generated based on the private key corresponding to the public key. Coordinator 104 may sign the blockchain transaction and submit the signed transaction to one or more blockchain nodes of the blockchain network 106.

[0163] In script form, "locking scripts" and "unlocking scripts" may take the following forms: Locking script = OP_DUP OP_HASH160<Public KeyHash> OP_EQUAL OP_CHECKSIG Unlocking script = <signature><Public Key>

[0164] Referring to the embodiments described above,<Public Key> P = a child • May be equal to G, <signature>includes a threshold signature s, where the previous transaction is the message to be signed. Note that, as described above, an ECDSA signature is in the form of (r, s).

[0165] Note that the described signature generation method is not limited to any specific use case and may be widely used to generate signatures based on any message. Signing all or part of a blockchain transaction is merely an example for illustration purposes. The described method may be used, for example, to sign and / or authenticate legal documents (such as wills, certificates, or other contracts), correspondence between one or more parties (such as digital certificates issued by a certification authority), prescriptions, bank transfers or financial products, mortgage loans or loan applications, etc.

[0166] As a specific example, a group of participants (such as a total of five participants) may form a company's board of directors. The company's resolutions may require a majority of the board of directors (i.e., at least three participants) to agree to a specific resolution. The board of directors may use the described signature generation method to prove that at least three directors have agreed to vote in favor of a specific result. In this example, the threshold of the signature generation method is 3. That is, in order for the coordinator to generate a signature normally, at least three of the directors must each provide their signature shares. If the signature is created normally, at least the threshold number (i.e., three) of directors must have agreed to vote in favor of the result. Therefore, the normal generation of the signature serves as a record of the resolution and proves that a majority of the board of directors has voted in a specific manner.

[0167] Another use case of the present invention lies in the field of digital certificates, for example, digital certificates issued under the X.509 standard. A digital certificate contains a signature that signs some data. The data can generally be any data, but one particular example of data included in a digital certificate is a public key. The public key in a digital certificate is often called a “certified public key.” The issuer of a digital certificate (a “certificate authority”) may perform one or more checks on the owner of the public key (for example, a know-your-customer check), and if the checks pass, the certificate authority issues a digital certificate containing the certified public key. For example, by signing a message with a private key that corresponds to a certified public key, a user can use the certified public key to prove that they are the person claiming to be that person. One specific use of a certificate authority is signing certificates used in HTTPS for secure browsing on the internet. Another common use is for national governments to issue identity cards for use when digitally signing documents. A Certificate Authority (CA) uses its private key to sign a public key (or any other data that is being verified).

[0168] As described above, embodiments of the present invention may include encrypting a message with a public key corresponding to a private key share and similarly decrypting the message with a private key share. In this case, a first participant 102a may decrypt a message encrypted by a different participant. Alternatively, the message may be encrypted with a public key corresponding to a complete private key, for example, a complete child key. In this case, at least a threshold number of participants may make their respective shares of the child private key available to decrypt the message. The message to be encrypted may include part or all of a blockchain transaction, for example, the encrypted data may be included in the transaction so that it is recorded on the blockchain.

[0169] conclusion Other variations or use cases of the disclosed technology will become apparent to those skilled in the art if the disclosure herein is given. The scope of this disclosure is not limited by the embodiments described herein, but is limited only by the appended claims.

[0170] It will be understood that the embodiments described above are merely illustrative. More broadly, methods, apparatus, or programs may be provided by one or more of the following statements.

[0171] Statement 1. A method performed by a computer to generate a digital signature for signing a message, wherein each participant in a group of participants has a private key share of a shared private key, and the shared private key can only be generated with at least a threshold number of each private key share, and each participant is associated with their respective participant index, and the method is performed by a coordinating party. A step of obtaining at least a threshold number of signature shares, wherein each signature is generated by each participant based on their respective private key share, A step of obtaining, for each of each signature share, the respective commitment for each signature share, wherein each commitment was generated by the respective participant who generated each signature share. A step of generating a Merkle tree, wherein each leaf node of the Merkle tree, at least a threshold number of them, contains the respective hash of each signed commitment combined with its respective participant index, and each participant index is associated with the respective participant who generated its respective signed commitment. A step of generating a signature based on each signature share of at least a threshold number, The steps include making the Merkle root of the Merkle tree available to at least each participant who generated their respective signature share, and Methods that include...

[0172] Statement 2. The method according to Statement 1, comprising the step of sending a Merkle certificate to each participant who generated each signature share, wherein each Merkle certificate is based on each leaf node of a Merkle tree generated based on each participant index associated with that participant.

[0173] Statement 3. The method of Statement 1 or Statement 2, wherein making the Merkle root available includes at least sending the Merkle root to each participant who generated each signed share.

[0174] Statement 4. Making the Merkle root available includes submitting a first blockchain transaction to the blockchain network, and the blockchain network includes the Merkle root in any of the methods of the aforementioned statements.

[0175] Statement 5. A method of any of the aforementioned statements, which includes the step of making the Merkle root available before performing the aforementioned generation of the signature.

[0176] Statement 6. Each signature share is based on a message including Merkle's root, in the manner of Statement 5.

[0177] Statement 7. Each signature share's respective commitment, including each signature share, in any of the aforementioned statements.

[0178] Statement 8. Each participant has a respective share of the shared ephemeral secret key, the first coordinate of the ephemeral public key corresponding to the shared ephemeral secret key, and each share of the message-independent component MIC of each signature share, where each share of the MIC is generated based on the respective share of the ephemeral secret key, the respective share of the secret key, and the first coordinate of the ephemeral public key, and the respective commitment for each signature share is based on the respective share of the ephemeral secret key, the first coordinate of the ephemeral public key, each share of the MIC, and the generator point of the elliptic curve, in any of the methods of Statements 1 to 6.

[0179] Statement 9. The method of any of the foregoing statements, where the message includes at least a part of the second blockchain transaction.

[0180] Statement 10. The methods of Statements 4, 8, and 9, where the first blockchain transaction is the second blockchain transaction.

[0181] Statement 11. A method implemented by a computer for proving that the first participant in a group of participants generated each signature share of a digital signature for signing a message, where each participant in the group has a respective share of the shared secret key, and the shared secret key can be generated only with at least a threshold number of the respective secret key shares, each participant is associated with a respective participant index, and the method generating a first signature share based on the first secret key share and the message; generating a first commitment for the first signature share; A step of providing the coordinating parties with a) a first signature share and b) a first commitment in order to generate a) signatures based on at least a threshold number of signature shares and b) a Merkle tree, wherein each leaf node of the Merkle tree, at least a threshold number of, contains a hash of each signature commitment combined with each participant index, and each participant index is associated with each participant that generated each signature commitment. Steps to obtain the Merkle root of a Merkle tree, A step of obtaining a Merkle proof based on each leaf node of a Merkle tree generated based on each participant index associated with the first participant, The steps include verifying that leaf nodes of a Merkle tree having a Merkle root were generated based on a first commitment and a first participant index, thereby verifying that the coordinating party generated signatures based on a first signature share, by providing the verifying party with at least a Merkle proof, a first commitment, and a first participant index, and Methods that include...

[0182] Statement 12. The Statement 11 method includes a step of providing the Merkle route to the parties verifying it.

[0183] Statement 13. The method of obtaining the Merkle root as described in Statement 11, which includes receiving the Merkle root from the coordinating party.

[0184] Statement 14. The method of statement 11, wherein a first blockchain transaction stored on the blockchain includes a Merkle root, and the acquisition of the Merkle root includes acquiring the Merkle root from the blockchain.

[0185] Statement 15. A method of a message containing a Merkle root in statement 11 or any statement that is subordinate to statement 11.

[0186] Statement 16. The first commitment of the first signed share is a method of statement 11 or any statement subordinate to statement 11, which includes the first signed share.

[0187] Statement 17. Each participant has a temporary private key share of the shared temporary private key, a first coordinate of the temporary public key corresponding to the shared temporary private key, and a share of the message-independent component MIC of their respective signature share, where each share of the MIC is generated based on their respective temporary private key share, their respective private key share, and the first coordinate of the temporary public key, and the first commitment of the first signature share is based on the first temporary private key share, the first coordinate of the temporary public key, the first share of the MIC, and the generator of the elliptic curve, in any way of statements 11 to 15.

[0188] Statement 18. A method of statement, either statement 11 or a statement subordinate to statement 11, wherein the message includes at least a portion of a second blockchain transaction.

[0189] Statement 19. The first blockchain transaction is the second blockchain transaction, as described in statements 14, 17, and 18.

[0190] Statement 20. Memory including one or more memory units, A computer device comprising one or more processing units, wherein memory stores code arranged to be executed on the processing unit, and the code is configured to execute any of the methods of statements 1 to 19 when it is on the processing unit.

[0191] Statement 21. A computer program that is implemented on computer-readable storage and configured to execute one of the methods of statements 1 through 19 when executed on one or more processors.

[0192] Another aspect disclosed herein may provide a method that includes actions of the coordinating party and the first participant.

[0193] In other embodiments disclosed herein, a system may be provided that includes computer equipment of the coordinating parties and the first participant. [Explanation of Symbols]

[0194] 100 Systems 101 Adjuster 102 Stakeholders and Participants 102a First participant 102b Second participant 102c Third participant 104. Parties involved in coordination, coordinators 106 Blockchain Networks 300 ways 400 ways< / signature> < / signature>

Claims

1. A computer-based method for generating a digital signature to sign a message, wherein each participant in a group of participants has a private key share of a shared private key, and the shared private key can only be generated with at least a threshold number of each private key share, and each participant is associated with their respective participant index, and the method is performed by a coordinating party. A step of obtaining at least the number of signature shares of the threshold, wherein each signature is generated by each participant based on each private key share, A step of obtaining, with respect to each of the aforementioned signature shares, the respective commitment for each of the aforementioned signature shares, wherein the respective commitment was generated by the respective participant who generated the respective signature share. A step of generating a Merkle tree, wherein each of at least a threshold number of leaf nodes in the Merkle tree includes a hash of each signed commitment combined with each participant index, and each participant index is associated with the respective participant who generated each signed commitment; A step of generating the signature based on each of the number of signature shares of at least the thresholds, The steps include making the Merkle root of the Merkle tree available to at least each of the participants who generated their respective signature shares. Methods that include...

2. The method according to claim 1, comprising the step of sending a Merkle certificate to each participant who generated each signature share, wherein each Merkle certificate is based on the respective leaf node of the Merkle tree generated based on the respective participant index associated with each participant.

3. The method according to claim 1, wherein making the Merkle root available includes, at least, sending the Merkle root to each of the participants who generated their respective signature shares.

4. The method according to claim 1, wherein making the Merkle route available includes submitting a first blockchain transaction to a blockchain network, and the blockchain network includes the Merkle route.

5. The method according to claim 1, comprising the step of making the Merkle root available before performing the generation of the signature.

6. The method according to claim 5, wherein each of the aforementioned signature shares is based on a message including the Merkle route.

7. The method according to claim 1, wherein each of the commitments of each of the signature shares includes each of the signature shares.

8. The method according to claim 1, wherein each participant has a respective temporary private key share of a shared temporary private key, a first coordinate of a temporary public key corresponding to the shared temporary private key, and a respective share of the message-independent component MIC of the respective signature share, the respective share of the MIC being generated based on the respective temporary private key share, the respective private key share, and the first coordinate of the temporary public key, and the respective commitment of the respective signature share being based on the respective temporary private key share, the first coordinate of the temporary public key, the respective share of the MIC, and the source of the elliptic curve.

9. The method according to claim 1, wherein the message includes at least a portion of a second blockchain transaction.

10. A computer-based method for verifying that a first participant in a group of participants has generated each signature share of a digital signature for signing a message, wherein each participant in the group has each private key share of a shared private key, the shared private key can only be generated in at least a threshold number of each private key share, and each participant is associated with their respective participant index, and the method is A step of generating a first signature share based on a first private key share and the message, The steps include generating a first commitment for the first signature share, A step of providing the coordinating parties with a) the first signature shares and b) the first commitment in order to generate a) signatures based on each of the threshold number of signature shares and b) a Merkle tree, wherein each of the threshold number of leaf nodes in the Merkle tree includes each hash of each signature commitment combined with each participant index, and each participant index is associated with each participant that generated each signature commitment. The step of obtaining the Merkle root of the Merkle tree, A step of obtaining a Merkle proof based on each leaf node of the Merkle tree generated based on the first participant index associated with the first participant, The steps include: verifying that the leaf node of the Merkle tree having the Merkle root was generated based on the first commitment and the first participant index, and thereby verifying that the coordinating party generated the signature based on the first signature share, by providing the verifying party with at least the Merkle proof, the first commitment and the first participant index; Methods that include...

11. The method according to claim 10, comprising the step of providing the Merkle route to the person being verified.

12. The method according to claim 10, wherein obtaining the Merkle route includes receiving the Merkle route from the coordinating party.

13. The method according to claim 10, wherein a first blockchain transaction stored on the blockchain includes the Merkle root, and obtaining the Merkle root includes obtaining the Merkle root from the blockchain.

14. The method according to claim 10, wherein the message includes the Merkle route.

15. The method according to claim 10, wherein the first commitment of the first signature share includes the first signature share.

16. The method according to claim 10, wherein each participant has a respective temporary private key share of a shared temporary private key, a first coordinate of a temporary public key corresponding to the shared temporary private key, and a respective share of a message-independent component MIC of the respective signature share, the respective share of the MIC being generated based on the respective temporary private key share, the respective private key share, and the first coordinate of the temporary public key, and the first commitment of the first signature share being based on the first temporary private key share, the first coordinate of the temporary public key, the first share of the MIC, and the source of the elliptic curve.

17. The method according to claim 10, wherein the message includes at least a portion of a second blockchain transaction.

18. The method according to claim 16, wherein a first blockchain transaction stored on the blockchain includes the Merkle root, obtaining the Merkle root includes obtaining the Merkle root from the blockchain, the message includes at least a portion of a second blockchain transaction, and the first blockchain transaction is the second blockchain transaction.

19. Memory including one or more memory units, A processing apparatus comprising one or more processing units, wherein the memory stores code arranged to be executed on the processing apparatus, and the code is configured to perform the method described in any one of claims 1 to 18 when it is on the processing apparatus. Computer equipment, including...

20. A computer program that is embodied on computer-readable storage and configured to perform the method described in any one of claims 1 to 18 when executed on one or more processors.

Images