(EC)dsa threshold signatures with secret sharing

Abstract

To provide a computer-implemented method for generating a share of a digital signature for a message.SOLUTION: With a threshold number of different signature shares being required from each participant of a group of participants to generate a digital signature, and with the participants having respectively private key shares, a method according to the present invention is performed by a first participant among the participants and includes the steps of: generating a first message-independent component and a first message-dependent component, in which the message-independent component is generated on the basis of the first private key share and the message-dependent component is generated on the basis of the message; enabling a coordinator to use the first message-independent component; and enabling the coordinator to use the first signature share so as to generate a signature on the basis of at least the threshold number of signature shares, in which the first signature share includes at least the message-dependent component.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] Public key cryptography is a type of cryptographic system that uses a key pair: a private key known only to its owner, 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 allows a sender to encrypt a message using the recipient's public key (i.e., the public key that corresponds to a 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 its 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 who has the signer's corresponding public key can use the same message and the digital signature on the message to verify whether the signature was validly created, i.e., whether the signature was indeed made using the signer's private key.

[0005] Digital signature schemes typically involve three steps, or algorithms: A key generation algorithm is used to generate a random private key and a corresponding public key; A signing algorithm is used to generate a signature based on the message and the private key; and A verification algorithm is used, given the public key and the message, to verify that the signature was generated according to the signing algorithm using the corresponding private key.

[0006] A threshold signature scheme allows a threshold number of participants in a group to create digital signatures for (or of) a message using their individual shares of a shared secret key. Here, a digital signature is a signature generated based on the message to be signed. In such a scheme, a signature can only be created if the threshold number of participants agree to create a signature for the message. Any attempt to create a signature using fewer participants will not produce a valid signature. Therefore, a valid signature by a group (i.e., a signature generated using the message and the shared secret key) requires that a threshold number of people provably agreed to create the signature. This also implies that any attacker would need to obtain a threshold number of shares of the private key in order to forge a signature using that private key.

[0007] A general feature of threshold signature shares is that if any of the private key shares are lost, the private key may still be recoverable, provided that a threshold number of shares are still 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, the threshold ECDSA scheme, is a non-optimal scheme in which a group collectively possesses a shared secret key with a threshold of t+1, but creating a signature requires a larger threshold of 2t+1. For a detailed description, 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 an optimal scheme, where optimal means that the threshold for creating the signature is the same as the threshold for the shared secret key. For a detailed description, 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 hereafter referred to as the "optimal Gennaro scheme." [Prior art documents] [Patent documents]

[0010] [Patent Document 1] WO2017145010A1 [Non-patent literature]

[0011] [Non-Patent Document 1] Gennaro, R. et al., "Robust threshold DSS signatures," International Conference on the Theory and Applications of Cryptographic Techniques, Springer, Berlin, Heidelberg, 1996. [Non-patent document 2] 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. Summary of the Invention [Problem to be solved by the invention]

[0012] The advantage of the non-optimal Gennaro scheme is that it is efficient in terms of both computation and communication rounds. The disadvantage is that the threshold for creating a private key is smaller than the threshold for generating a digital signature. The problem with this is that one cannot be sure that a threshold number of participants have jointly signed. That is, because a signature can be calculated using a private key, fewer participants than the threshold for generating a signature can jointly sign a message using a private key and without using threshold signatures. For example, the threshold for generating a private key can be 2, and the threshold for generating a signature can be 3. In that case, two people can generate the private key and therefore the signature, thus avoiding the requirement that three people be needed to generate a threshold signature.

[0013] In contrast, the advantage of the optimal Gennaro scheme is that there is no difference in the thresholds for generating private keys and signatures. However, this scheme requires more computation and communication rounds, signature creation is slower, and the scheme does not scale well.

[0014] Therefore, it would be desirable to have a threshold ECDSA scheme that is as threshold-optimal as the optimal Gennaro scheme, but has the computation, storage, and communication advantages of the non-optimal Gennaro scheme. [Means for solving the problem]

[0015] According to one aspect disclosed herein, there is provided 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.

[0016] According to another aspect disclosed herein, there is provided a computer-implemented method for generating 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 coordinator and comprising: obtaining at least a threshold number of respective message-independent components, each respective message-independent component being generated based on a respective private 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 a message; and generating a signature for the message based on each of the obtained signature shares and each of the obtained message-independent components.

[0017] To assist in understanding embodiments of the present disclosure and to show how such embodiments may be put into effect, reference will be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 illustrates a schematic diagram of an exemplary system for generating a signature for a message, in accordance with an embodiment of the present invention. [Figure 2] FIG. 2 illustrates a schematic diagram of an exemplary method for generating a signature share of a message, according to an embodiment of the present invention. [Figure 3] FIG. 1 is a schematic diagram illustrating an example blockchain transaction protocol. DETAILED DESCRIPTION OF THE INVENTION

[0019] Introduction Elliptic curve group An elliptic curve E is given by the formula y 2 =x 3 +ax+b mod p where a,b∈Zp and a and b are 4a 3 +27b 3 ≠ 0. A group on this elliptic curve is defined to be the set of elements (x, y) that satisfy this equation together with the identity element, the point at infinity O. The group operation on elements in this group is called elliptic curve point addition and is denoted by +. This group is called E(Z p ) and its degree is denoted by n.

[0020] This group operation can be used to define another operation on elements called point multiplication, denoted by ·. p ) and scalar

[0021]

number

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

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

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

[0025] 1. Compute the message digest e = hash(msg), which may be any hash function. For example, in some examples, hash(msg) = SHA256(SHA256(msg)), where SHA256(■) is the SHA-256 hash function. Note that the message may alternatively be hashed only once or more than twice using the same or different hash functions.

[0026] 2. Choose a random integer k∈{1,...,n-1}, where n is the degree of the elliptic curve, e.g., the secp256k1 curve. In the following, k is called the ephemeral private key.

[0027] 3. The ephemeral public key k G = (R x ,R y ) is calculated.

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

[0029] 5. Multiplicative inverse k of an ephemeral key -1 Calculate mod n.

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

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

[0032] The ephemeral key must be kept secret, or else the private key can be calculated given the message and the signature. Additionally, each time a signature is generated, a different ephemeral key must be used. If this were not the case, it would be 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 the corresponding signature (r, s), the signature can then be verified by completing the following steps:

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

[0035] 2. Multiplicative inverse s of s modulo n -1 Calculate.

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

[0037] 4. Calculate 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 Q:=(Q x ,Q y ) and u=Q x Calculate mod n. If u = r, the signature is valid.

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

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

[0042] 1. 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 is set Z n \{0} means a randomly generated element, where Z n \{0} is the notation for the set {1,...,n-1}. Then, each participant calculates a secret polynomial of degree t for i=1,...,N. f i (x)=a i0 +a i1 x+...+a it x t mod n Note that from now on we will omit the mod n notation and that all arithmetic operations on integers are assumed to be done modulo n.

[0043] 2. Each participant i sends a value f using a secure communication channel with only participant j. i (j) is sent to participant j.

[0044] 3. Each participant i calculates his / her private secret share of the shared secret polynomial.

[0045]

number

[0046] Calculate as follows.

[0047] The shared secret shares are of the form (i, a i ), where i is the participant label in the scheme. This method for creating secret shares of a, as described in steps 1-3, is referred to herein as i=JVRSS(i). Note that "JVRSS" typically stands for "Joint Verification Random Secret Sharing," which also includes steps 4 and 5. However, throughout this specification, JVRSS will be understood to mean performing at least steps 1 through 3, where steps 4 and 5 are optional.

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

[0049] 4. Each participant i, for k=0,...,t, calculates the obfuscation coefficient a ik G Broadcast to all participants.

[0050] 5. Each participant i receives f j (i) Calculate G, and

[0051]

number

[0052] By verifying that each participant j is at the polynomial point f j Check that you have calculated (i) correctly.

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

[0054] Reconstructing the Shared Secret Suppose a participant wishes to reconstruct a shared secret a, which is the zeroth degree of a shared polynomial. (1,a1),...,((t+1),a t+1 ) Given (t+1) points on this polynomial, then, to find the shared secret a, we derive a general formula called "Lagrange interpolation":

[0055]

number

[0056] Calculate.

[0057] Public Key Calculation N zeroth-degree private polynomial coefficient public keys a for i=1,...,N shared in step 4 of JVRSS i0 Given G, each participant creates a shared secret a

[0058]

number

[0059] to calculate the shared public key P.

[0060] Adding the Shared Secret To compute the addition of two shared secrets shared among a group of N participants, each with a degree t of secret polynomial, without any entity knowing the individual secrets, the following steps are taken:

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

[0062] 2. Generate a second shared secret b, where participant i’s share is calculated as b using a threshold of (t+1). i =JVRSS(i).

[0063] 3. Each participant i receives his / her additive share νi =a i +b i mod n Calculate.

[0064] 4. Every participant contributes his / her additive share ν i broadcast to all other participants.

[0065] 5. Each participant will receive a share of i Interpolate over at least (t+1) of ν=interpolate(ν1,...,ν t+1 )=a+b Calculate.

[0066] This method for adding the shared secret is denoted by ADDSS(i) for participant i and results in each participant i knowing v=(a+b).

[0067] Product of the shared secret To compute the product of two shared secrets, both 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 participant i's share is a for i=1,...,N i = JVRSS(i). The shared secret polynomial has degree t, meaning that (t+1) participants are required to recreate it.

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

[0070] 3. Each participant: μ i =a i b i Using its own multiplicative share μ i Calculate.

[0071] 4. Every participant contributes his / her multiplicative share μ i broadcast to all other participants.

[0072] 5. Each participant receives a share μ i Interpolate over at least (2t+1) of the μ=interpolate(μ1,...,μ 2t+1 )=ab Calculate.

[0073] This method for computing the product of two shared secrets is denoted herein by μ=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 taken:

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

[0076] 2. Each participant calculates the modular inverse of μ, which is μ -1 =(ab) -1 mod n The result is as follows.

[0077] 3. Each participant i:

[0078]

number

[0079] Calculate its reverse secret share by computing

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

[0081]

number

[0082] is shown by

[0083] Generating and verifying a 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 run JVRSS with a threshold of t+1 and public key computation as described above. The result is that all participants i=1,...,N share a secret key a i and the corresponding shared public key P = (a·G).

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

[0085] 1. Reverse sharing of the shared secret

[0086]

number

[0087] where (t+1) shares are needed to recreate it.

[0088] 2. Each participant is responsible for i Using the shared obfuscation coefficient in the verification of

[0089]

number

[0090] and then calculate r=x mod n Calculate.

[0091] 3. Each participant i:

[0092]

number

[0093] Remember.

[0094] Threshold Optimal Signatures FIG. 1 illustrates an exemplary system 100 for implementing a threshold-optimal signature scheme, e.g., a threshold-optimal ECDSA scheme. As illustrated, system 100 includes multiple parties, including a coordinator 101 and a group of participants 102. While only three participants 102 are shown in FIG. 1, it will be appreciated that a system may generally include any number of participants. Furthermore, although FIG. 1 illustrates coordinator 101 as distinct from the participants 102, in some embodiments, coordinator 101 may also be one of the participants 102, e.g., first participant 102a. Each of coordinator 101 and participants 102 operates a respective computing device.

[0095] Each of the respective computing devices of each party (i.e., the coordinator 101 and the participants 102) in the system 100 comprises a respective processing unit comprising one or more processors, e.g., 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 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, e.g., magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives. Each computing device may comprise at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a 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 (cloud computing resources comprising resources of one or more physical server devices implemented at one or more sites) accessed via the user terminal. It will be appreciated that any actions described as being performed by a party of system 100 may be performed by a respective computing device operated by that party.

[0096] The coordinator 101 is the party that initiates the signature using a threshold number of signature shares generated by each participant in the group of participants 102. That is, the coordinator 101 generates a signature for the message to be signed. Again, note that generating a signature for a message is understood to mean 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 or otherwise outputs the signature and optionally the message to a third party 103. For example, the third party 103 may be a certificate authority or other 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 publicly accessible medium.

[0097] The coordinator 101 may send a 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, a threshold number of participants. In the example of Figure 1, the group of participants comprises three participants 102a, 102b, and 102c. The coordinator 101 may send a message to one participant, who then forwards the message to one, some, or all of the other participants.

[0098] Messages may be sent over the Internet using LAN or WAN connections, or via alternative wired or wireless communication means. Messages may be sent individually to each participant 102, for example, via a secure communication channel between the coordinator 101 and each participant 102, or may be broadcast to the group as a whole, for example, via email or other means. Messages may be sent in raw or encrypted form. For example, messages 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 may otherwise be, for example, publicly available. One or more participants 102 may receive the message from a third party 103. A participant 102 that obtains 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 a 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 two, 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 that generate signature shares may transmit 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 publicly available. As mentioned above, the coordinator 101 may also be a participant. In those embodiments, the coordinator 101 may also generate their respective signature shares. In that sense, obtaining at least one of the threshold number of signature shares means generating at least one signature share; therefore, the coordinator 101 need receive fewer signature shares than the threshold number of signature shares.

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

[0102] Upon obtaining at least a threshold number of signature shares, the coordinator 101 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 it as part of a digital record, for example, in an email or other document.

[0103] Signature Shares i A method for generating a signature share is now described. While the method is described from the perspective of a first participant 102a, it will be appreciated that each other participant 102 that generates a signature share does so using an equivalent method, albeit using some data unique to that other participant 102.

[0104] Each participant 102 has the following data items: a respective private key share a i (i.e., shares of the same secret key), each ephemeral secret key share k i , and a shared common value r that is generated based on a common ephemeral public key k·G. The common ephemeral public key corresponds to, and is generated based on, an ephemeral private key. Here, a value or key may be common in the sense that each participant has access to that same value or key. Note that, unless 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 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 either 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. "First" in this context is merely used as an arbitrary label to distinguish a particular participant and a particular signature share from other participants and signature shares, respectively, and indicates that the first participant 102a generates a signature share s i or the first signature share s1 is the first participant to generate signature share s i Note that this does not necessarily imply that the element is first in the ordered list of elements.

[0107] In some embodiments, the first signature share s1 may be generated based on, i.e., is a function of, a first message-independent component (MIC) and a first message-dependent component (MDC), where again "first" is used only 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 may 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, 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 separate from the first signature share.

[0109] The coordinator 101 may obtain respective message-independent components (MICs) from at least a threshold number of participants and may generate a signature based on the respective signature shares (which are functions of the respective message-dependent components (MDCs)) and the respective message-independent components (MICs). More details are provided below.

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

[0111] Having generated the first signature share s1, the first participant 102a makes the first signature share s1 available to the coordinator 101 for generating a signature s on 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 noted above, the first signature share s1 may be generated based on the first MIC and the first MDC. Regardless of whether the first signature share is a function of the first MIC, the first MIC is generated based on (i.e., is a function of) the first private key share a1 (i.e., a share of the private key a known to the first participant 102a). The first MIC may also be based on a shared value r generated based on (i.e., is a function of) the first ephemeral private key share k1 (i.e., a share of the ephemeral private key k known to the first participant 102a) and the ephemeral public key k·G corresponding to the ephemeral private key k. The first MDC may be 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 private key share k1. Variations of MICs and MDCs are provided below.

[0113] Preferably, the first private key share a1 may be calculated using a joint secret sharing scheme, 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 private key share for participant 1 using a1=JVRSS(1), where the private key is denoted by a. Each participant may generate a respective private key share a i For example, the second participant 102b may generate a second private key share for participant 2 using a2=JVRSS(2), and so on.

[0114] Generating a first secret key share a1 using a joint secret sharing scheme involves generating a set of numbers a 1j ∈ R Z n \{0}, ∀j=0,...,t, and then generate the first polynomial f1(x)=a 10 +a 11 x+...+a 1t x tmod n, where the set of numbers are the coefficients of the polynomial. Each of the other participants 102 generates a respective polynomial using a respective set of numbers. For example, the second participant 102b generates a second polynomial f(x)=a 20 +a 21 x+...+a 2t x t mod n. The participants 102 then transmit the values ​​of their respective functions, evaluated at the indices of those other participants, to each of the other participants. For example, a first participant 102a evaluates f1(2) for a second participant 102b and then transmits that value to the second participant 102b, evaluates f1(3) for a third participant 102c and then transmits 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 a function of the first participant's index. The values ​​may be transmitted via the Internet or via other means. The values ​​may be transmitted via respective secure communication channels between each pair of participants. Rather than transmitting directly, one or more participants 102 (e.g., the first participant 102a) may broadcast their respective values. Having 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, e.g., f2(1), f3(1), etc.

[0115] The first participant may calculate a corresponding public key a·G based on the set of obfuscation coefficients, where the coefficients are the respective private key shares a of each participant 102. i is used to generate the ephemeral private key share k i When generating ijThe participants 102 may share G with each other participant 102. The coefficients are obfuscated by a common generator point G on the chosen elliptic curve. These obfuscated coefficients may be transmitted directly between the participants 102 or may be broadcast to the group. For example, the first participant 102a may share obfuscated coefficient a 10 G, a 11 G, a 12 The public key corresponding to the private key may then be broadcast as follows:

[0116]

number

[0117] It can be calculated as:

[0118] Private key share a i Note that s may be generated using alternative methods, i.e., without using the JVRSS method described above. Each participant generates their signature share s i Although shares of the private key a are required to generate the private key shares, the particular method for generating the private key shares may be chosen to suit a particular scenario, e.g., whether some, all, or none of the participants may be trusted, or whether a trusted dealer is available to distribute the key shares. Methods for generating private key shares are known per se in the art. Similarly, methods for distributing shares of a private key (or other such data) are known per se in the art. That said, private key shares a i can be generated in several ways, for example using Shamir's secret sharing scheme, e.g., to generate a secret key share a i A dealer (e.g., a coordinator) may 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 is described in WO2017145010A1.

[0119] Similarly, the private key shares described below, e.g., the ephemeral private key share k i , a first blinding value key share α i , and / or a second blinding value key share β i When generating some or all of the above, an alternative form of JVRSS may be used.

[0120] The first ephemeral private key share k1 may be calculated using a joint secret sharing scheme, 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 may generate its own ephemeral private key share k i For example, the second participant 102b may generate a 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 the joint secret sharing scheme 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 is used for each signature, but the ephemeral private key k and ephemeral private key share k i Note that changes for each signature.

[0123] The shared value r is generated based on the ephemeral public key k·G corresponding to the ephemeral private key k. The ephemeral public key (x, y) has two components, typically called the x component and the y component. The shared value r may be a function of the x component of the ephemeral public key, e.g., r=x mod n.

[0124] The ephemeral public key k·G may be generated based on a set of obfuscation coefficients, which are the respective ephemeral private key shares k of each participant 102. i was used to generate the ephemeral private key share k i When generating ij G with each of the other participants 102. The coefficients are obfuscated by a common generator point G on the chosen elliptic curve. These obfuscated coefficients may be transmitted directly between the participants 102 or may be broadcast to the group. For example, the first participant 102a may share the obfuscated coefficient k 10 G, k 11 G, k 12 The ephemeral public key may then be broadcast as follows:

[0125]

number

[0126] It can be calculated as:

[0127] In some embodiments, the first MIC is a first reverse share corresponding to the first ephemeral private key share k1.

[0128]

number

[0129] That is, the first inverse share

[0130]

number

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

[0132] First Reverse Share

[0133]

number

[0134] For example, for participant 1,

[0135]

number

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

[0137] This means that each participant 102 receives a multiplicative share μ i =k i α i may involve generating i is a share of the first blinding key α. Each participant 102 uses a joint secret sharing scheme, for example the JVRSS technique described above, to derive its respective share α of the first blinding key α. i For example, the first participant 102a may have an index of 1 and may generate a share of the first blinding key using α1=JVRSS(1) for participant 1. Each participant may then calculate (e.g., via direct transmission or broadcasting) its respective multiplicative share μi and then, for example, by interpolation, the multiplicative share μ i Generate an intermediate value μ based on each of the first inverse share

[0138]

number

[0139] may be generated by computing the inverse of the intermediate value μ. For example, the first participant 102a may compute the modular inverse of μ, which is μ -1 =(kα) -1 mod n The result is as follows.

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

[0141]

number

[0142] By calculating -1 and a first reverse share based on its respective first blinding key share α1.

[0143]

number

[0144] You may calculate:

[0145] Blinding Key Share α i Note that the use of is optional and may be omitted from the above steps.

[0146] Optionally, a MIC may be generated based on (i.e., may be a function of) a share of the second blinding key β. That is, the MIC is also based on the first share β1 of the second blinding key β in addition to the previously mentioned data items. The first share of the second blinding key may be calculated using a joint secret sharing scheme, 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 share of the second blinding key using β1=JVRSS(1) for participant 1, where the second blinding key is denoted by β.

[0147] The MIC may be generated based on a first pre-signature share σ, which is a first intermediate share λ and respective intermediate shares λ obtained from at least a threshold number of participants 102. i That is, each participant 102 receives their respective intermediate share λ i and their intermediate share λ i may be transmitted and / or broadcast to the other participants 102. The first participant 102a may transmit and / or broadcast the intermediate share λ i For example, the intermediate share λ i A common intermediate value λ may be generated by interpolation of σ 1 '. The first participant 102a (and optionally other participants 102) may generate multiple pre-signature shares σ 1 ', each for use in generating a different signature share s 1 '.

[0148] The first intermediate share λ1 is a first secret key share a1 and a first reverse share

[0149]

number

[0150] In that case, each of at least a threshold number of participants 102 will have their respective private key a i Shares and their respective reverse shares

[0151]

number

[0152] Each intermediate share, λ, is a function of i Generate and share.

[0153] Alternatively, the first intermediate share λ1 may be a function of the first private key share a1 and the first share of the first blinding key α1, in which case each of at least a threshold number of participants 102 will receive their respective private key share a i and each intermediate share λ, which is a function of its own respective share of the first blinding key α1. i Generate and share.

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

[0155] 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 performed, in this example, by each of a threshold number of participants 102 (including the first participant 102a). Step S209 is performed by the coordinator 101, which 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 allows for the creation of a shared secret of a threshold (t+1) among a group of N≧2t+1 participants, where the signing threshold is also (t+1).

[0157] set up In step S201, each participant 102 calculates a shared secret key share and a corresponding public key. For example, each participant 102 may calculate a shared secret key and a corresponding public key using JVRSS and the public key calculation given in the introduction. At this point, each participant i calculates 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] Precomputation In step S202, each participant 102 calculates a shared ephemeral key share and a corresponding public key. For example, each participant 102 may calculate a shared ephemeral key using the JVRSS and the calculation of the public key given in the preamble. Each participant 102 may then calculate a reverse share based on the ephemeral private key. This means that, using a threshold of (t+1), each participant calculates a reverse share.

[0159]

number

[0160] The result is

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

[0162] In step S204, each participant 102 calculates its median share and broadcasts its median share to the other participants. For example, each participant i calculates its median share

[0163]

number

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

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

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

[0167]

number

[0168] , and the private key share and the corresponding public key (a i , P).

[0169] Note that because a different ephemeral key is used for each signature, multiple ephemeral keys can be set up at once, i.e., steps S202-S206 can be repeated to create multiple ephemeral keys during pre-computation and stored for later use. These can be performed simultaneously so that there are no additional rounds 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 perform steps S207 and S208.

[0171] In step S207, at least a threshold number of participants 102 obtain the message to be signed and calculate a 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 a threshold number of participants 102 calculate and send their signature shares to the coordinator 101. For example, each participant i calculates its signature share

[0173]

number

[0174] Then, the 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 calculates a signature s=interpolate(s1,...,s t+1 )=k -1 (e+ar), and finally the signature (r,s).

[0176] There are several alternatives for precomputing the message-independent component of the signature share. These fall into two sets of variants: when r should be included in the calculation, and when (kα) -1 These can be selected independently from each other, so there are eight variations of the method 200 above.

[0177] One modification is to add, during step S206:

[0178]

number

[0179] This means that r is included in the pre-signature share.

[0180] Another modification is that the multiplication with r can also come earlier during the calculation of the intermediate shares.

[0181]

number

[0182] Then, in step S206, σ i =λ-β i =(rk -1 a+β)-β i The signature share is calculated as follows:

[0183]

number

[0184] This becomes:

[0185] Another modification is λ i =α i a i +β i instead, so that λ=(kα) -1 (αa+β) and σ i =λ-(kα) -1 β i Two variants involving r at alternative points can be done in combination with this. Each participant has knowledge of kα as calculated in the pre-computation step S202. Additionally, every participant 102 has knowledge of its λ i The participants then broadcast their shares, so that each participant 102 has (at least) 2t+1 shares and knowledge of the value kα. λ=(kα) -1 ×interpolate(λ1,...,λ 2t+1 ) can be calculated.

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

[0187]

number

[0188] Two variations on when r should be included in the calculation can also be made in conjunction with this. Each participant 102

[0189]

number

[0190] Participants then use this knowledge to calculate (kα) -1 mod n, and then calculate it as s i can be included in the calculation of

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

[0192]

number

[0193] (Interpolation over these shares is used to calculate k as α vanishes.) -1 gives k -1 a uses the first product, so when the share is expanded, the calculated

[0194]

number

[0195] gives kα and α i Made from

[0196]

number

[0197] Any calculation involving shares begins with α i Perform calculations involving only kα itself, and then, if necessary, (kα) -1 This can be done by multiplying by

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

[0199] An equivalent scheme comprises, for example, calculating the MIC as above after interpolation of the signature shares made from the MDC alone, and then incorporating this together with the signature shares into the signature. Notably, the scheme may be the same up to the pre-computation step S206, where the intermediate shares include the r value, i.e.

[0200]

number

[0201] and so after interpolation, this becomes λ=k -1 It becomes ar+β.

[0202] In this stage, participants

[0203]

number

[0204] and has knowledge of the private key share and the corresponding public key (a i ,P).

[0205] To generate their signature share for a given message m, which is then hashed to create a message digest e=hash(m), participants

[0206]

number

[0207] and sends it to the coordinator. The coordinator then s=interpolate(s1,...,s t+1 )+λ =k -1 e+k -1 ar , which yields the expected signature share since the β term vanishes. A similar variation of this protocol is (kα) -1 This can be done as above, which describes when r and r are included in the calculation.

[0208] The following variations for computing the message-independent component can be implemented.

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

[0210]

number

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

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

[0213] iii) Calculate as follows: λ=αa+β Then, the signature share is now:

[0214]

number

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

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

[0217]

number

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

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

[0220]

number

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

[0222] One difference between method 200 and previous schemes is that k in the signature -1The computation of term a can be moved into the precomputation stage. The consequence of this is that the signature generation has the same threshold as the private key computation, and is therefore now threshold-optimal. To understand how the exact signature is found, consider that interpolation over the signature shares yields s=k -1 e+r(k -1 a+β-β) =k -1 e+r(k -1 a) =k -1 (e+ar) and note that this is exactly the signature that is required.

[0223] Note that the secret thresholds can be different; that is, the thresholds of a, k, α, and β themselves do not necessarily need to be the same in order for the signature generation scheme to work. For example, if you have a group of six people and three of them are needed to create the signature and / or private key, they could technically do that calculation with a threshold of 4 for k and a threshold of 3 for the other shared secrets and they would still have a threshold-optimal scheme.

[0224] Note that if a blinding secret β is not used, it may be possible to compute the ephemeral key, and therefore the shared secret, in the following way: -1 a) and that participants also know r, e, and s. (s-(k -1 a)r)e -1 =k -1 can be calculated.

[0225] This result is then (k -1 ) -1 (k -1 a)=a , which is the shared secret key.

[0226] This calculation cannot be done by including β in the calculation. -1 a+β) is the information about each secret and the result k -1 To obtain any information that would reveal the private key a, at least (t+1) participants, the same number as the private key threshold, must cooperate, so computing this intermediate value λ does not reduce security.

[0227] The problem to be solved using the previous threshold-optimal signature computation is to compute the product of two shared secrets, where the secret is the sum of the individual secrets of all participants in the group.

[0228]

number

[0229] is.

[0230] In a signature, if the private key a is a shared secret, then k must be as well (otherwise a can be calculated by anyone who knows k). The second term in the signature is then the multiplication of two shared secrets, which is what makes optimality difficult to achieve. In the non-optimal scheme by Gennaro et al. and the exemplary method 200 described above, these secrets are each polynomials of degree t, and multiplying the polynomials together results in a threshold of 2t+1 shares being required to calculate the result of the multiplication. To ensure fairness in this scheme, most communications can be broadcast, and simple equality checks can be made. Additionally, if one participant drops out of the signature calculation, it is easy for another participant to contribute.

[0231] In the threshold-optimal scheme by Gennaro et al., this 2t+1 threshold is avoided by computing each term in the secret product separately. That is, each pair of participants i,j computes the individual terms a i0k j0 and sum these results. During signing, an ephemeral key k is created, and then these products of the individual private contributions are calculated using Pallier encryption. This requires that each participant must communicate individually with every other signer. To ensure fairness in this case, there are multiple zero-knowledge proofs that must be performed. In this case, if a participant drops out of the signature calculation, the signing 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 It is a multiplication of two sums of individual terms, which can be extended and expanded as follows:

[0233] The Gennaro method calculates these terms separately. That is, participant 1, together with participant 2, calculates a 20 b 10 We also had to calculate a 30 b 10 , and so on. These are then all summed together. These individual calculations involve zero-knowledge proofs which are computationally expensive, so as soon as there are many people in the scheme, the scheme becomes inefficient. This is also all done in the signing stage, so it is a computationally expensive way to calculate a signature.

[0234] In a simple case with three participants, the rounds of communication are roughly equivalent between the two schemes (i.e., the optimal threshold scheme by Gennaro et al. and exemplary method 200), but the Gennaro scheme has more, and this is not where the main efficiency savings lie. The savings are in the volume of data computed and communicated. Gennaro's scheme must include multiple zero-knowledge proofs (ZKPs), which are not present in exemplary method 200.

[0235] The following compares exemplary method 200 with a two-out-of-three scheme implemented using the optimal threshold scheme by Gennaro et al. In Gennaro's scheme, there are additional encryption keys to be created for the JVRSS before signing and 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 phase. Additionally, in some steps, each participant must communicate individually with every other participant in the signing phase, which is inefficient. This means that the participants must all be online at the same time. In contrast, the present invention allows a given participant to calculate signature shares without other participants being online.

[0236] In contrast, in the scheme described above, there are four JVRSS calculations in the pre-signing phase, and there is no ZKP at any point. The JVRSS calculations can be performed simultaneously, so the communication is the same as for a single JVRSS. In the signing phase, there is only request-response communication, and all information can be broadcast to the group.

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

[0238] To summarize, Gennaro's scheme reduces the storage required after setup and pre-computation, but increases computation and communication during signature computation. This is due to the inefficiency of moving more of the computation to pre-signing in Gennaro's scheme. Our scheme is more efficient than Gennaro's optimal scheme, especially when the inequality N≧2t+1 is admissible.

[0239] Exemplary Use Cases In general, the present invention can be used to generate a signature for any message. As a specific exemplary use case, the message can 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 illustrates an exemplary transaction protocol for use as part of a blockchain protocol. Exemplary blockchain protocols are well documented in the literature, but a description of an exemplary protocol transaction is provided here for completeness. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is a fundamental data structure of a blockchain (each block of the blockchain comprises one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol, although this is not limiting to all possible embodiments.

[0241] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure comprising 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 the input 202 of another new transaction (if the UTXO has not already been redeemed). A UTXO includes a value that specifies an amount of digital tokens, e.g., represents an amount of digital assets. This represents a set number of tokens on the ledger (to be delivered). 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 indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to a miner.

[0242] A first user, say Alice, wishes to create transaction 152j to transfer a certain amount of digital tokens to a second user, say Bob. In Figure 3, Alice's new transaction 152j is labeled "Tx1." It removes the amount of digital tokens locked for Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least some of them to Bob. The previous transaction 152i is labeled "Tx0" in Figure 3. Tx0 and Tx1 are arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain or that Tx1 is the immediate next transaction in the pool. Tx1 can point backward to any previous (i.e., antecedent) transaction that still has unspent outputs 203 locked for Alice.

[0243] By the time Alice creates her new transaction Tx1, or at least by the time she sends it to the network 106, the preceding transaction Tx0 may already be valid and included in the blockchain. It may already be included in one of the blocks at that time or may still be waiting in the pool 154, in which case it will soon be included in a new block. Alternatively, Tx0 and Tx1 may be created and sent to the blockchain network together, or Tx0 may be sent even after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “preceding” and “successor,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence (e.g., which transaction points backward to which other transaction), as defined by transaction pointers specified in the transactions. They may be equivalently substituted for "predecessor" and "successor," or "ancestor" and "descendant," "parent" and "child," or the like. That does not necessarily imply the order in which they are created, sent to the network, or arrive at any given node. However, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not valid until and unless the parent transaction is valid. A child that arrives at a node before its parent is considered an orphan. An orphan may be discarded or buffered for some time to wait for its parent, depending on the node protocol and / or minor behavior.

[0244] One of the one or more outputs 203 of the 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 locking script that defines the conditions that must be met by an unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be valid, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks that amount to a particular party (the beneficiary of the transaction whose locking script is included therein). That is, the locking script typically defines an unlocking condition that comprises the condition that an unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to whom the preceding transaction is locked.

[0245] A lock script (aka scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S). A lock script specifies what information is needed to consume the transaction output 203, for example, the requirements of Alice's signature. An unlock script appears in the transaction's output. An unlock script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. An unlock script appears in the transaction's input 202.

[0246] Therefore, in the illustrated example, UTXO0 in the output 203 of Tx0 is the lock script [Checksig P A ] and the lock script [Checksig P A ] must be present in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A [Checksig PA ] is the public key P from Alice's public-private key pair. A The input 202 of Tx1 comprises a pointer that points back into Tx1 (e.g., by its transaction ID, i.e., TxID0, which in an embodiment is a hash of the entire transaction Tx0). The input 202 of Tx1 comprises an index that identifies UTXO0 within Tx0, to distinguish it among any other possible outputs of Tx0. The input 202 of Tx1 comprises an unlock script <Sig P A >Further equipped with unlock script <Sig P A > comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). What data (or "message") needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or a combination of these.

[0247] When a new transaction Tx1 arrives at a node, the node applies the node protocol, which comprises running the lock script and the unlock script together and checking whether the unlock script satisfies a condition defined in the lock script (where this condition may comprise one or more criteria). In an embodiment, this means concatenating the two scripts, i.e. <Sig P A > <P A > || [Checksig P A ] where "||" denotes concatenation, "<...>" denotes the location of the 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 run one after the other using a common stack rather than concatenating the scripts. Either way, when run together, the scripts will find Alice's public key P as contained in the lock script in the output of Tx0.A , to authenticate that the lock script in Tx1's input contains Alice's signature signing the expected portion of the data. The expected portion 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 (so a separate element specifying the signed portion of the data in plaintext must be included, as it is already inherently present).

[0248] The details of authentication via public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then given Alice's public key and the message in plaintext (the unencrypted message), another entity, such as a node in a blockchain network, can authenticate that the encrypted version of the message was signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature on the plaintext version of the message, thus allowing 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 embodiments, mean signing a hash of such piece of data or part of a transaction.

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

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

[0251] Note that script code is often expressed schematically (i.e., not in a precise language). A ] = OP_DUP OP_HASH160 <H(P A )> OP_EQUALVERIFY [Checksig P A ]. "OP_..." refers to a specific opcode in the Script language. OP_CHECKSIG (also known as "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 occurrences of the signature ("sig") are removed from the script, but additional requirements, such as a hash puzzle, remain in the transaction to be 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 could comprise a document that one wishes to store in the blockchain.

[0252] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific piece of data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific parts of the outputs it signs depend on the SIGHASH flag, which is a four-byte code included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

[0253] A lock script may be referred to as a "scriptPubKey," referring to the fact that it provides the public key of the party to whom each transaction is locked. An unlock script may be referred to as a "scriptSig," referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain that the condition for a UTXO to be redeemed comprises authenticating the signature. More generally, a scripting language may be used to define any condition or conditions. Therefore, the more general terms "lock script" and "unlock script" may be preferred.

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

[0255] When expressed in a script, the "lock script" and "unlock script" may take the following form: Locking script = OP_DUP OP_HASH160<Public KeyHash> OP_EQUAL OP_CHECKSIG Unlocking script = <signature><Public Key>

[0256] With reference to the above described embodiments,<Public Key> may be considered equivalent to P=a·G, <signature>r comprises a threshold signature s, where the previous transaction is the message to be signed. Note that, as mentioned above, ECDSA signatures are of the form (r, s).

[0257] It should be noted that the described signature generation method is not limited to any particular use case and may generally be used to generate a signature based on any message. Signing all or part of a blockchain transaction is just one illustrative example. The described method may be used, for example, to sign and / or authenticate legal documents (e.g., wills, deeds, or other contracts), letters between one or more parties, digital certificates (e.g., issued by a certificate authority), medical prescriptions, bank transfers or financial instruments, mortgage or loan applications, etc.

[0258] As a specific example, a group of participants (e.g., five participants total) may form the board of directors of a company. A voting matter for that company may require a majority of the board (i.e., at least three participants) to agree on a particular vote. The board may use the described signature generation method to prove that at least three board members agreed to vote in favor of a particular outcome. In this example, the threshold for the signature generation scheme is three. That is, at least three of the board members must provide their respective signature shares for the coordinator to successfully generate a signature. If the signature is successfully generated, at least the threshold number (i.e., three) of board members must have agreed to vote in favor of that outcome. Thus, the successful generation of a signature serves as a record of the vote and proves in a specific way that a majority of the board 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 contains a signature that signs over some data. The data can generally be any data, but a specific example of data included in a digital certificate is a public key. The public key in a digital certificate is often called a "certified public key." The issuer of the digital certificate (a "certification authority") may perform one or more checks (e.g., a know-your-customer check) on the owner of the public key, and if the checks are successful, the certification authority issues a digital certificate that includes the certified public key. A user can use the certified public key to prove that they are who they say they are, for example, by signing a message with the private key that corresponds to the certified public key.

[0260] One specific use for a certificate authority is to sign certificates used in HTTPS for secure browsing on the Internet. Another common use is when issuing identity cards by national governments for use in electronically signing documents. The certificate authority uses its private key to sign the public key (or any other data to be certified). This introduces a single point of failure: if a malicious party can gain access to the private key used by the certificate authority to issue a digital certificate, the malicious party can then issue a fraudulent certificate. A specific example of a certificate authority being targeted is DigiNotar, a Dutch certificate authority. 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 certificate authority (DigiNotar) used a threshold signature scheme in accordance with the present invention, this attack would not be possible (or would at least be made more difficult). To issue a certificate, an attacker must obtain a threshold number of key shares (or signature shares) required to generate a signature.

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

[0262] Statement 1. 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 performed by a first of the participants; generating a first message-independent component and a first message-dependent component, the message-independent component being generated based on the first secret key share and the message-dependent component being generated based on the message; making the first message-independent component available to the coordinator; making a first signature share available to a coordinator for generating a signature based on at least a threshold number of signature shares, the first signature share comprising at least a 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 retrieving the message.

[0265] In other words, the message-independent component may be pre-computed, i.e., generated prior to obtaining (e.g., receiving) the message. Then, once the message has been obtained, the message-dependent component may be generated, thus allowing the signature share to be generated.

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

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

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

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

[0270] Statement 6. The method of statement 5, wherein obtaining the respective data items comprises obtaining the respective data items via respective communication channels between the first participant and each of the respective participants.

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

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

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

[0274] In some examples, the joint secret sharing scheme may include: sharing a respective set of coefficients of the first polynomial obfuscated with the generator value with each of at least a threshold number of participants; obtaining a respective set of coefficients of a respective polynomial generated by each respective participant, wherein the respective set of coefficients is obfuscated using a generator value; For each participant, determining a first candidate value based on each data item obtained from the participant and obfuscated using the origin value; determining a second candidate value based on the respective sets of obfuscation coefficients obtained from the respective participants; and By verifying that the first candidate value corresponds to the second candidate value, and verifying that each participant has correctly generated its respective private key share. It may be a jointly verifiable secret sharing scheme.

[0275] Statement 8. The method of any preceding statement, wherein each participant has a respective ephemeral private key share, and wherein the first message-independent component and / or the first message-dependent component are based on the first ephemeral private key share.

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

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

[0278] Statement 11. The method of any preceding statement, wherein the first message-independent component is generated based on an inverse element corresponding to the first ephemeral private key share.

[0279] Statement 12. The method of statement 11, wherein generating the inverse of the first ephemeral private key share comprises: generating an intermediate value based on the ephemeral private key and the first blinding key; generating an inverse of the first ephemeral private 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 private key and the first blinding key.

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

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

[0283] Note that in some instances, the threshold number of participants required to generate multiplicative key shares is different from the threshold number of participants required to generate private key shares, e.g., the private key has a threshold of t+1, and the multiplicative key shares require 2t+1.

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

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

[0286] Statement 17. The method of statement 16, wherein the second blinding key shares are generated using a joint secret sharing scheme for generating the second blinding key shares.

[0287] Statement 18. The method of statement 11 or any statement 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, the first intermediate share being generated based on the first private key share and an inverse element corresponding to the first ephemeral private key share; and The median shares are generated based on respective median shares obtained from at least a threshold number of participants.

[0288] Statement 19. The method of statement 11 when subject to any of statements 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, the first intermediate share being generated based on the first secret key share and the first blinding key share; The median shares are generated based on respective median shares obtained from at least a threshold number of participants.

[0289] Statement 20. The method of statement 19, wherein the first pre-signature share is generated based on an inverse corresponding to the first ephemeral private key share.

[0290] Statement 21. The method of any of statements 18-20, wherein the first intermediate share is generated based on the second blinding key share.

[0291] Statement 22. The method of any of statements 18-21, wherein the first pre-signature share is generated based on the shared value.

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

[0293] Statement 24. The method of either statement 18 or statement 19 or any statement dependent thereon, comprising transmitting the first intermediate shares to at least a threshold number of participants.

[0294] Statement 25. The method of any preceding statement, comprising generating a plurality of distinct instances of the message-independent component.

[0295] Statement 26. The method of any preceding statement, comprising generating a plurality of distinct instances of the first ephemeral private key share.

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

[0297] Statement 28. The method of either statement 18 or statement 19 or any statement dependent thereon, comprising generating a plurality of distinct instances of a first pre-signed share.

[0298] Statement 29. The method of any preceding statement, comprising obtaining a message from a coordinator.

[0299] Statement 30. The method of any of statements 1-28, comprising generating a message.

[0300] Statement 31. The method of any of the preceding statements, wherein the message is a hash of a second message.

[0301] Statement 32. The method of any preceding statement, wherein said making available a first signature share to a coordinator comprises: sending the first signature share to the coordinator; broadcasting the first signature share to one or more of the threshold number of participants.

[0302] Statement 33. The method of any preceding statement, wherein making the first message-independent component available to the coordinator comprises: sending the first message-independent component to the coordinator; broadcasting the first message-independent component to one or more of the threshold number of participants.

[0303] Statement 34. A computer-implemented method for generating a digital signature for a message, wherein a threshold number of distinct 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 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 a message; generating a signature for the message based on each of the obtained signature shares and each of the obtained message-independent components.

[0304] Each 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] Statement 35. The method of statement 34, wherein each respective signature share is based on a respective message-independent component.

[0308] Statement 36. The method of statement 34, 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] Statement 37. The method of any of statements 34-36, wherein each participant has a respective ephemeral private key share, and each respective message-independent component and / or message-dependent component is based on the respective ephemeral private key share.

[0310] Statement 38. The method of statement 37, wherein each participant has a shared value that is based on an ephemeral public key corresponding to the ephemeral private key, and each respective message-independent component is based on the shared value.

[0311] Statement 39. The method of any of statements 34-38, comprising sending a message to one, some, or all of the participants in the threshold number of participants.

[0312] Statement 40. The method of any of statements 34-39, comprising sending requests for respective signature shares to at least a threshold number of participants.

[0313] Statement 41. The method of any of statements 34 through 40, comprising generating one of the obtained signature shares.

[0314] Statement 42. Any of the methods of statements 34-41, comprising outputting a signature.

[0315] Statement 43. The method of statement 42, wherein outputting the signature comprises: Sending the signature to one or more parties; and / or Recording your signature on a digital medium; and / or The signature is made public.

[0316] Statement 44. The method of any preceding statement, wherein the message comprises at least a portion of a blockchain transaction.

[0317] The message may alternatively comprise one of at least a portion of a document (eg, a legal document), a digital certificate, a medical prescription, or a financial instrument.

[0318] Statement 45. The method of any preceding statement, wherein the threshold number of participants is less than the total number of participants in the group of participants.

[0319] Statement 46. A computer device, a memory comprising one or more memory units; a processing device having one or more processing units, wherein the memory stores code configured to execute on the processing device, the code being configured to perform any of the methods of statements 1 to 45 when executed on the processing device.

[0320] Statement 47. A computer program embodied on a computer-readable storage and configured to perform the method of any of statements 1 to 45 when executed on the computer device of statement 46.

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

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

[0323] Given the disclosure herein, other variations or uses of the disclosed techniques may become apparent to those skilled in the art. The scope of the present disclosure is limited only by the appended claims, and not by the described embodiments. [Explanation of symbols]

[0324] 100 systems 101 Coordinator 102 participants 103 Third Party 152 transactions 201 Header 202 Input, input field 203 Output, Output Field< / signature> < / signature>

Claims

1. 1. A computer-implemented method for generating shares of a digital signature for a message, wherein a threshold number of different signature shares are required from each participant of a group of participants to generate the digital signature, each participant having a respective share of a private key; the computer-implemented method being performed by a first one of the participants; generating a first message-independent component and a first message-dependent component, the message-independent component is generated based on a first secret key share; the message-dependent component is generated based on the message; Each participant has their own ephemeral private key share, the first message-independent component and / or the first message-dependent component are 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; the first signature share comprising at least the message-dependent component; A computer-implemented method comprising:

2. The method of claim 1 , wherein the message-independent components are generated before obtaining the message.

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

4. 4. The method of claim 1, wherein the first private key share is generated using a joint secret sharing scheme for generating shares of a first private key.

5. generating the first secret key share using the joint secret sharing scheme; generating a first data item, the first data item being a first polynomial; obtaining respective data items from at least the threshold number of participants, each respective data item being 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 of claim 4, comprising:

6. said step of obtaining each data item comprises:

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

7. transmitting a respective instance of the first polynomial to each of at least the threshold number of participants; The method of claim 5 , wherein the respective instances of the first polynomial are based on respective participants.

8. each participant having a respective shared value based on an ephemeral public key corresponding to said ephemeral private key; The method of claim 7 , wherein the first message-independent component is based on the shared value.

9. 9. The method of claim 1, wherein the first ephemeral private key share is generated using the joint secret sharing scheme for generating shares of the ephemeral private key.

10. 10. The method of claim 1, wherein the first message-independent component is generated based on an inverse element corresponding to the first ephemeral private key share.

11. generating the inverse of the first ephemeral private key share; generating an intermediate value based on the ephemeral private key and a first blinding key; generating an inverse of the first ephemeral private key share based on an inverse of the intermediate value and a first blinding key share of the first blinding key; The method of claim 10, comprising:

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

13. The intermediate value is generating a first multiplicative key share based on the first ephemeral private key share and the blinding key share; obtaining respective multiplicative key shares from at least the threshold number of participants; generating the intermediate value based on the first multiplicative key share and each of the respective multiplicative key shares; 13. The method of claim 11 or 12, wherein the compound is produced by

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

15. 15. The method of claim 1, wherein the message-independent component is generated based on a second blinding key share of a second blinding key.

16. 16. The method of claim 15, wherein the second blinding key share is generated using the joint secret sharing scheme for generating the second blinding key share.

17. the first message-independent component is generated based on a first pre-signature share; The first pre-signed share comprises: a first intermediate share, the first intermediate share being generated based on the first private key share and the inverse element corresponding to the first ephemeral private key share; and each intermediate share obtained from at least said threshold number of participants; The method of claim 10 or any claim dependent thereon, wherein the method is generated based on

18. the first message-independent component is generated based on a first pre-signature share; The first pre-signed share comprises: a first intermediate share, the first intermediate share being generated based on the first private key share and the first blinding key share; each intermediate share obtained from at least said threshold number of participants; The method of claim 10 when dependent on any of claims 1 to 16, wherein the method is generated based on

19. 20. The method of claim 18, wherein the first pre-signature share is generated based on the inverse element corresponding to the first ephemeral private key share.

20. 20. The method of any one of claims 17 to 19, wherein the first intermediate share is generated based on the second blinding key share.

21. 21. The method of claim 17, wherein the first pre-signature share is generated based on the shared value.

22. The method of claim 21 , wherein the first intermediate share is generated based on the shared value.

23. 19. A method according to any one of claims 17 or 18 or any claim dependent thereon, comprising transmitting the first intermediate share to at least the threshold number of participants.

24. 24. A method according to any preceding claim, comprising generating a plurality of different instances of the message-independent component.

25. 25. The method of any one of claims 1 to 24, comprising generating a plurality of different instances of the first ephemeral private key share.

26. 26. A method according to claim 24 or 25, comprising generating a plurality of different instances of the first blinding key share and / or the second blinding key share.

27. 19. A method according to any one of claims 17 or 18 or any claim dependent thereon, comprising generating a plurality of different instances of the first pre-signed share.

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

29. 29. A method according to any preceding claim, comprising generating the message.

30. 30. The method of any one of claims 1 to 29, wherein the message is a hash of a second message.

31. making the first signature share available to the coordinator; sending the first signature share to the coordinator; broadcasting the first signature share to one or more of the threshold number of participants.

31. The method of claim 1, comprising at least one of:

32. making the first message-independent component available to the coordinator; sending the first message-independent component to the coordinator; broadcasting the first message-independent component to one or more of the threshold number of participants.

32. The method of any one of claims 1 to 31, comprising at least one of:

33. 1. A computer-implemented method for generating a digital signature for a message, comprising: generating the digital signature by using a threshold number of distinct signature shares from each participant of a group of participants, each participant having a respective private key share; and each participant having a respective ephemeral private key share; the computer-implemented method being executed 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 said 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 is generated based on said message; generating the digital signature for 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 based on a respective ephemeral secret key share; A computer-implemented method comprising:

34. 34. The method of claim 33, wherein each respective signature share is based on the respective message-independent component.

35. 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; 34. The method of claim 33, comprising:

36. each participant has a shared value based on an ephemeral public key corresponding to said ephemeral private key; 36. The method of claim 35, wherein each respective message-independent component is based on the shared value.

37. 37. A method according to any one of claims 33 to 36, comprising sending the message to one, some or all of the participants in the threshold number of participants.

38. 38. A method according to any one of claims 33 to 37, comprising sending requests for respective signature shares to at least the threshold number of participants.

39. 39. A method according to any one of claims 33 to 38, comprising generating one of the obtained signature shares.

40. 40. The method of any one of claims 33 to 39, comprising outputting the digital signature.

41. The step of outputting the digital signature comprises: sending said digital signature to one or more parties; and / or recording said digital signature on a digital medium; and / or making the digital signature public 41. The method of claim 40, comprising:

42. 42. The method of any one of claims 1 to 41, wherein the message comprises at least a portion of a blockchain transaction.

43. 43. The method of any one of claims 1 to 42, wherein the threshold number of participants is less than the total number of participants in the group of participants.

44. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units; 44. A computing device comprising: a memory storing code configured to execute on the processing unit; and the code configured, when executed on the processing unit, to perform the method of any one of claims 1 to 43.

45. 47. A computer program embodied on a computer readable storage and configured to perform the method of any one of claims 1 to 43 when executed on a computing device according to claim 46.

Images