(EC)DSA Threshold Signature with Secret Sharing

Abstract

A computer-implemented method for generating shares of a digital signature for a message, wherein a threshold number of different signature shares from each participant of a group of participants are required to generate the digital signature, each participant having a respective private key share, the method being executed by a first of the participants and comprising: generating a first message-independent component and a first message-dependent component, wherein the message-independent component is generated based on the first private key share and the message-dependent component is generated based on the message; making the first message-independent component available to a coordinator; and making the first signature share available to the coordinator for generating a signature based on at least the threshold number of signature shares, wherein the first signature share comprises at least the message-dependent component.

Description

Technical Field

[0001] The present disclosure relates to a method for generating shares of a digital signature of a message, and a method for generating a digital signature of a message using the signature shares.

Background Art

[0002] Public key cryptography is a type of cryptographic system that uses a pair of keys, namely, a private key known only to the owner of the private key and a public key that is generated based on the corresponding private key and can be distributed without compromising the security of the private key.

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

[0004] Similarly, a sender can sign a message using the sender's own private key, for example, to prove that the message is being sent by the sender and / or to indicate that the sender agrees to the message. The signer (i.e., the party generating the signature) creates a digital signature for the message using the signer's private key. Anyone having the corresponding public key of the signer can use the same message and the digital signature in the message to verify whether the signature was created validly, i.e., whether the signature was indeed created using the signer's private key.

[0005] Digital signature schemes typically involve three procedures, namely, algorithms. A key generation algorithm is used to generate a random private key and the corresponding public key. A signature algorithm is used to generate a signature based on the message and the private key. A verification algorithm is used with the public key and the message to verify whether the signature was generated according to the signature algorithm using the corresponding private key.

[0006] The threshold signature scheme enables a threshold number of participants in a group to create a digital signature for (or on) a message using their respective shares of a shared secret key. Here, the digital signature is a signature generated based on the message to be signed. In such a scheme, a signature can only be created if a threshold number of participants agree to generate a signature for the message. Any attempt to generate a signature using fewer participants will not produce a valid signature. Thus, a valid signature by the group (i.e., a signature generated using the message and the shared secret key) proves that a threshold number of people have agreed to generate the signature. This also implies that any attacker needs to obtain a threshold number of shares of the secret key in order to forge a signature using the secret key.

[0007] A common feature of threshold signature shares is that the secret key can still be recoverable if any of the secret key shares are lost, provided that a threshold number of shares remain available.

[0008] One particular digital signature algorithm is the Elliptic Curve Digital Signature Algorithm (ECDSA). There are two common threshold schemes for ECDSA signatures. One threshold ECDSA scheme is the non-optimal scheme, where the group collectively owns a shared secret key with a threshold of t + 1, but creating a signature requires a larger threshold of 2t + 1. For a detailed explanation, see Gennaro, R et al., "Robust threshold DSS signatures", International Conference on the Theory and Applications of Cryptographic Techniques, Springer, Berlin, Heidelberg, 1996. This scheme is hereinafter referred to as the "non-optimal Gennaro scheme".

[0009] The other common threshold ECDSA scheme is the optimal scheme, where optimal means that the threshold for creating a signature is the same as the threshold of the shared secret key. For a detailed explanation, see Gennaro, R and Goldfeder, S., "Fast multiparty threshold ECDSA with fast trustless setup", Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018. This scheme is hereinafter referred to as the "optimal Gennaro scheme".

Prior Art Documents

Patent Documents

[0010]

Patent Document 1

Non-Patent Documents

[0011]

Non-Patent Document 1

Non-Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0012] The advantage of the non-optimal Gennaro method is that it is efficient from both the perspectives of computation and communication rounds. The disadvantage is that the threshold for creating the private key is smaller than the threshold for generating the digital signature. The problem associated with this is that it is not possible to be certain that the required number of threshold participants have signed together. That is, since the signature can be computed using the private key, a smaller number of participants than the threshold for generating the signature can, together, sign the message using the private key and without using threshold signatures. For example, the threshold for generating the private key could be 2, and the threshold for generating the signature could be 3. In that case, two people can create the private key and thus generate the signature, thus avoiding the requirement that three people are needed to generate the threshold signature.

[0013] In contrast, the advantage of the optimal Gennaro scheme is that there is no gap in the threshold for generating the private key and the signature. However, in this scheme, the number of computation and communication rounds is much larger, the creation of the signature is much slower, and this scheme does not scale well.

[0014] Therefore, a threshold ECDSA scheme that has the optimality of an optimal threshold such as the optimal Gennaro scheme while having the computational, memory, and communication advantages of the non-optimal Gennaro scheme is desirable.

Means for Solving the Problem

[0015] According to one aspect disclosed in this specification, a computer-implemented method for generating shares of a digital signature of a message is provided, where different numbers of threshold signature shares from each participant in a group of participants are required to generate a digital signature, each participant has its own private key share, the method is executed by a first participant among the participants, and includes generating a first message-independent component and a first message-dependent component, where the message-independent component is generated based on the first private key share and the message-dependent component is generated based on the message; making the first message-independent component available to a coordinator; and making a first signature share available to the coordinator for generating a signature based on at least the threshold number of signature shares, where the first signature share includes at least the message-dependent component.

[0016] According to another aspect disclosed in this specification, a computer-implemented method for generating a digital signature of a message is provided, where a threshold number of different signature shares from each participant in a group of participants is required to generate the digital signature, each participant has its own secret key share, and the method is executed by a coordinator and includes obtaining at least a threshold number of each message-independent component, where each message-independent component is generated based on its own secret key share, obtaining at least a threshold number of each signature share, where each signature share is based on at least its own message-dependent component, and each message-dependent component is generated based on the message, and generating a signature of the message based on each of the obtained signature shares and each of the obtained message-independent components.

[0017] For the purpose of assisting in the understanding of the embodiments of the present disclosure and showing how such embodiments can be implemented, reference is made to the accompanying drawings by way of example only.

Brief Description of the Drawings

[0018]

Figure 1

Figure 2

Figure 3

Modes for Carrying Out the Invention

[0019] Preface Elliptic Curve Group The elliptic curve E satisfies the equation y 2 =x 3 +ax + b mod p where a, b ∈ Zp where a, b are constants satisfying 4a 3 + 27b 3 ≠ 0. The group on this elliptic curve is defined as the set of elements (x, y) that satisfy this equation, together with the point at infinity O which is the identity element. The group operation on the elements of this group is called elliptic curve point addition and is denoted by +. This group is denoted by E(Z p ) and its order is denoted by n.

[0020] This group operation can be used to define another operation on the elements, called point multiplication, denoted by ·. For a point G ∈ E(Z p ) and a scalar

[0021]

Number

[0022] k, the point k·G is defined to be the point G added to itself k times.

[0023] In elliptic curve cryptography, the private key is defined as a scalar k ∈ Z n \{0}, where Z n \{0} is 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 chosen to be secp256k1, and the values of a, b, and p are fully specified by this curve. The order n of this group is calculated given these values, and in the case of this curve these values are prime numbers, and the secp256k1 standard also specifies the point G that will be used as the generator of this group.

[0024] Elliptic Curve Digital Signature Algorithm To create a signature for a message msg using the private key a, the following steps are performed.

[0025] 1. Calculate the message digest e = hash(msg), which 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 more than twice using the same or different hash functions.

[0026] 2. Select a random integer k ∈ {1,..., n - 1}, where n is the order of an elliptic curve, such as the secp256k1 curve. Hereinafter, k is called the ephemeral private key.

[0027] 3. Calculate the ephemeral public key corresponding to this ephemeral private key k·G = (R x , R y ).

[0028] 4. Calculate r = R x mod n. If r = 0, return to step 2.

[0029] 5. Calculate the multiplicative inverse k -1 mod n of the ephemeral key.

[0030] 6. Calculate s = k -1 (e + ar) mod n. If s = 0, return to step 2.

[0031] 7. The signature for the message msg is (r, s).

[0032] The ephemeral key must be kept secret; otherwise, the private key can be calculated given the message and the signature. Additionally, a different ephemeral key must be used each time a signature is generated. If this is not the case, it is possible to derive the private key a given two different signatures and their corresponding messages.

[0033] Given a message msg, a public key P = a·G, and a corresponding signature (r, s), the signature can then be verified by completing the following steps.

[0034] 1. Compute the message digest e = hash(msg), for example, e = SHA256(SHA256(msg)).

[0035] 2. Compute the multiplicative inverse s -1 of s modulo n.

[0036] 3. Compute j1 = es -1 mod n and j2 = rs -1 mod n.

[0037] 4. Compute the point Q = j1·G + j2·P.

[0038] 5. If Q = O, i.e., the point at infinity, the signature is invalid.

[0039] 6. If Q ≠ O, then set Q := (Q x , Q y ) and compute u = Q x mod n. If u = r, the signature is valid.

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

[0041] Joint Verifiable Random Secret Sharing Assume that N participants wish to create a joint secret that can be regenerated only by at least (t + 1) of the participants in this scheme. To create the shared secret, the following steps are performed.

[0042] 1. The participants agree on a unique label \(i\) for each participant. Each participant \(i\) generates \((t + 1)\) random numbers a ij ∈ R Z n \{0\}, ∀j = 0, ..., t where ∈ R means a randomly generated element of the set \(Z\) n \{0\}, and here \(Z\) n \{0\} is the notation for the set \(\{1, ..., n - 1\}\). Then each participant has a secret polynomial f i (x)=a i0 +a i1 x+...+a it x t mod n of degree \(t\) for \(i = 1, …, N\). Note that we will henceforth omit the mod \(n\) notation and assume that all arithmetic operations on integers are performed modulo \(n\).

[0043] 2. Each participant \(i\) sends the value \(f\) i (j) to participant \(j\) using, for example, a secure communication channel only with participant \(j\).

[0044] 3. Each participant \(i\) calculates its own personal secret share of the shared secret polynomial

[0045]

Number

[0046] as

[0047] The shared secret share is in the form \((i, a\) i [[ID=[]8]]) where \(i\) is the participant label in this scheme. This method of creating the secret share of \(a\) as described in steps 1 - 3 is herein referred to as \(a\) i=It is shown by JVRSS(i). Note that "JVRSS" usually represents "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 to 3, where Steps 4 and 5 are optional steps.

[0048] Once the participants have generated the shared polynomial, each participant can verify that each other participant has shared the correct information for all participants and that all participants have the same shared polynomial. This is done in the following way.

[0049] 4. For each participant i and for k = 0,..., t, the blinding factor a ik ·G is broadcast to all participants.

[0050] 5. Each participant i calculates f j (i)·G and

[0051]

Number

[0052] By verifying that it is, each participant j checks that each other participant has correctly calculated the polynomial point f j (i).

[0053] If all participants find that this equation holds for each polynomial, the group can collectively be confident that all participants have created the same shared polynomial.

[0054] Reconstruction of the Shared Secret Assume that the participants wish to reconstruct the shared secret a which is the 0 - th degree of the shared polynomial. The form (1,a1),...,((t + 1),a t+1 ) Given (t + 1) points on this polynomial, then, to find the shared secret a, it is derived from a general formula called "Lagrange interpolation"

[0055]

Number

[0056] to calculate.

[0057] Public key calculation Given the N zero-degree secret polynomial coefficient public keys a for i = 1,..., N shared in step 4 of JVRSS i0 ·G, each participant uses the

[0058]

Number

[0059] corresponding to the shared secret a to calculate the shared public key P.

[0060] Addition of shared secrets To calculate the addition of two shared secrets shared among a group of N participants where each secret polynomial has degree t, without any entity knowing the individual secrets, the following steps are performed.

[0061] 1. Generate the first shared secret a, where the share of participant i is a for i = 1,..., N using the threshold (t + 1) i = given by JVRSS(i).

[0062] 2. Generate the second shared secret b, where the share of participant i is b i = given by JVRSS(i) using the threshold (t + 1).

[0063] 3. Each participant i uses their additive share νi = a i + b i mod n Compute it.

[0064] 4. All participants broadcast their additive share ν i to all other participants.

[0065] 5. Each participant interpolates over at least (t + 1) of the shares ν i to compute ν = interpolate(ν1,..., ν t+1 ) = a + b This method for the addition of the shared secret is denoted by ADDSS(i) for participant i, and as a result, each participant i knows ν = (a + b).

[0066] Product of shared secrets

[0067] To compute the product of two shared secrets, both of which are shared among a group of N participants where each secret polynomial has degree t, the group performs the following steps.

[0068] 1. Generate a first shared secret a, where the share for participant i is given by a i = JVRSS(i) for i = 1,..., N. This means that the shared secret polynomial has degree t and (t + 1) participants are required to recreate it.

[0069] 2. Generate a second shared secret b, where the share for participant i is given by b i = JVRSS(i), and the shared secret polynomial again has degree t.

[0070] 3. Each participant computes their multiplicative share μ μ i = a i b i using i to compute their multiplicative share μ

[0071] 4. All participants broadcast their multiplicative share μ i to all other participants.

[0072] 5. Each participant interpolates over at least (2t + 1) of the shares μ i to compute μ = interpolate(μ1,..., μ 2t+1 ) = ab .

[0073] This method for computing the product of two shared secrets is denoted herein as μ = ab = PROSS(i) for participant i.

[0074] Inverse of the shared secret To compute the inverse of the shared secret a, the following steps are performed.

[0075] 1. All participants compute the product of the shared secrets PROSS(i), the result of which is μ = ab mod n.

[0076] 2. Each participant computes the modular inverse of μ, which is μ -1 = (ab) -1 mod n .

[0077] 3. Each participant i computes

[0078]

Number

[0079] to compute its inverse secret share.

[0080] This method for computing the inverse of the shared secret is, for participant i,

[0081]

Number

[0082] is indicated by.

[0083] Generation and Verification of Shared Secret Key To compute a shared secret key a among N ≥ 2t + 1 participants, t + 1 of them are required to create a signature, and the participants execute JVRSS using the threshold t + 1 and public key computation as described above. The result is that all participants i = 1,..., N have the secret key share a i and the corresponding shared public key P = (a·G).

[0084] Ephemeral Key Share Generation To generate the ephemeral key shares and the corresponding r as required in the signature, a group of size N with a shared secret key a of threshold (t + 1) executes the following steps.

[0085] 1. Inverse Share of Shared Secret

[0086]

Number

[0087] is generated, where (t + 1) shares are required to recreate it.

[0088] 2. Each participant uses the obfuscation factor shared in the verification of k i to compute

[0089]

Number

[0090] and then computes r = x mod n to compute.

[0091] 3. Each participant i stores

[0092]

Number

[0093] .

[0094] Threshold optimal signature Figure 1 shows an exemplary system 100 for implementing a threshold optimal signature scheme, such as a threshold optimal ECDSA scheme. As shown, system 100 includes a plurality of parties, including a coordinator 101 and a group of participants 102. Although only three participants 102 are shown in Figure 1, it will be understood that in general the system may include any number of participants. Further, although the coordinator 101 is shown as distinct from the participants 102 in Figure 1, in some embodiments, the coordinator 101 may also be one of the participants 102, for example, the first participant 102a. Each of the coordinator 101 and the participants 102 operates a respective computing device.

[0095] Each of the respective computing devices of each of the parties of system 100 (i.e., coordinator 101 and participant 102) comprises a respective processing device comprising one or more processors, such as one or more central processing units (CPUs), accelerator processors (GPUs), application-specific processors, and / or field programmable gate arrays (FPGAs). Each computing device may also comprise a memory, i.e., computer-readable storage in the form of one or more non-transitory computer-readable media. The memory may comprise 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 disk drives. Each computing device may comprise at least one user terminal, such as a desktop computer or laptop computer, tablet, smartphone, or wearable device such as a smartwatch. Alternatively or additionally, each computing device may comprise one or more other networked resources, such as cloud computing resources (resources of one or more physical server devices implemented at one or more sites) accessible via the user terminal. It will be understood that any act described as being performed by a party of system 100 may be performed by each respective computing device operated by that party.

[0096] The coordinator 101 is the party that starts the signing using the threshold number of signature shares generated by each of the participants in the group of participants 102. That is, the coordinator 101 generates a signature for the message to be signed. Again, it should be noted that generating a signature for a message means that the signature depends on the message to be signed, or in other words, the signature is a function of the message to be signed. The coordinator 101 may also be the party that sends the signature and optionally the message to a third party 103, or otherwise outputs the signature. For example, the third party 103 may be a certification authority, or another form of authority, or another user. In other examples, the signature may be recorded, for example, in a database or other document. In some examples, the signature may be made public, for example, recorded on a website or other medium accessible to the general public.

[0097] The coordinator 101 may send the message to be signed to the participants 102. The message may be sent to all of the participants 102, or to a subset of the participants, for example, the threshold number of participants. In the example of FIG. 1, the group of participants comprises three participants 102a, 102b, 102c. The coordinator 101 may send the message to one participant, who then forwards the message to one, some, or all of the other participants.

[0098] The message may be sent via the Internet using a LAN connection or a WAN connection, or via alternative wired or wireless communication means. The message may be sent individually to each participant 102 via, for example, a secure communication channel between the coordinator 101 and each participant 102, or may be broadcast to the group as a whole via, for example, email or other means. The message may be sent in raw form or in encrypted form. For example, the message may be hashed one or more times.

[0099] One or more of the participants 102 may obtain the message via alternative means, i.e., not from the coordinator 101. For example, the message may be generated by one of the participants 102 or, alternatively, may be generally available, e.g., to the public. One or more of the participants 102 may receive the message from a third party 103. The participant 102 obtaining the message may send the message (in raw or encrypted form) to one or more other participants 102. For example, a first participant 102 may send the message to a second participant 102b and / or a third participant 102c.

[0100] The coordinator 101 obtains (e.g., receives) a threshold number of signature shares. In the example of FIG. 1, the threshold is 2, and only the first participant 102a and the second participant 102b decide to generate their respective signature shares. For example, one or more of the participants 102 generating the signature shares may send their respective shares directly to the coordinator 101, e.g., via a secure communication channel. Alternatively, one or more of the participants 102 may broadcast their respective shares and / or make their shares generally available. As described above, the coordinator 101 may also be a participant. In those embodiments, the coordinator 101 may also generate its respective signature share. In that sense, obtaining at least one of the threshold number of signature shares means generating at least one signature share, and thus the coordinator 101 need only receive fewer signature shares than the threshold number of signature shares.

[0101] To obtain the signature shares, the coordinator 101 may send a request for signature shares for the message. For example, the coordinator 101 may send the request for signature shares to one, a portion, or all of the group of participants 102.

[0102] When the coordinator 101 has obtained at least a threshold number of signature shares, it generates a signature using the obtained shares. The coordinator 101 may then broadcast or transmit the signature to one or more other entities. Additionally or alternatively, the coordinator may store the signature and / or record the signature as part of a digital record, for example, in an email or other document.

[0103] Signature share s i A method for generating is described herein. The method is described from the perspective of the first participant 102a, but it will be understood that each other participant 102 that generates a signature share does so using an equivalent method, even if such other participant 102 uses some data specific to that other participant 102.

[0104] Each participant 102 has access to the following data items, namely, their respective secret key share a i (i.e., a share of the same secret key), their respective ephemeral secret key share k i , and a shared common value r generated based on the common ephemeral public key k·G. The common ephemeral public key corresponds to the ephemeral secret key, i.e., it is generated based on the ephemeral secret key. Here, a value or key may be common in the sense that each participant has access to the same value or key. Note that, unless otherwise specified, generating a second key based on a first key does not necessarily imply that the first key itself is known. Examples of how these data items may be generated are provided below.

[0105] The first participant 102a obtains the message to be signed or already has access to the message to be signed. The message may be in its raw form (e.g., plaintext) or in an encrypted or otherwise encoded form (e.g., ciphertext). The first participant 102a may obtain the message (in any form) from the coordinator and / or from another participant 102. Alternatively, the first participant 102a may generate the message to be signed.

[0106] The first participant 102a generates a first signature share s1. The "first" in this context is only used as an arbitrary label to distinguish a particular participant and a particular signature share from other participants and signature shares, and does not necessarily imply that the first participant 102a is the first participant to generate the signature share s i or that the first signature share s1 is the first in an ordered list of signature shares s i It should be noted that this is not necessarily implied.

[0107] In some embodiments, the first signature share s1 may be generated based on a first message-independent component (MIC) and a first message-dependent component (MDC), i.e., it is a function of them, where again the "first" is only used as a label. The MIC is generated independently of the message. That is, the MIC is not a function of the message to be signed (i.e., the MIC is not generated based on the message), and knowledge of the message is not required to generate the MIC. In contrast, the MDC is a function of the message to be signed, and knowledge of the message is required to generate the MDC.

[0108] In other embodiments, the first signature need not be a function of the first message-independent component (MIC). In these embodiments, the first message-independent component is generated and made available to the coordinator 101, for example, by being sent to the coordinator 101 or broadcast to one or more participants 102. The first message-independent component (MIC) may be shared with the coordinator prior to, and separately from, the first signature share.

[0109] The coordinator 101 may obtain each message-independent component (MIC) from at least a threshold number of participants and generate a signature based on each signature share (which is a function of each message-dependent component (MDC)) and each message-independent component (MIC). More details are provided below.

[0110] Since the MIC does not require knowledge of the message, the MIC can be pre-computed. In other words, the MIC can be generated before obtaining the message. Thus, multiple different MICs can be pre-computed for use in generating different respective signature shares s1' for signing different messages, where the prime symbol (') indicates that it is a different instance of the first signature share.

[0111] When generating the first signature share s1, the first participant 102a makes the first signature share s1 available to the coordinator 101 for generating the signature s for the message. If the first participant 102a is the coordinator 101, making the first signature share s1 available to the coordinator 101 may simply mean outputting the first signature share s1 to a function for generating the signature s. Otherwise, the first participant 102a may send the first signature share s1 to the coordinator 101 or to one or more other participants 102 for forwarding to the coordinator 101, or may broadcast the first signature share s1, or may use a combination of these options.

[0112] As described above, the first signature share s1 can be generated based on the first MIC and the first MDC. Whether the first signature share is a function of the first MIC or not, the first MIC is generated based on (i.e., is a function of) the first secret key share a1 (i.e., the share of the secret key a known to the first participant 102a). The first MIC may also be based on the first ephemeral secret key share k1 (i.e., the share of the ephemeral secret key k known to the first participant 102a), and a shared value r generated based on the ephemeral public key k·G corresponding to the ephemeral secret key k. The first MDC is generated based on (i.e., is a function of) the message (in raw or encrypted form), and may also be generated based on the first ephemeral secret key share k1. Variations of the MIC and MDC are provided below.

[0113] Preferably, the first secret key share a1 may be calculated using a joint secret sharing method, for example, using the JVRSS technique described above. For example, the first participant 102a may have an index of 1, and may generate the first secret key share using a1 = JVRSS(1) for participant 1, where the secret key is denoted by a. Each participant may generate their respective secret key share a i For example, the second participant 102b may generate the second secret key share using a2 = JVRSS(2) for participant 2, and so on.

[0114] Generating the first secret key share a1 using a joint secret sharing method involves generating a set of numbers a 1j ∈ R Z n \{0}, ∀j = 0,..., t, and then the first polynomial f1(x) = a 10 + a 11 x +... + a 1t x tmay include generating mod n, where the set of numbers are the coefficients of the polynomial. Each of the other participants 102 generates their respective polynomial using their respective set of numbers. For example, the second participant 102b generates the second polynomial f2(x)=a 20 +a 21 x+...+a 2t x t mod n. The participant 102 then sends to each other participant the value of its respective function evaluated at the indexes of such other participants. For example, the first participant 102a evaluates f1(2) for the second participant 102b and then sends that value to the second participant 102b, evaluates f1(3) for the third participant 102c and then sends that value to the third participant 102c, and so on. The first participant 102a obtains the respective values generated by the other participants 102 as functions of the index of the first participant. The values may be sent via the Internet or via other means. The values may be sent via a respective secure communication channel between each pair of participants. Instead of sending directly, one or more participants 102 (e.g., the first participant 102a) may broadcast their respective values. When the first participant 102a has obtained at least a threshold number of values from at least a threshold number of participants, the first participant 102a generates a first secret key share based on the first value and each of the other data values obtained, such as f2(1), f3(1), etc.

[0115] The first participant may calculate the corresponding public key a·G based on the set of blinding factors, where the factors are used to generate the respective secret key share a i of each participant 102. That is, when generating the ephemeral secret key share k i , each participant 102 uses the blinding factor a ij·G can be shared with each other participant 102. The coefficients are obfuscated by a common generator point G on the selected elliptic curve. These obfuscated coefficients may be sent directly among the participants 102 or may be broadcast to the group. For example, the first participant 102a may broadcast the obfuscated coefficient a 10 ·G, a 11 ·G, a 12 ·G, etc. The public key corresponding to the private key can then be

[0116]

Number

[0117] calculated as.

[0118] The private key share a i It should be noted that it may be generated using an alternative method, i.e., without using the JVRSS method described above. Each participant requires a share of the private key a to generate their respective signature share s i However, the specific method for generating the private key share may be selected to suit a particular scenario, e.g., whether some of the participants can be trusted, whether all of the participants can be trusted, or whether none of the participants can be trusted, or whether a trusted dealer is available to distribute the key shares. Methods for generating shares of the private key are essentially known in the art. Similarly, methods for distributing shares of the private key (or other such data) are essentially known in the art. That being said, the private key share a i can be generated in several ways. For example, the Shamir's secret sharing scheme can be used, e.g., a dealer (e.g., a coordinator) can be used to generate and distribute one, some, or all of the private key shares a i One such scheme that can be used to generate and distribute the private key share a i is described in WO2017145010A1.

[0119] Similarly, when generating some or all of the private key shares described below, for example, the ephemeral private key share k i , the first blinding value key share α i , and / or the second blinding value key share β i , alternative forms of JVRSS may be used.

[0120] The first ephemeral private key share k1 can be calculated using a joint secret sharing method, for example, using the JVRSS technique described above. For example, the first participant 102a may have an index of 1, and may generate the first ephemeral private key share for participant 1 using k1 = JVRSS(1), where the ephemeral private key is denoted by k. Each participant 102 can generate their respective ephemeral private key share k i . For example, the second participant 102b may generate the second ephemeral private key share for participant 2 using k2 = JVRSS(2), and so on.

[0121] Generating the first ephemeral private key k1 share using a joint secret sharing method comprises the same steps described above for generating the first private key share a1, except that the random number used to generate the ephemeral private key share k1 is a different number compared to the random number used to generate the private key share a1.

[0122] The same private key a, and private key share a i are used for each signature, but note that the ephemeral private key k and ephemeral private key share k i change for each signature.

[0123] The shared value r is generated based on the ephemeral public key k·G corresponding to the ephemeral secret key k. The ephemeral public key (x, y) typically consists of two components, usually referred to as the x-component and the y-component. The shared value r may be a function of the x-component of the ephemeral public key, for example, r = x mod n.

[0124] The ephemeral public key k·G may be generated based on a set of obfuscation factors, where the factors are the respective ephemeral secret key shares k i used to generate for each participant 102. That is, when generating the ephemeral secret key share k i each participant 102 shares the obfuscation factor k ij ·G with each other participant 102. The factors are obfuscated by a common generator point G on the selected elliptic curve. These obfuscation factors may be sent directly among the participants 102 or broadcast to the group. For example, the first participant 102a may broadcast the obfuscation factors k 10 ·G, k 11 ·G, k 12 ·G, etc. The ephemeral public key is then

[0125]

Number

[0126] calculated as

[0127] In some embodiments, the first MIC is the first inverse share corresponding to the first ephemeral secret key share k1

[0128]

Number

[0129] generated based on. That is, the first inverse share

[0130]

Number

[0131] is a function of the first ephemeral secret key share k1.

[0132] The first inverse share

[0133]

Number

[0134] is, for example, for Participant 1

[0135]

Number

[0136] may be the inverse of the shared secret, generated by calculating, for example, for Participant 1. As described above, calculating the inverse of the shared secret comprises calculating the product of the shared secrets. The first participant 102a generates an intermediate value μ as the product of the first ephemeral secret key k and the first blinding key α. For example, the intermediate value may be calculated as μ = kα = PROSS(1) for Participant 1, and the result is μ = kα mod n.

[0137] This may involve each participant 102 generating a multiplicative share μ i = k i α i where α i is a share of the first blinding key α. Each participant 102 may calculate its own respective share α i of the first blinding key α using a joint secret sharing method, for example, the JVRSS technique described above. For example, the first participant 102a may have an index of 1 and generate a share of the first blinding key for Participant 1 using α1 = JVRSS(1). Each participant (e.g., via direct transmission or broadcast) its own respective multiplicative share μi are shared, and then an intermediate value μ is generated based on each of the multiplicative shares μ i for example, by interpolation. The first inverse share

[0138] [Number]

[0139] can be generated by calculating the multiplicative inverse of the intermediate value μ. For example, the first participant 102a may calculate the multiplicative inverse of μ, which is μ -1 =(kα) -1 mod n resulting in.

[0140] The first participant 102a then, for example

[0141] [Number]

[0142] calculates the multiplicative inverse μ -1 of the intermediate value and, based on its respective first blinding key share α1, the first inverse share

[0143] [Number]

[0144] may be calculated.

[0145] Note that the use of the blinding key share α i is optional and may be omitted from the above steps.

[0146] Optionally, the MIC can be generated (i.e., can be a function thereof) based on a share of a second blinding key β. That is, the MIC is also based on a first share β1 of the second blinding key β in addition to the data items described previously. The first share of the second blinding key can be computed using a secret sharing scheme, e.g., using the JVRSS technique described above. For example, the first participant 102a may have an index of 1 and may generate a first share of the second blinding key for Participant 1 using β1 = JVRSS(1), where the second blinding key is denoted by β.

[0147] The MIC may be generated based on a first pre-signature share σ1, where the first pre-signature share σ1 is a function of a first intermediate share λ1 and respective intermediate shares λ obtained from at least a threshold number of participants 102. i That is, each of the participants 102 may generate a respective intermediate share λ i and may send and / or broadcast those intermediate shares λ i to other participants 102. The first participant 102a may collect the intermediate shares λ i and may generate a common intermediate value λ, e.g., by interpolation of the intermediate shares λ i . The first participant 102a (and optionally other participants 102) may each generate a plurality of pre-signature shares σ1' for use in the generation of different signature shares s1'.

[0148] The first intermediate share λ1 can be a function of a first secret key share a1 and a first inverse share

[0149]

Number

[0150] and can be. In that case, each of at least a threshold number of participants 102 has its own respective secret key a i share and its own respective inverse share

[0151]

Number

[0152] Each intermediate share λ that is a function of i is generated and shared.

[0153] Alternatively, the first intermediate share λ1 may be a function of the first share of the first secret key share a1 and the first blinding key α1. In that case, each of at least a threshold number of participants 102 i generates and shares each intermediate share λ that is a function of its respective share of its own secret key share a i and its respective share of the first blinding key α1.

[0154] In some embodiments, the first pre-signature share σ1 may also be generated based on the first share of the second blinding key β1. For example, the first intermediate share λ1 may be a function of the first share of the second blinding key β1. In additional or alternative embodiments, the first intermediate share λ1 may also be a function of a common value r.

[0155] FIG. 2 shows an exemplary method 200 for generating a signature for a message, according to an embodiment of the present invention. Steps S201-S208 are each performed by a threshold number of participants 102 (including the first participant 102a) in this example. Step S209 is performed by the coordinator 101, and the coordinator 101 may also be one of the participants performing steps S201-S208. It will be appreciated that some of the steps may be omitted or performed in a different order.

[0156] The exemplary method 200 enables the creation of a threshold (t + 1) shared secret among a group of N ≧ 2t + 1 participants, where the threshold for signing is also (t + 1).

[0157] Setup In step S201, each participant 102 calculates a shared secret key share and a corresponding public key. For example, each participant 102 may calculate the shared secret key and the corresponding public key using the calculation of JVRSS and the public key given in the preamble. In this regard, each participant i has a secret key share and a public key (a i , P), where P is the notation for the public key corresponding to the shared secret key. The shared secret key has a threshold of (t + 1).

[0158] Pre - calculation In step S202, each participant 102 calculates a shared ephemeral key share and a corresponding public key. For example, each participant 102 may calculate the shared ephemeral key using the calculation of JVRSS and the public key given in the preamble. Each participant 102 may then calculate an inverse share based on the ephemeral secret key. This results in each participant having an inverse share

[0159]

Number

[0160] with a threshold of (t + 1).

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

[0162] In step S204, each participant 102 calculates an intermediate share and broadcasts its own intermediate share to other participants. For example, each participant i may calculate the intermediate share

[0163]

Number

[0164] . This value has a threshold of (2t + 1).

[0165] In step S205, each participant 102 calculates an intermediate value based on at least the intermediate shares. For example, each participant 102 may use the interpolation λ = interpolate(λ1,..., λ 2t+1 ) = k -1 a + β over (2t + 1) shares to calculate the intermediate value.

[0166] In step S206, each participant 102 calculates a pre-signature share. For example, each participant i may calculate its pre-signature share σ i = λ - β i =(k -1 a + β)-β i . Each participant 102 may

[0167]

Number

[0168] , as well as the secret key share and the corresponding public key (a i , P) for storage.

[0169] Note that since different ephemeral keys are used for each signature, multiple ephemeral keys can be set up at once, that is, steps S202 to S206 can be repeated to create multiple ephemeral keys during pre - calculation and stored for later use. These can be executed simultaneously so that there is no additional round of communication. Note that preferably different values of α and β should be used for each signature.

[0170] Signature Generation To sign the message msg, at least (t + 1) participants must execute steps S207 and S208.

[0171] In step S207, at least the threshold number of participants 102 obtain the message to be signed and calculate the message digest. For example, the coordinator 101 may send a request to (t + 1) participants to create signature shares for the message msg. Each participant i may calculate 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.

[0172] In step S208, at least the threshold number of participants 102 calculate the signature shares and send them to the coordinator 101. For example, each participant i may calculate its own signature share

[0173]

Equation

[0174] and then send its signature share (r, s i ) to the coordinator. Note that the value r may not be sent by all participants.

[0175] In step S209, the coordinator 101 calculates a signature. For example, the coordinator 101 may calculate s = interpolate(s1,..., s t+1 ) = k -1 (e + ar), and finally calculate the signature (r, s).

[0176] There are several alternative forms for pre - calculating the message - independent components of the signature shares. These can be broadly divided into two sets of variants, namely, the cases where r should be included in the calculation and the cases where (kα) -1 should be included. These can be selected independently of each other, so there are 8 variants of the above - mentioned method 200.

[0177] One modified form is to

[0178]

Number

[0179] be memorized during step S206, which means that r is included in the pre - signature share.

[0180] Another modified form is that the multiplication with r can come earlier during the calculation of the intermediate shares. In step S204,

[0181]

Number

[0182] is defined instead, and then in step S206, σ i = λ - β i =(rk -1 a + β)-β i results, and the calculation of the signature share is

[0183]

Number

[0184] It becomes.

[0185] Another modified form is λ i = α i a i + β i is calculated instead, and as a result, λ = (kα) -1 (αa + β) and σ i = λ - (kα) -1 β i It becomes. Two deformation forms including r at the alternative points can be performed in combination with this. Each participant has knowledge of kα as calculated in the pre - calculation step S202. Additionally, all participants 102 broadcast their λ i shares. Therefore, each participant 102 has (at least) 2t + 1 shares and knowledge of the value kα. The participant then λ = (kα) -1 × interpolate(λ1,..., λ 2t+1 ) can be calculated.

[0186] Another modified form is to calculate the intermediate value as λ = (αa + β) and the pre - signature share as σ i = λ - β i instead. Finally, the signature share then

[0187]

Number

[0188] will be. The two deformation forms in the case where r should be included in the calculation can also be performed in combination with this. Each participant 102

[0189]

Number

[0190] Has knowledge of kα from the calculation. The participant then uses this to calculate (kα) -1 mod n and can then include it in the calculation of s i .

[0191] In summary, each participant 102 can generate four secret shares, namely a i , k i , α i , β i . In the exemplary method 200, two products, namely kα, and k -1 a for use in the signature, need to be calculated, and kα is then

[0192]

Number

[0193] is used to calculate (these interpolations across the shares give k -1 when α disappears), and k -1 a uses the first product, so when the shares are extended, what is calculated is

[0194]

Number

[0195] . Any calculation involving shares made from kα and α i can be done by first performing calculations involving only α

[0196]

Number

[0197] itself and then, if necessary, multiplying by (kα) i . -1

[0198] ​One version of the above - mentioned method can be summarized by saying that the signature is calculated using shares consisting of a message - independent component (MIC) and a message - dependent component (MDC), where the MIC is preferably based on the pre - signature share σ i and the MDC is based on the message e.

[0199] The equal - weight method comprises, for example, after interpolation of the signature share made up only of the MDC, calculating the MIC as above and then incorporating this into the signature together with the signature share. Clearly, this method may be the same up to the pre - calculation step S206, where the intermediate share contains the r value, i.e.,

[0200]

Number

[0201] so that, after interpolation, this is λ = k -1 ar + β.

[0202] At this stage, the participant has

[0203]

Number

[0204] the knowledge of, and stores this together with the secret - key share and the corresponding public key (a i , P).

[0205] Then, to generate its signature share for a given message m that is hashed to create the message digest e = hash(m), the participant

[0206]

Number

[0207] Calculate this and send it to the coordinator. The coordinator then s = interpolate(s1,..., s t+1 ) + λ<o001064>= k -1 e + k -1 ar Calculate this, and since the β term disappears, it yields the expected signature share. A similar variant of this protocol can be done as above, for the case where (kα) -1 and r are included in the calculation.

[0208] The following variants can be implemented to calculate message-independent components.

[0209] i) Calculate as follows. λ = k -1 a + β Then, here the signature share is as follows.

[0210]

Number

[0211] And the signature is generated as follows. s = int(s1,..., s t+1 ) + rλ

[0212] ii) Calculate as follows. λ = αar + β Then, here the signature share is as follows. s i = α i e - β i And the signature is generated as follows. s = (kα) -1 (int(s1,..., s t+1 ) + λ)

[0213] M iii) Calculate as follows. λ = αa + β Then, here the signature share is as follows. It should be noted that there may be some unclear or incorrect notations in the original text (such as 2 which seems to be an incomplete or incorrect tag in the context). The translation is done based on the best understanding of the provided text.

[0214]

Number

[0215] And the signature is generated as follows. s=(kα) -1 (int(s1,...,s t+1 )+rλ)

[0216] iv) Calculate as follows. λ=αar+β Then, here the signature share is as follows.

[0217]

Number

[0218] And the signature is generated as follows. s=(int(s1,...,s t+1 )+(kα) -1 λ)

[0219] v) Calculate as follows. λ=αa+β Then, here the signature share is as follows.

[0220]

Number

[0221] And the signature is generated as follows. s=(int(s1,...,s t+1 )+r(kα) -1 λ)

[0222] One difference between method 200 and the previous method is k in the signature -1The calculation of item a can be moved into the pre - calculation stage. The result of this is that signature generation has the same threshold as the private - key calculation, and thus is now a threshold - optimal method. To understand how the correct signature is found, interpolation across the signature shares is s = k -1 e + r(k -1 a+β - β) = k -1 e + r(k -1 a) = k -1 (e + ar) and it should be noted that this is exactly the signature as required.

[0223] Note that the secret thresholds can be different. That is, the thresholds for a, k, α, β themselves do not necessarily need to be the same to execute the signature - generation method. For example, if there is a group of 6 people and 3 are required to create a signature and / or private key, the threshold for k is 4 and the threshold for other shared secrets is 3, and they can technically perform the calculation and they still have a threshold - optimal method.

[0224] Note that when the blinding secret β is not used, it may be possible to calculate the ephemeral key and thus the shared secret key in the following way. Assume that the participants simply use (k -1 a), and that the participants also know r, e, and s. Any person in the method (s-(k -1 a)r)e -1 = k -1 can calculate.

[0225] This result can then be used to calculate (k -1 ) -1 (k -1 a)=a which is the shared secret key.

[0226] By including β in the calculation, this calculation cannot be performed. The value (k -1 a + β) does not leak information about the individual secrets nor the result k -1 a either. To obtain any information that would reveal the secret key a, at least (t + 1) participants, which is the same number as the threshold of the secret key, must cooperate. Therefore, the security is not compromised by calculating this intermediate value λ.

[0227] The problem to be solved using the previous threshold optimal signature calculation is that the product of two shared secrets must be calculated, where the secret is the sum of the individual secrets of all the participants in the group

[0228]

Number

[0229] is.

[0230] In the signature, when the secret key a is a shared secret, k must necessarily be the same as well (otherwise, a could be calculated by anyone who knows k). The second term in the signature is then the multiplication of two shared secrets, which is the part that makes it difficult to achieve optimality. In the non - optimal method by Gennaro et al., and in the exemplary method 200 described above, these secrets are each of degree 0 of a polynomial of degree t, and multiplying the polynomials together results in a requirement for 2t + 1 shares at the threshold to calculate the result of the multiplication. To ensure fairness in this method, most of the communication can be broadcast, and simple equivalence can be checked. Additionally, if a participant drops out of the signature calculation, it is easy for another participant to contribute.

[0231] In the threshold optimal method by Gennaro et al., this threshold of 2t + 1 is avoided by calculating each individual term in the product of the secrets separately. That is, for each pair of participants i, j, the individual term a for each i, j i0k j0 Calculate these results and sum them up. An ephemeral key k is created during signing, and then these products of the individual secret contributions are calculated using the Pallier encryption. This requires each participant to communicate individually with all other signers. To ensure fairness in this case, there are multiple zero-knowledge proofs that must be executed. In this case, if a participant withdraws from the calculation of the signature, the signature algorithm must be restarted.

[0232] In other words, each secret is the sum of the individual secrets, and the multiplication of two secrets is a 10 b 10 +a 20 b 10 +...b n0 a n0 a multiplication of the sums of two of the individual terms that can be extended and expanded like etc.

[0233] The Gennaro method calculates these terms individually. That is, Participant 1 must calculate a 20 b 10 with Participant 2, and also a 30 b 10 with Participant 3, and so on. These are then all summed together. These individual calculations involve zero-knowledge proofs that are computationally expensive. Therefore, as soon as there are many people in this method, this method becomes inefficient. This is also a method with high computational cost for calculating the signature as everything is done at the signature stage.

[0234] ​​In a simple case with three participants, the communication rounds are approximately equal between the two methods (i.e., the optimal threshold method by Gennaro et al. and the exemplary method 200), but the Gennaro method has more, which is not where the main efficiency savings are. The savings are in the volume of data that is computed and communicated. The Gennaro method must include multiple zero-knowledge proofs (ZKP) that do not exist in the exemplary method 200.

[0235] The following compares the method for two out of three people implemented using the optimal threshold method by Gennaro et al. with the exemplary method 200. In the Gennaro method, there are the JVRSS before signing and additional encryption keys to be created for Pallier encryption. Then, there are seven ZKPs to be created and seven ZKPs to be verified in the signature calculation. These ZKPs cannot be sent simultaneously, so there are multiple rounds of communication in the signing stage. Additionally, in some steps, each participant has to communicate individually with all other participants in the signing stage, which is inefficient. This means that all those participants have to be online simultaneously. In contrast, the present invention enables a given participant to calculate a signature share without the other participants being online.

[0236] On the other hand, in the method described above, there are four JVRSS calculations in the pre-signature stage and no ZKPs at any point. The JVRSS calculations can be done simultaneously, so the communication is the same as for one JVRSS. In the signing stage, there is only request-response type communication and all information can be broadcast to the group.

[0237] To compare between the memory capacities of the two schemes, it should be noted that in the above scheme, the ephemeral key is computed along with the setup stage. This means that there is more memory capacity required when compared to Gennaro's scheme. In the case of the scheme described above, for example, 32 bytes of memory space are each required for three additional values to be stored corresponding to creating a signature. Considering savings in computation and communication, as well as achieving optimality, this is minimal.

[0238] To summarize, Gennaro's scheme reduces the memory capacity required after setup and precomputation, but increases the computation and communication during signature calculation. This is due to the inefficiency of moving more of the computation in Gennaro's scheme to be pre-signed. In particular, when the inequality N≧2t + 1 is acceptable, the scheme of the present invention is more efficient than Gennaro's optimal scheme.

[0239] Exemplary Use Cases Generally, the present invention can be used to generate signatures for any message. As a specific exemplary use case, the message may be part or all of a blockchain transaction. That is, the signature can be used to sign one or more inputs and / or one or more outputs of a blockchain transaction.

[0240] Figure 3 shows an exemplary transaction protocol for use as part of a blockchain protocol. Exemplary blockchain protocols are well-documented in the literature, but an explanation of an exemplary protocol transaction is provided here for completeness. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the basic data structure of the blockchain (each block of the blockchain comprises one or more transactions 152). The following is explained by reference to an output-based or "UTXO" - based protocol. However, this is not limiting for all possible embodiments.

[0241] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO) that can be used as a source for an input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO includes a value that specifies the amount of a digital token, e.g., represents the amount of a digital asset. This represents the number of tokens on the ledger (being distributed). A UTXO may also include, among other information, the transaction ID of the transaction from which the UTXO came. The transaction data structure may also comprise a header 201, which may comprise an indicator of the sizes of the input field 202 and the output field 203. The header 201 may also include the ID of the transaction. In an embodiment, the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner.

[0242] A first user, for example, Alice, wishes to create a transaction 152j that transfers a certain amount of digital tokens to a second user, for example, Bob. In FIG. 3, Alice's new transaction 152j is labeled "Tx1". It removes the digital tokens of the amount locked for Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least some of these to Bob. The preceding transaction 152i is labeled "Tx0" in FIG. 3. Tx0 and Tx1 are just arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain nor that Tx1 is the very next transaction in the pool. Tx1 can point back to any preceding (i.e., antecedent) transaction that still has an unspent output 203 locked for Alice.

[0243] When Alice creates her new transaction Tx1, or at least by the time she sends it to network 106, the previous transaction Tx0 may already have been validated and may be included in the blockchain. It may already be included in one of the blocks at that time, or it may still be waiting in pool 154, in which case it will soon be included in a new block. Alternatively, Tx0 and Tx1 can be created together and sent to the blockchain network, or Tx0 can be sent even after Tx1 if the node protocol allows "orphan" transactions to be buffered. The terms "previous" and "subsequent" as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence (which transaction points to which other transaction, etc.) as defined by the transaction pointers specified in the transactions. They can be equivalently replaced with "predecessor" and "successor", or "ancestor" and "descendant", "parent" and "child", or the like. This does not necessarily imply the order in which they are created, sent to the network, or arrive at any given node. That said, a subsequent transaction (descendant transaction or "child") that refers to a previous transaction (ancestor transaction or "parent") is not valid until the parent transaction is validated, and is not valid as long as the parent transaction is not validated. A child that arrives at the node before its parent is considered an orphan. Orphans may be discarded, depending on the node protocol and / or miner behavior, or may be buffered for some period of time while waiting for a parent.

[0244] One of one or more outputs 203 of a preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of digital tokens represented by the UTXO, and a lock script defining conditions that must be satisfied by an unlocking script in an input 202 of a subsequent transaction in order for the subsequent transaction to be valid, and thus for the UTXO to be successfully redeemed. Typically, the lock script locks the amount for a particular party (the beneficiary of the transaction in which the lock script is included). That is, the lock script typically defines an unlocking condition that includes the condition that the unlocking script in an input of a subsequent transaction comprises the cryptographic signature of the party to whom the preceding transaction locked the amount.

[0245] The lock script (also known as scriptPubKey) is a fragment of code written in a domain-specific language recognized by the node protocol. A particular example of such a language is called "Script" (with a capital S). The lock script specifies what information is required to spend a transaction output 203, e.g., specifying the requirements for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a fragment of code written in a domain-specific language that provides the information required to meet the lock script criteria. For example, it may include Bob's signature. The unlocking script appears in an input 202 of the transaction.

[0246] Thus, in the illustrated example, UTXO0 in the output 203 of Tx0 comprises the lock script [Checksig P A , and the lock script [Checksig P A requires Alice's signature Sig P A in order for UTXO0 to be redeemed (strictly speaking, for a subsequent transaction attempting to redeem UTXO0 to be valid). [Checksig PA includes the public key P from Alice's public-private key pair. A Input 202 of Tx1 comprises a pointer that points backward to Tx1 (e.g., in an embodiment, the transaction ID, i.e., TxID0, which is the hash of the entire transaction Tx0). Input 202 of Tx1 comprises an index that identifies UTXO0 within Tx0 to distinguish it from any other possible output of Tx0. Input 202 of Tx1 further comprises an unlock script <Sig P A >, and the unlock script <Sig P A > comprises Alice's cryptographic signature created by applying her private key from the key pair to a predefined portion of the data (sometimes called the "message" in cryptography). What data (or "message") needs to be signed by Alice to provide a valid signature can be defined by the lock script, or by the node protocol, or by a combination of these.

[0247] When a new transaction Tx1 arrives at a node, that node applies the node protocol. This comprises causing the lock script and the unlock script to be executed together to check whether the unlock script satisfies the conditions defined in the lock script (where this condition may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts, i.e., <Sig P A > <P A > || [Checksig P A where "||" represents concatenation, "<...>" means the location of data on the stack, and "[...]" is a function provided by the unlock script (in this example, a stack-based language). Equivalently, the scripts may be executed one after another using a common stack rather than concatenating the scripts. Either way, when executed together, the scripts check whether the public key P of Alice, as contained in the lock script within the output of Tx0,​A Use A to authenticate that the lock script in the input of Tx1 contains Alice's signature that signs the expected part of the data. The expected part of the data itself (the "message") must also be included in Tx0 to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx0 (thus, no separate element is needed to specify the signed part of the data in plaintext as it already essentially exists).

[0248] Details of authentication by public-key cryptography will be familiar to those skilled in the art. Basically, if Alice is signing a message by encrypting it with her private key, given Alice's public key and the message in plaintext (the non-encrypted message), another entity such as a node in the blockchain network can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically comprises hashing the message, signing the hash, and tagging this as a signature over the plaintext version of the message, thus enabling any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or part of a transaction or the like can, in an embodiment, be taken to mean signing the hash of such a piece of data or part of a transaction.

[0249] If the unlock script in Tx1 meets one or more conditions specified within the lock script of Tx0 (so in the illustrated example, if Alice's signature is provided and authenticated within Tx1), the blockchain node considers Tx1 valid. If it is a mining node, this means that the mining node adds Tx1 to the pool of transactions waiting for proof of work. If it is a transfer node, the transfer node transfers the transaction Tx1 to one or more other nodes in the blockchain network, and as a result, the transaction Tx1 is propagated throughout the network. When Tx1 is made valid and included in the blockchain, this defines UTXO0 from Tx0 as consumed. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction, Tx1 is invalid even if all other conditions are met. Thus, node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been consumed (already formed a valid input to another valid transaction). This is one reason why enforcing the defined order on transactions is important for blockchain 150. In practice, a given node 104 may maintain a separate database marking which UTXO203 in which transaction has been consumed, but ultimately, what defines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction in the blockchain.

[0250] If the total amount specified among all outputs 203 of a given transaction is greater than the total amount indicated by all of its inputs 202, this is another criterion for invalidity in most transaction models. Thus, such a transaction is not propagated and is not mined into a block.

[0251] Note that script code is often represented schematically (i.e., not in exact language). For example, [Checksig P A = OP_DUP OP_HASH160 <H(P A )> OP_EQUALVERIFY OP_CHECKSIG can be written as [Checksig P A for the purpose of meaning. "OP_..." refers to specific opcodes of the Script language. OP_CHECKSIG (also called "Checksig") is a Script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrence of the signature ("sig") is removed from the script, but additional requirements such as a hash puzzle remain in the transaction being verified by the "sig" input. As another example, OP_RETURN is a Script language opcode for creating a non-consumable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata in the blockchain. For example, the metadata can comprise a document that is desired to be stored in the blockchain.

[0252] Signature P A is a digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific piece of data. In embodiments, for a given transaction, the signature signs part of the transaction input and all or part of the transaction output. The specific part of the output that it signs depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature for selecting which outputs are signed (and thus fixed at the time of signing).

[0253] Referring to the fact that the locking script includes the public key of the party to whom each transaction is locked for that person, the locking script may be referred to as the "scriptPubKey". Referring to the fact that the unlocking script supplies the corresponding signature, the unlocking script may be referred to as the "scriptSig". However, more generally, it is not always essential in all applications of the blockchain that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred in some cases.

[0254] According to some embodiments of the present invention, the signature generated by the coordinator 101 can be used to sign a blockchain transaction. For example, the generated signature can be used, at least in part, to unlock the output of a blockchain transaction. As a specific example, the output of a previous transaction may be a pay-to-public-key-hash (P2PKH) output locked to the hash of the public key. To be unlocked, the input of a later transaction referring to the P2PKH output needs to include the (unhashed) public key and a signature generated based on the private key corresponding to the public key.

[0255] When represented in a script, the "locking script" and "unlocking script" may take the following forms. Locking script = OP_DUP OP_HASH160 <Public KeyHash> OP_EQUAL OP_CHECKSIG Unlocking script = <signature><Public Key>

[0256] Referring to the above-described embodiments, <Public Key> may be regarded as equivalent to P = a·G, <signature>It has a threshold signature s, where the previous transaction is the message to be signed. Note that, as described above, the ECDSA signature has the form (r, s).

[0257] Note that the described signature generation method is not limited to any particular use case and, in general, may be used to generate signatures based on any message. Signing all or part of a blockchain transaction is just one exemplary example. The described method may be used, for example, to sign and / or authenticate legal documents (such as wills, notarial deeds, or other contracts), letters between one or more parties, digital certificates (such as those issued by a certification authority), medical prescriptions, bank transfers or financial certificates, mortgage or loan applications, etc.

[0258] As a specific example, a group of participants (such as a total of five participants) may form a company's board of directors. The voting matters of the company may require a majority of the board of directors (i.e., at least three participants) to agree on a particular vote. The board of directors may use the described signature generation method to prove that at least three board members have agreed to vote in favor of a particular outcome. In this example, the threshold of the signature generation method is three. That is, in order for the coordinator to successfully generate a signature, at least three of the board members must each provide their signature shares. If the signature is successfully generated, it must be the case that at least the threshold number (i.e., three) of board members have agreed to vote in favor of that outcome. Thus, the successful generation of the signature serves as a record of the vote and proves in a particular way that a majority of the board of directors has voted.

[0259] Another use case for the present invention is in the field of digital certificates, for example, digital certificates issued according to the X.509 standard. A digital certificate includes a signature that signs over some data. The data can generally be any data, but a particular example of the data included in the digital certificate is a public key. The public key in the digital certificate is often referred to as the "certified public key". The issuer of the digital certificate (the "certification authority") may perform one or more checks (such as a know-your-customer check) on the owner of the public key. If the check is successful, the certification authority issues a digital certificate that includes the certified public key. A user can use the certified public key, for example, by signing a message with the private key corresponding to the certified public key, to prove that they are who they say they are.

[0260] One particular use for a certification authority is to sign the certificates used in HTTPS for secure browsing on the Internet. Another common use is when the central government issues identity certificates for use when electronically signing documents. The certification authority signs the public key (or any other data to be certified) using the private key. This introduces a single point of failure. That is, if a malicious party can obtain access to the private key used by the certification authority to issue digital certificates, the malicious party can then issue fraudulent certificates. A particular example of a targeted certification authority is DigiNotar, a certification authority in the Netherlands. The private key used by DigiNotar was compromised in 2011 and used to issue fraudulent certificates. This attack was possible because the attacker only needed to obtain a single piece of data, namely the private key. However, if the certification authority (DigiNotar) had used the threshold signature scheme according to the present invention, this attack would have been impossible (or at least made much more difficult). To issue a certificate, the attacker would have to obtain the threshold number of key shares (or signature shares) required to generate the signature.

[0261] It will be appreciated that the above embodiments are merely illustrative by way of example. More generally, a method, apparatus, or program according to any one or more of the following statements may be provided.

[0262] Statement 1. A computer-implemented method for generating shares of a digital signature of a message, wherein a threshold number of different signature shares from each participant in a group of participants are required to generate the digital signature, each participant has a respective private key share, and the method is performed by a first participant among the participants, Generating a first message-independent component and a first message-dependent component, wherein the message-independent component is generated based on a first secret key share and the message-dependent component is generated based on a message; Making the first message-independent component available to a coordinator; Making a first signature share available to the coordinator for generating a signature based on at least a threshold number of signature shares, wherein the first signature share comprises at least the message-dependent component.

[0263] For example, the first message-independent component may be sent to the coordinator before the first signature share and even before the first message-dependent component is generated.

[0264] Statement 2. The method of Statement 1, wherein the message-independent component is generated before the message is obtained.

[0265] In other words, the message-independent component may be pre-computed. That is, the message-independent component may be generated prior to obtaining (e.g., receiving) the message. Then, when the message has been obtained, the message-dependent component may be generated, thus enabling the generation of the signature share.

[0266] Statement 3. The method of Statement 1 or Statement 2, wherein the first signature share comprises the message-independent component.

[0267] That is, in at least some embodiments, the first signature share does not include the message-independent component.

[0268] Statement 4. The method of any one of Statements 1 to 3, wherein the first secret key share is generated using a joint secret sharing scheme for generating a share of the first secret key.

[0269] Claim 5. The method of Claim 4, wherein generating the first secret key share using a joint secret sharing method comprises: generating a first data item, wherein the first data item is a first polynomial; and obtaining each respective data item from at least a threshold number of participants, wherein each respective data item is a respective polynomial generated by each respective participant; and generating the first secret key share based on the first data item and each of the respective data items.

[0270] Claim 6. The method of Claim 5, wherein obtaining each respective data item comprises obtaining each respective data item via a respective communication channel between the first participant and each of the respective participants.

[0271] Preferably, each communication channel is a secure communication channel.

[0272] Claim 7. The method of Claim 4 or Claim 5, comprising transmitting each instance of the first polynomial to each of at least a threshold number of participants, wherein each instance of the first polynomial is based on each respective participant.

[0273] For example, each instance may be transmitted via a respective communication channel.

[0274] In some examples, the joint secret sharing method comprises: sharing each respective set of coefficients of the first polynomial obfuscated using a generator value with each of at least a threshold number of participants; and obtaining each respective set of coefficients of each respective polynomial generated by each respective participant, wherein each respective set of coefficients is obfuscated using the generator value; and for each respective participant, Determining a first candidate value based on each data item that has been obfuscated using a generator value and obtained from its participant; Determining a second candidate value based on each set of obfuscation factors obtained from its respective participant, and Verifying that the first candidate value corresponds to the second candidate value, Further comprising verifying that each participant has correctly generated its respective secret key share; It may be a jointly verifiable secret sharing scheme.

[0275] Statement 8. A method according to any of the preceding statements, wherein each participant has a respective ephemeral secret key share, and the first message-independent component and / or the first message-dependent component is based on the first ephemeral secret key share.

[0276] Statement 9. A method according to statement 8, wherein each participant has a respective shared value based on the ephemeral public key corresponding to the ephemeral secret key, and the first message-independent component is based on the shared value.

[0277] Statement 10. A method according to any of the preceding statements, wherein the first ephemeral secret key share is generated using a joint secret sharing scheme for generating shares of the ephemeral secret key.

[0278] Statement 11. A method according to any of the preceding statements, wherein the first message-independent component is generated based on the inverse corresponding to the first ephemeral secret key share.

[0279] Statement 12. A method according to statement 11, wherein generating the inverse of the first ephemeral secret key share comprises: Generating an intermediate value based on the ephemeral secret key and the first blinding key; and Generating the inverse of the first ephemeral secret key share based on the inverse of the intermediate value and the first blinding key share of the first blinding key.

[0280] The intermediate value is the product of the ephemeral secret key and the first blinding key.

[0281] Claim 13. The method of Claim 12, wherein a first blinding key share is generated using a joint secret sharing method for generating a share of the first blinding key.

[0282] Claim 14. The method of Claim 12 or Claim 13, wherein the intermediate value is generated by generating a first multiplicative key share based on a first ephemeral secret key share and a blinding key share, obtaining each multiplicative key share from at least a threshold number of participants, and generating an intermediate value based on the first multiplicative key share and each of the respective multiplicative key shares.

[0283] Note that in some examples, the threshold number of participants required to generate a multiplicative key share is different from the threshold number of participants required to generate a secret key share. For example, the secret key has a threshold t + 1 and the multiplicative key share requires 2t + 1.

[0284] Claim 15. The method of Claim 14, comprising transmitting the first multiplicative key share to each of at least a threshold number of participants.

[0285] Claim 16. The method of any of the preceding claims, wherein the message-independent component is generated based on a second blinding key share of a second blinding key.

[0286] Claim 17. The method of Claim 16, wherein a second blinding key share is generated using a joint secret sharing method for generating a share of the second blinding key.

[0287] Claim 18. A method according to claim 11 or any claim dependent thereon, wherein the first message-independent component is generated based on a first pre-signature share, the first pre-signature share being a first intermediate share generated based on a first secret key share and the inverse corresponding to a first ephemeral secret key share, and generated based on each intermediate share obtained from at least a threshold number of participants.

[0288] Claim 19. A method of claim 11 when dependent on any of claims 1-17, wherein the first message-independent component is generated based on a first pre-signature share, the first pre-signature share being a first intermediate share generated based on a first secret key share and a first blinding key share, and generated based on each intermediate share obtained from at least a threshold number of participants.

[0289] Claim 20. The method of claim 19, wherein the first pre-signature share is generated based on the inverse corresponding to the first ephemeral secret key share.

[0290] Claim 21. A method according to any of claims 18-20, wherein the first intermediate share is generated based on a second blinding key share.

[0291] Claim 22. A method according to any of claims 18-21, wherein the first pre-signature share is generated based on a shared value.

[0292] Claim 23. The method of claim 22, wherein the first intermediate share is generated based on a shared value.

[0293] Claim 24. A method according to either claim 18 or claim 19 or any claim dependent thereon, comprising transmitting the first intermediate share to at least a threshold number of participants.

[0294] Claim 25. The method of any of the foregoing claims, comprising generating a plurality of different instances of message-independent components.

[0295] Claim 26. The method of any of the foregoing claims, comprising generating a plurality of different instances of first ephemeral secret key shares.

[0296] Claim 27. The method of Claim 25 or Claim 26, comprising generating a plurality of different instances of a first blinding key share and / or a second blinding key share.

[0297] Claim 28. The method of either Claim 18 or Claim 19 or any claim dependent thereon, comprising generating a plurality of different instances of first pre-signature shares.

[0298] Claim 29. The method of any of the foregoing claims, comprising obtaining a message from a coordinator.

[0299] Claim 30. The method of any of Claims 1 to 28, comprising generating a message.

[0300] Claim 31. The method of any of the foregoing claims, wherein the message is a hash of a second message.

[0301] Claim 32. The method of any of the foregoing claims, wherein making the first signature share available to the coordinator for the coordinator comprises at least one of: sending the first signature share to the coordinator; broadcasting the first signature share to one or more of a threshold number of participants.

[0302] Claim 33. The method of any of the foregoing claims, wherein making the first message-independent component available to the coordinator for the coordinator is sending the first message-independent component to a coordinator; comprising at least one of broadcasting the first message-independent component to one or more of a threshold number of participants.

[0303] Claim 34. A computer-implemented method of generating a digital signature of a message, wherein a threshold number of different signature shares from respective participants of a group of participants are required to generate the digital signature, each participant has a respective secret key share, the method being performed by a coordinator, obtaining at least a threshold number of respective message-independent components, each respective message-independent component being generated based on a respective secret key share; obtaining at least a threshold number of respective signature shares, each respective signature share being based on at least a respective message-dependent component, each respective message-dependent component being generated based on the message; and generating a signature of the message based on each of the obtained signature shares and each of the obtained message-independent components.

[0304] Each respective message-independent component may form part of a respective signature share.

[0305] Generating the signature may comprise interpolating the signature shares.

[0306] Note that in some cases, the signature may be a component of an ECDSA signature.

[0307] Claim 35. The method of Claim 34, wherein each respective signature share is based on a respective message-independent component.

[0308] Claim 36. The method of Claim 34, wherein generating a common message-independent component based on each of the obtained message-independent components; and generating a signature based on the common message-independent component.

[0309] Claim 37. A method according to any of Claims 34 to 36, wherein each participant has a respective ephemeral secret key share, and each respective message-independent component and / or message-dependent component is based on the respective ephemeral secret key share.

[0310] Claim 38. A method according to Claim 37, wherein each participant has a shared value based on an ephemeral public key corresponding to the ephemeral secret key, and each respective message-independent component is based on the shared value.

[0311] Claim 39. A method according to any of Claims 34 to 38, comprising sending a message to one, some, or all of the participants among a threshold number of participants.

[0312] Claim 40. A method according to any of Claims 34 to 39, comprising sending a request for each respective signature share to at least a threshold number of participants.

[0313] Claim 41. A method according to any of Claims 34 to 40, comprising generating one of the obtained signature shares.

[0314] Claim 42. A method according to any of Claims 34 to 41, comprising outputting a signature.

[0315] Claim 43. A method according to Claim 42, wherein outputting a signature comprises sending the signature to one or more parties, and / or recording the signature on a digital medium, and / or publishing the signature.

[0316] Claim 44. A method according to any of the preceding claims, wherein the message comprises at least a part of a blockchain transaction.

[0317] Alternatively, the message may comprise at least one of a document (e.g., a legal document), a digital certificate, a medical prescription, or a financial certificate.

[0318] Claim 45. A method according to any of the preceding claims, wherein the threshold number of participants is less than the total number of participants in the group of participants.

[0319] Claim 46. A computer device, a memory comprising one or more memory units, and a processing device comprising one or more processing units, the memory storing code configured to execute on the processing device, the code being configured to execute a method according to any of Claims 1 to 45 when executed on the processing device.

[0320] Claim 47. A computer program embodied on a computer-readable storage and configured to execute a method according to any of Claims 1 to 45 when executed on a computer device according to Claim 46.

[0321] According to another aspect disclosed herein, a method may be provided that includes actions of a first participant and a coordinator.

[0322] According to another aspect disclosed herein, a system may be provided that includes computer devices of a first participant and a coordinator.

[0323] Given the disclosure herein, other variations or use cases of the disclosed techniques may become apparent to those skilled in the art. The scope of this disclosure is limited only by the appended claims, rather than the described embodiments.

Description of the Reference Numerals

[0324] 100 System 101 Coordinator 102 Participant 103 Third Party 152 Transaction 201 Header 202 Input, Input Field 203 Output, Output Field< / signature> < / signature>

Claims

1. A computer-implemented method for generating a first signature share of a digital signature of a message, wherein a threshold number of different signature shares from each participant in a group of participants is required to generate the digital signature, each participant has a respective secret key share, and each participant has a share of a respective ephemeral secret key, wherein the computer-implemented method is executed by a processing device of a computer device used by a first participant in the group of participants, wherein the first participant has a first secret key share, generating a first message-independent component and a first message-dependent component, wherein the first message-independent component is generated based on the first secret key share, wherein the first message-dependent component is generated based on the message, wherein the first message-independent component and / or the first message-dependent component is based on a first ephemeral secret key share, making the first message-independent component available to a coordinator, making a first signature share available to the coordinator for generating the digital signature based on at least the threshold number of signature shares, wherein the first signature share comprises at least the first message-dependent component, A computer-implemented method comprising the steps.

2. The method according to claim 1, wherein the first message-independent component is generated before obtaining the message.

3. The method according to claim 1 or 2, wherein the first signature share comprises the first message-independent component.

4. The method according to any one of claims 1 to 3, wherein the first secret key share is generated using a secret sharing scheme for generating a share of a first secret key.

5. Generating the first secret key share using the secret sharing scheme is generating a first data item, wherein the first data item is a first polynomial, obtaining respective data items from at least the threshold number of participants, wherein each respective data item is a respective polynomial generated by a respective participant, generating the first secret key share based on the first data item and each of the respective data items The method according to claim 4, comprising the above.

6. The step of obtaining each of the respective data items The method according to claim 5, comprising the step of obtaining each of the respective data items via respective communication channels between the first participant and each of the respective participants.

7. comprising the step of transmitting each instance of the first polynomial to each of at least the threshold number of participants, The method according to claim 5, wherein each instance of the first polynomial is based on a respective participant.

8. Each participant has a respective shared value based on the respective ephemeral public key corresponding to the respective ephemeral secret key, The method according to claim 7, wherein the first message-independent component is based on the shared value.

9. The method according to any one of claims 4 to 8, wherein the first ephemeral secret key share is generated using the joint secret sharing method for generating shares of the respective ephemeral secret keys.

10. The method according to any one of claims 4 to 9, wherein the first message-independent component is generated based on the inverse corresponding to the first ephemeral secret key share.

11. generating the inverse of the first ephemeral secret key share comprises the step of generating an intermediate value based on a first ephemeral secret key and a first blinding key; and the step of generating the inverse of the first ephemeral secret key share based on the inverse of the intermediate value and a first blinding key share of the first blinding key The method according to claim 10, comprising the above.

12. The method according to claim 11, wherein the first blinding key share is generated using the joint secret sharing method for generating shares of the first blinding key.

13. The intermediate value comprises the step of generating a first multiplicative key share based on the first ephemeral secret key share and the blinding key share; the step of obtaining respective multiplicative key shares from at least the threshold number of participants; and the step of generating the intermediate value based on the first multiplicative key share and each of the respective multiplicative key shares The method according to claim 11 or 12, generated by

14. The method according to claim 13, comprising the step of sending the first multiplicative key share to each of at least the threshold number of participants.

15. The method according to any one of claims 4 to 14, wherein the first message-independent component is generated based on a second blinding key share of a second blinding key.

16. The method according to claim 15, wherein the second blinding key share is generated using the common secret sharing method for generating a share of the second blinding key.

17. The first message-independent component is generated based on a first pre-signature share, wherein the first pre-signature share, is a first intermediate share generated based on the first secret key share and the inverse corresponding to the first ephemeral secret key share, and each intermediate share obtained from at least the threshold number of participants The method according to claim 10 or any one of claims 11 to 16 when dependent on claim 10.

18. The first message-independent component is generated based on a first pre-signature share, wherein the first pre-signature share, is a first intermediate share generated based on the first secret key share and the first blinding key share, each intermediate share obtained from at least the threshold number of participants The method according to any one of claims 12 to 16 when dependent on claim 11.

19. The method according to claim 18, wherein the first pre-signature share is generated based on the inverse corresponding to the first ephemeral secret key share.

20. The method according to claim 17 when dependent on claim 15, wherein the first intermediate share is generated based on the second blinding key share.

21. The method according to claim 18 or 19 when dependent on claim 15, wherein the first intermediate share is generated based on the second blinding key share.

22. The method according to claim 17 or 20 when dependent on claim 8, wherein the first pre-signature share is generated based on the shared value.

23. The method according to any one of claims 18, 19, and 21 when dependent on claim 8, wherein the first pre-signature share is generated based on the shared value.

24. The method according to claim 22, wherein the first intermediate share is generated based on the shared value.

25. The method according to claim 17 or claim 20 or 22 when dependent on claim 17, comprising the step of transmitting the first intermediate share to at least the threshold number of participants.

26. The method according to any one of claims 19, 21, and 23 when dependent on claim 18 or claim 18, comprising the step of transmitting the first intermediate share to at least the threshold number of participants.

27. The method according to any one of claims 1 to 25, comprising the step of generating a plurality of different instances of the first message-independent component.

28. The method according to any one of claims 1 to 27, comprising the step of generating a plurality of different instances of the first ephemeral secret key share.

29. The method according to claim 27 or 28, comprising the step of generating a plurality of different instances of the first blinding key share and / or the second blinding key share.

30. The method according to any one of claims 19 to 29 when dependent on claim 17 or claim 17, comprising the step of generating a plurality of different instances of the first pre-signature share.

31. The method according to any one of claims 19 to 29 when dependent on claim 18 or claim 18, comprising the step of generating a plurality of different instances of the first pre-signature share.

32. The method according to any one of claims 1 to 27, comprising the step of obtaining the message from the coordinator.

33. The method according to any one of claims 1 to 32, comprising the step of generating the message.

34. The method according to any one of claims 1 to 33, wherein the message is a hash of a second message.

35. The step of making the first signature share available to the coordinator is the step of transmitting the first signature share to the coordinator, broadcasting the first signature share to one or more of the participants of the threshold number The method according to any one of claims 1 to 34, comprising at least one of the above. **Claim 36** The step of making the first message-independent component available to the coordinator includes sending the first message-independent component to the coordinator, broadcasting the first message-independent component to one or more of the participants of the threshold number The method according to any one of claims 1 to 35, comprising at least one of the above. **Claim 37** A computer-implemented method for generating a digital signature of a message, wherein a threshold number of different signature shares from each participant in a group of participants are required to generate the digital signature, each participant has a respective secret key share, and each participant has a share of a respective ephemeral secret key, the computer-implemented method is executed by a processing device of a computer device used by a coordinator, obtaining at least a threshold number of respective message-independent components, each respective message-independent component being generated based on a respective secret key share, obtaining at least the threshold number of respective signature shares, each respective signature share being based on at least a respective message-dependent component, each respective message-dependent component being generated based on the message, generating the digital signature of the message based on each of the obtained signature shares and each of the obtained message-independent components, each message-independent component and / or message-dependent component being based on a share of a respective ephemeral secret key A computer-implemented method comprising the above. **Claim 38** The method according to claim 37, wherein each respective signature share is based on each of the message-independent components. **Claim 39** generating a common message-independent component based on each of the obtained message-independent components; generating the digital signature based on the common message-independent component The method according to claim 37, comprising the above. **Claim 40** Each participant has a shared value based on the ephemeral public key corresponding to each of the respective ephemeral secret keys, each respective message-independent component is based on the shared value, the method according to claim 39. **Claim 41** The method according to any one of claims 37 to 40, comprising the step of sending the message to one, a part, or all of the participants among the threshold number of participants. **Claim 42** The method according to any one of claims 37 to 41, comprising the step of sending a request for each signature share to at least the threshold number of participants. **Claim 43** The method according to any one of claims 37 to 42, comprising the step of generating one of the obtained signature shares. **Claim 44** The method according to any one of claims 37 to 43, comprising the step of outputting the digital signature. **Claim 45** The step of outputting the digital signature is the step of sending the digital signature to one or more parties, and / or the step of recording the digital signature on a digital medium, and / or the step of making the digital signature public The method according to claim 44, comprising. **Claim 46** The method according to any one of claims 1 to 36, wherein the message comprises at least a part of a blockchain transaction. **Claim 47** The method according to any one of claims 37 to 45, wherein the message comprises at least a part of a blockchain transaction. **Claim 48** The method according to any one of claims 1 to 36 and 46, wherein the threshold number of participants is less than the total number of participants in the group of participants. **Claim 49** The method according to any one of claims 37 to 45 and 47, wherein the threshold number of participants is less than the total number of participants in the group of participants. **Claim 50** A computer device, a memory comprising one or more memory units, a processing device comprising one or more processing units The computer device is provided, the memory stores code configured to be executed on the processing device, and when the code is executed on the processing device, it is configured to execute the method according to any one of claims 1 to 36 and 46. **Claim 51** A computer device, A memory comprising one or more memory units, a processing apparatus comprising one or more processing units, wherein the memory stores code configured to be executed on the processing apparatus, and when the code is executed on the processing apparatus, is configured to execute the method according to any one of claims 37 to 45 and 47, a computer device.

52. A computer program embodied on a computer-readable storage and configured to execute the method according to any one of claims 1 to 36 and 46 when executed on the computer device according to claim 48.

53. A computer program embodied on a computer-readable storage and configured to execute the method according to any one of claims 37 to 45 and 47 when executed on the computer device according to claim 49.

Images