Generating a digital signature

By generating temporary keys for unique subgroups, participants can prove their contribution to the signature, addressing the issue of unidentified contributors in threshold signature schemes and ensuring valid signature generation.

JP7871370B2Active Publication Date: 2026-06-08NCHAIN LICENSING AG

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
NCHAIN LICENSING AG
Filing Date
2022-07-11
Publication Date
2026-06-08

AI Technical Summary

Technical Problem

Threshold signature schemes do not provide a way to identify which participants contributed to a generated signature, leading to potential fraud or false claims of participation.

Method used

A method where participants generate temporary private and public keys for unique subgroups, allowing them to prove their contribution to the signature by using signature shares based on these keys, ensuring only the subgroup with access to the corresponding temporary public key can generate a valid signature.

Benefits of technology

Enables participants to prove their contribution to the signature, preventing false claims and ensuring the validity of the signature generation process.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007871370000019
    Figure 0007871370000019
  • Figure 0007871370000020
    Figure 0007871370000020
  • Figure 0007871370000021
    Figure 0007871370000021
Patent Text Reader

Abstract

A computer-implemented method for verifying that a target subgroup generated a digital signature, the group being divisible into a number of unique subgroups, each subgroup including at least a threshold number of participants, the method includes generating a first ephemeral private key share for each subgroup to which the first participant belongs, the other participants in each subgroup generating respective ephemeral private key shares, generating respective shared ephemeral public keys for each shared ephemeral private key, generating a first signature share of a signature based on the first private key share, the first ephemeral private key share of the target shared ephemeral private key for each shared ephemeral private key, and the message, and making the first signature share available to a coordinator for generating a signature.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] This disclosure relates to a method for generating digital signatures and a method for proving that participants have contributed to sharing digital signatures. [Background technology]

[0002] Generally, a shared secret can be used to share data items distributed among a group of participants. Each participant has a different share of the secret. Typically, a secret can only be reconstructed when a certain number of participants (called a "threshold") have made their respective shares available. For example, they can be combined to calculate the secret.

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

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

[0005] Similarly, a sender can sign a message using their private key. For example, this can prove that the message was sent by the sender and / or that the sender consented to the message. A signer (i.e., the party generating the signature) uses their private key to create a digital signature based on the message. Creating a digital signature based on a message means providing the message and the private key to a function that generates a signature based on both the message and the private key. The signature is added to the message (e.g., tagged to the message) or associated with the message. Anyone with the signer's corresponding public key can use the same message and its digital signature to verify whether the signature was validly created, i.e., whether the signature was actually created using the signer's private key. Digital signatures not only guarantee the authenticity of a message but also guarantee its integrity and non-repudiation. That is, a digital signature can be used to prove that a message has not been altered since it was signed and that the creator of the signature cannot deny in the future that they created the signature.

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

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

[0008] Instead of participants sharing their private key shares to generate signatures, they can use a threshold signature scheme. A threshold signature scheme allows a threshold of participants in a group to create digital signatures based on a message using their individual shares of a shared private key, without the private key being made available to all participants. Here, the digital signature is the signature generated based on the message to be signed. In such a scheme, a signature can only be created if the threshold of participants agree to generate a signature for the message. Attempting to generate a signature using fewer participants will not produce a valid signature. Therefore, a valid signature by a group (i.e., one generated using the message and the shared private key) must have been achieved if there was a threshold of people who agreed to generate the signature. This also means that an adversary would need to obtain a threshold of private key shares to forge a signature using the private key. [Overview of the Initiative]

[0009] As mentioned earlier, in threshold signature schemes, participants must each provide their respective signature share to generate a valid signature. A valid signature proves that at least a threshold of participants contributed to the signature share, but it does not prove which participants in the group contributed. In other words, in threshold signature schemes, there is no way to identify who created a given signature, and the resulting signature will always be the same regardless of which share was used to create the signature. Therefore, a threshold signature scheme is needed that allows signers (i.e., participants contributing to the signature) to prove that they contributed to the signature share. Such a scheme can be used to prevent other participants from falsely claiming that they contributed to the signature or that a certifier did not contribute to the signature.

[0010] According to one aspect disclosed herein, a computer-based method is performed by a first participant of a group of participants to prove that a target subgroup of the group has generated a digital signature, wherein the signature can be generated only on the basis of each signature share of at least a threshold, each participant of the group has each private key share of a shared private key, the group is divisible into a plurality of unique subgroups, each subgroup includes at least the threshold of participants, and the method is: A step of generating each first temporary private key share of each shared temporary private key for each subgroup to which the first participant belongs, wherein each other participant in each subgroup generates each temporary private key share of each shared temporary private key, For each shared temporary private key, the step is to generate a shared temporary public key, A step of generating a first signature share of the signature, wherein the first signature share is generated based on the first private key share of the shared private key, the first temporary private key share of the target shared temporary private key for each shared temporary private key, and the message. Steps include: making the first signature share available to the coordinator to generate the signature based on each signature share of the threshold, wherein each signature share is based on each private key share of the shared private key and each temporary private key share of the target shared temporary private key of each shared temporary private key, and the signature includes a component based on each shared temporary public key corresponding to the target shared temporary private key of each shared temporary private key; A method including this is provided.

[0011] Each participant in a group has a share of the same shared secret key to generate a threshold signature. A signature can only be generated with the fewest possible unique signature shares. This number is known as the signature threshold. A group divides itself into all possible unique subsets (i.e., subgroups). Each subset is at least the size of the signature threshold so that each subset can generate enough signature shares to generate a valid signature. A subset may contain more participants than necessary. Each subset derives a different share of a shared temporary key. Thus, a participant who is a member of multiple subsets derives multiple shares of temporary keys, one for each subset. A subset also derives a corresponding temporary public key. If a subset wishes to generate a signature, the participants in that subset use their share of the temporary key derived by that subset to generate their respective signature shares. Since a signature includes a component based on a corresponding temporary public key, participants in a subset from which the signature is derived can prove that they actually derived the signature because they are the only ones who have access to the temporary key (i.e., its share) corresponding to the temporary public key on which the signature's components are based. [Brief explanation of the drawing]

[0012] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the following appended drawings are referenced only as examples. [Figure 1] This is a schematic block diagram of a system for implementing an embodiment of the present invention. [Figure 2] A flowchart illustrating an exemplary embodiment of the present invention. [Figure 3] This flowchart illustrates an exemplary signature generation method according to several embodiments of the present invention. [Modes for carrying out the invention]

[0013] 1. Introduction to Cryptography The following examples illustrate elliptic curve cryptography, but the present invention is not limited to any one specific cryptographic scheme and can generally be applied to any cryptographic scheme, such as RSA or other public-key cryptographic schemes.

[0014] 1.1 Elliptic Curve Group The elliptic curve E satisfies the following equation:

number

number

[0015] This group operation can be used to define another operation on elements called point multiplication, represented by "·".

number

[0016] In elliptic curve cryptography, the secret key is defined as a scalar given by the following equation:

number

[0017] 1.2 Elliptic Curve Digital Signature Algorithm To create a signature for message msg using private key a, follow these steps:

[0018] 1) Calculate the message digest e = hash(msg). Any hash function can be used here. For example, in some examples, hash(msg) = SHA256(SHA256(msg)), where SHA256(■) is the SHA-256 hash function. Alternatively, note that the message may be hashed only once, or more than once with the same or different hash functions. 2) Select a random integer k ∈ {1, ..., n-1}, where n is the degree of the elliptic curve, for example, the secp256k1 curve. Hereafter, we will refer to k as the temporary secret key. 3) The temporary public key corresponding to this temporary private key is k·G=(R x ,R y ) calculate. 4) r = R x Calculate modulo n. If r=0, return to step 2). 5) The multiplicative inverse element k of a temporary key -1 Calculate modulo n. 6) s = k -1 Calculate (e+ar) mod n. If s=0, return to step 2). 7) The signature for message msg is (r,s).

[0019] The temporary key must be kept secret. Otherwise, given the message and signature, the private key could be calculated. Furthermore, a different temporary key must be used each time a signature is generated. Otherwise, given two different signatures and corresponding messages, private key 'a' could be derived.

[0020] Given a message msg, a public key P=a·G, and a corresponding signature (r,s), the signature can be verified by performing the following steps. 1) Calculate the message digest e = hash(msg). For example, e = SHA256(SHA256(msg)). 2) Calculate the multiplicative inverse \(s\) of \(s\) modulo \(n\). -1 Do it. 3) Calculate \(j1 = es\ -1 \(\bmod n\) and \(j2 = rs\ -1 \(\bmod n\). 4) Calculate the point \(Q = j1G + j2\cdot P\). 5) If \(Q = O\) (the point at infinity), the signature is invalid. 6) If \(Q\neq O\), set \(Q:=(Qx,Qy)\) and calculate \(u = Q\ x \(\bmod n\). If \(u = r\), the signature is valid.

[0021] In the threshold signature scheme, this private key \(a\) is split into key shares that are distributed among the participants of the threshold scheme group.

[0022] 1.3 Verifiable Secret Random Sharing Suppose \(N\) participants want to create a common secret that can be regenerated only by at least \((t + 1)\) of the participants of the scheme. To create the shared secret, perform the following steps. 1) The participants agree on a unique label \(i\) for each participant. Each participant \(i\) generates \((t + 1)\) of the following random numbers:

Number

Number

Number

[0023] Shared secret share is (i,a i This is a point in the format ). Here, i is the participant label in the format. As explained in steps 1) to 3), this method for creating a secret share of a is, here, for participant i, a i = JVRSS(i). Note that "JVRSS" usually stands for "Joint verification random secret sharing" and also includes steps 4) and 5). However, throughout this specification, JVRSS means performing at least steps 1) to 3), with steps 4) and 5) being optional.

[0024] Since each participant has generated a shared polynomial, they can each verify that the other participants are sharing the correct information with all participants, and that all participants have the same shared polynomial. This is done as follows: 4) Each participant i broadcasts the following obfuscated coefficient to all participants:

number

number

[0025] If all participants discover that this equation applies to each polynomial, the group can collectively confirm that they have all created the same common polynomial.

[0026] 1.4 Reconstructing the Shared Secret Suppose the participants want to reconstruct a shared secret a, which is a zero-degree shared polynomial. Given (t+1) points on this polynomial of the following form:

number

number

[0027] 1.5 Public Key Calculation The public key a of N zero-th order secret polynomial coefficients shared in step 4) of JVRSS i0 Given G and j=1,...,N, each participant calculates the shared public key P corresponding to the shared secret a using the following formula:

number

[0028] 1.6 Addition of Shared Secrets To calculate the sum of two shared secrets shared within a group of N participants, the entities perform the following steps without knowing the individual secrets: where each secret polynomial has degree t. 1) Generate the first shared secret a. Here, participant i's share is a i =JVRSS(i), where i=1,...,N, and the threshold is (t+1). 2) Generate a second shared secret b. Here, participant i's share is b. i = Given by JVRSS(i), the threshold is (t+1). 3) Each participant i has their own added share ν i =a i +b i Calculate modulo n. 4) All participants will add their share ν i Broadcast this to all other participants. 5) Each participant will share ν iInterpolate at least (t+1) of them, and then ν = interpolate(ν1,...,ν t+1 Calculate ) = a + b.

[0029] The method for adding this shared secret is shown by participant i's ADDSS(i). This means that each participant i will know ν=(a+b).

[0030] 1.7 Product of shared secrets To compute the product of two shared secrets within a group of N participants, the group performs the following steps, where each secret polynomial has degree t. 1) Generate the first shared secret a. Here, participant i's share is a i =JVRSS(i), i=1,...,N, is given by the degree of the shared secret polynomial, which means that (t+1) participants need to recreate the shared secret polynomial. 2) Generate a second shared secret b. Here, participant i's share is b. i = Given by JVRSS(i), the degree of the shared secret polynomial is again t. 3) Each participant is μ i =a i b i Using its own multiplication share μ i Calculate. 4) All participants multiply their share μ i Broadcast this to all other participants. 5) Each participant has at least (t+1) share μ i Interpolate across the range μ = interpolate(μ1,...,μ 2t+1 Calculate ) = ab.

[0031] This method for calculating the product of two shared secrets is shown here by μ = ab = PROSS(i) for participant i.

[0032] 1.8 Reciprocal of a shared secret To create the inverse of a shared secret a, follow these steps: 1) All participants calculate the product of the shared secret PROSS(i), and the result is μ = ab mod n. 2) Each participant calculates the modular inequality of μ, and the result is μ -1 =(ab) -1 It becomes modulo n. 3) Each participant i is a i -1 =μ -1 b i By calculating this, you can calculate the reciprocal of your own secret share.

[0033] This method for calculating the reciprocal of two shared secrets is as follows: for participant i, a i -1 This is shown by =INVSS(i).

[0034] 1.9 Generating and verifying a shared secret key To compute the shared secret key a among N≧2t+1 participants, each participant performs JVRSS using the threshold t+1 and the public key computation described above. As a result, all participants i=1,...,N will obtain a shared secret key ai and a corresponding shared public key P=(a·G).

[0035] 1.10 Generating a temporary key share To generate the temporary key share and corresponding r required for signing, a group of size N with a shared secret key a with threshold t+1 performs the following steps: 1) Shared secret inverse share k i -1 =Generate INVSS(i). Here, (t+1) shares are needed to recreate the inverse shares. 2) Each participant calculates the following:

number

[0036] 1.11 Generating a Non-Optimal Signature Suppose at least 2t+1 participants want to create a signature for a message, and one of the participants chooses to coordinate this. To have the group create a signature using the shared secret key a, follow these steps: 1) The coordinator will request signatures for the message from at least 2+1 participants. 2) Each participant i is given the temporary key (r,k) calculated in the previous section. i -1 Restore the temporary key. All users must use the same temporary key corresponding to the share. 3) Each participant calculates the message digest e = SHA-256(SHA-256(message)). 4) Each participant i shall share their own signature i Calculate: s i =k i -1 (e+a i r) mod n Here, a i This is their private key share. 5) Each participant shares their signature (r,s i Send this to the coordinator. 6) When the coordinator receives 2t+1 signature shares, it calculates the following: s = interpolate(s1, ..., s 2t+1 ) Then, the signature is output as (r,s). 7) The coordinator verifies the signature using standard ECDSA verification. If this fails, there is at least one share fraud, and the signature generation algorithm must be run again.

[0037] 1.12 Addition of Secrets with Different Thresholds In the case of adding secrets of degrees t and t', to add two secrets, it is necessary to calculate max(t, t') + 1 shares. This is because the addition procedure of the shares of the shared secrets creates shares of a new polynomial. This new added polynomial corresponds to the result of adding the individual polynomials of the two shared secrets. The addition of two polynomials is to add the corresponding coefficients at each degree of x. Therefore, the degree of the added polynomial needs to be the same as the highest degree of the two polynomials. This can be generalized to the addition of three or more polynomials where the degree of the resulting polynomial is the same as the degree of the individual polynomial with the highest degree.

[0038] When the addition of two secrets is calculated with different thresholds, the security of the secret with the higher threshold decreases. This is because the result (a + b) is known for each threshold t, t'. Assuming t < t', a can be calculated with t shares, and (a + b) - a = b can be calculated. Since the value b is calculated with only t shares, this lower threshold is hereinafter referred to as the "implicit threshold" of b.

[0039] 1.13 Multiplication of Secrets with Different Thresholds In the case of multiplying two secrets with thresholds t and t', t + t' + 1 shares are required for the calculation of the multiplication. In this case, the multiplication of the shares of the two polynomials results in shares of a new polynomial. Since this new polynomial is the result of multiplying the two individual polynomials, the degree of the result is the addition of the degrees of the two individual polynomials.

[0040] Multiplication can also be generalized to any number of shared secrets. The resulting threshold is the sum of the individual thresholds plus 1, that is:

Equation

[0041] Similar to addition, the multiplication of two secrets with different thresholds results in the implicit threshold of the secret with the higher threshold. As before, if ab is known, a has a threshold t, b has a threshold t', and t < t', then both a and b can be computed using t shares. First, compute a, and find b using only t shares of the secret with (ab)a -1 Here, we can find b using only t shares of the secret with (ab)a

[0042] 1.14 Combining Addition and Multiplication of Shared Secrets in One Step Generalizing the above, any combination of addition and multiplication can be computed in one step. Suppose a group of N participants wants to compute the result of ab + c. Here, a, b, and c are shared secrets with thresholds (t a +1), (t b +1), and (t c +1) respectively. There is a condition that max(t a [[ID={16]]+t b ,t c ) < N. That is, the number of participants in the scheme must be greater than the maximum of the degree of the secret c and the degree of the multiplication result of the secrets a and b 1) Each participant computes the secret shares a a =JVRSS(i), b b =JVRSS(i), c c =JVRSS(i) with thresholds (t i +1), (t i +1), and (t i +1) respectively 2) Each participant i computes the share λ i =a i b i +c i 3) Each participant i shares the result λ i with other participants 4) Each participating element interpolates max(t a +t b ,t c ) + 1 shares to obtain the result λ = int(λ1,...,λ i ,...) = ab + c ​

[0043] This is performed in the calculation of the shared signature according to several of the following embodiments. That is, s i = k i -1 (e + a i r) is an interpolation for. This is basically the above a i b i = k i -1 a i r and c i = k i -1 e case. In this case, t a + t b = 2t and t c = t, and the interpolation exceeds max(t a + t b , t c ) + 1 = 2t + 1 shares.

[0044] 2. Generation of Signature Shares FIG. 1 shows an exemplary system 100 for implementing an embodiment of the present invention. As shown, system 100 includes a plurality of parties (also referred to herein as “participants”) 102. Only three participants 102a, 102b, 102c are shown in FIG. 1, but in general, it is understood that the system can include any number of participants. System 100 also includes an adjustment party 104 (or simply “coordinator”), which may or may not be one of the participants 102. Each of the participants 102 and the adjuster 104 operates their respective computing devices.

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

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

[0047] Embodiments of the present invention will be described primarily in terms of the first participant 102a. However, it will be understood that the general steps of the described method may be similarly performed by other participants, for example, the second participant 102b or the third participant 102c. It will also be understood that terms such as “first,” “second,” and “third” are used herein merely as identifying labels and do not necessarily imply order unless the specific context in which these terms are used requires otherwise.

[0048] The present invention enables each participant 102 in a group of participants 102 to generate their respective share of threshold signatures, and allows a coordinator 104 to generate signatures based on those signature shares. More specifically, it is possible for subgroups of a participant group to generate signatures and to prove that a particular subgroup generated threshold signatures.

[0049] Each participant 102 can access their respective share of the shared secret key (for example, by storing it in the memory of their respective computer device). These secret key shares can be generated using a secret sharing scheme such as JVRSS (mentioned above) or Shamir's Secret Sharing Scheme (SSSS). Other schemes can be used to generate shares of the shared secret key.

[0050] A signature has a threshold, meaning that at least a threshold of different signature shares is required to generate a valid signature. It should be understood that a reference to “threshold” is interpreted as meaning the number of signatures corresponding to that threshold. For example, the threshold could be 2, 3, or 10. A shared secret key also has a threshold. In some embodiments, the signature threshold is the same as the secret key threshold. In other embodiments, the signature threshold is not the same as the secret key threshold.

[0051] The group of participant 102 is divided into multiple subgroups. Each subgroup is unique. Each subgroup contains at least a threshold number of participants; that is, the minimum number of participants in each subgroup is the same as the signature threshold. In this way, each subgroup can generate a valid signature. Figure 1 shows an example of dividing a group of 3 participants 102 into subgroups. In this example, the threshold signature requires at least two signatures to be generated validly. As shown in the figure, one subgroup (indicated by a dotted circle) contains the first participant 102a and the second participant 102b. Another subgroup contains the second participant 102b and the third participant 102c. Although not shown in Figure 1, another subgroup may contain the first participant 102a and the third participant 102c. In general, a group can be divided into any number of unique subgroups, as long as each subgroup contains at least a threshold number of participants. In some examples, a group can be divided into all possible unique subgroups.

[0052] Each participant in a subgroup generates a share of a shared temporary secret key specific to that subgroup. The temporary secret key share can be generated using JVRSS, SSSS, or another method. Each participant 102 can also generate the inverse of their respective temporary secret key share, for example, using the INVSS function described above. Each participant in the group also generates a temporary public key, i.e., a public key corresponding to the shared temporary secret key. As is known in the art, the public key includes a first (x) coordinate and a second (y) coordinate, the first coordinate being used to generate a signature share, as described below. Each participant 102 can also access each message-independent component (MIC) of the signature share, i.e., a signature share can be generated based on each MIC. The MIC itself can be generated by a given participant 102 based on their respective secret key share and each temporary secret key share, as well as the first coordinate of the temporary public key. The data required by each participant 102 to generate each signature share depends on the specific form of the signature to be generated, e.g., an ECDSA signature.

[0053] A participant may be a member of multiple subgroups (i.e., belong to one). For example, in the example in Figure 1, the second participant 102b belongs to at least two subgroups. Each subgroup generates a shared temporary private key (i.e., each participant in each subgroup generates a share of the shared temporary private key), so each participant who is a member of multiple subgroups generates multiple temporary private key shares, one for each subgroup. Similarly, each participant who is a member of multiple subgroups generates multiple temporary public keys, one for each subgroup.

[0054] After generating temporary private key shares and temporary public keys (one for each subgroup), a participant 102 of a particular subgroup (hereinafter referred to as the “Target Subgroup”) can generate a signature for the message in such a manner that it can be proven that the signature was generated by the subgroup. Each participant of a subgroup (or, if the subgroup contains more than a threshold, at least a threshold number of participants in the subgroup) takes the message to be signed and generates their respective signature share based on the message (e.g., its hash), their respective private key share, and their respective temporary private key share of the shared temporary private key generated by the Target Subgroup. For example, a first participant 102a can generate a first signature share based on (i.e., as a function thereof) the message, a first private key share, and a first temporary private key share, where the first temporary private key share is a share of the shared temporary private key generated by the Target Subgroup. The message may be obtained from the coordinator 104 (e.g., as part of a request for a signature share) or may be known to the first participant 102a in advance. Other participants in the target subgroup attempting to generate their respective signature shares perform an equivalent process to generate their respective signature shares.

[0055] In some examples, the signature share is generated based on the inverse of the temporary key share. The signature share may also be generated based on the first coordinate of the temporary public key (or more specifically, the first coordinate mod n, where n is the degree of the elliptic curve). The signature share may also be generated based on each MIC share.

[0056] Each participant 102 in the target subgroup may send a first signature share to the coordinator 104 to generate a signature based on at least a threshold of signature shares. Alternatively, one of the participants (e.g., first participant 102a) may be the coordinator 104, in which case first participant 102a may obtain each signature share from each participant and then generate a signature based on each signature share.

[0057] Coordinator 104 obtains at least a threshold of signature shares from the subgroup. Coordinator 104 may obtain more than the threshold, for example, one from each participant 102.

[0058] The signature generated by the coordinator 104 consists of two components (i.e., parts). One component (s) is generated based on the signature share provided by the subgroup participant 102. The other component (r) is based on the temporary public key generated by the target subgroup. For example, this component may be based on the x-coordinate of the temporary public key, e.g., x-coordinate mod n. The complete signature may be in the form (r,s).

[0059] The signature is generated using a signature share based on a temporary private key share known only to the target subgroup, so only the target subgroup can generate the signature. This can be verified by a verification party by examining the signature components based on the temporary public key. Coordinator 104 can send the signed message to the verification party. Only the target subgroup associated with the temporary public key can generate the signature. The verification party may know the mapping between the subgroup and the temporary public key in advance, or the mapping may be provided by the target subgroup (e.g., by participant 102a) or by coordinator 104. The mapping can be stored, for example, on a blockchain.

[0060] As will be further explained below, a signed message may include at least a portion of a blockchain transaction, for example, one or more inputs and one or more outputs of the transaction. Coordinator 104 can send the signed transaction to the blockchain, as shown in Figure 1.

[0061] Figure 2 shows an example of Method 200 according to several embodiments of the present invention. Steps S201 to S204 are performed by a participant in a target subgroup, for example, a first participant 102a. In step S201, the first participant 102a generates a temporary private key share for each subgroup to which the first participant 102a belongs, and in step S202, the first participant 102a generates a corresponding temporary public key. In step S203, the first participant 102a generates a signature share using the shared temporary key shares derived by the target subgroups, and in step S204, the first participant 102a sends the signature share to the coordinator 104 to generate a signature.

[0062] The following provides further specific examples of the embodiments described.

[0063] A subset of participants can prove their contribution to the signature by using a process in which all possible subsets of signers generate a temporary key, and then the participating signers use the temporary key of the corresponding subset to generate the signature.

[0064] Suppose we have a group of N participants who share a secret with threshold (t+1), and the set of all possible subsets of that group of at least size (2t+1) is given by the following equation:

number

number

number

number

[0065] Figure 3 shows an exemplary method 300 for generating a signature for a message according to an embodiment of the present invention. Steps S301 to S308 are each executed by each of the threshold participants 102 (including the first participant 102a) in this example. Step S309 is executed by the coordinator 101, and the coordinator may be one of the participants who execute steps S301 to S308. It is understood that some of the steps may be omitted or executed in a different order.

[0066] The exemplary method 300 enables the creation of a threshold (t + 1) shared secret among a group of N ≧ 2t + 1 participants, and the signature threshold is also (t + 1).

[0067] Setting: In step S301, each participant 102 calculates a shared secret key share a i and the corresponding public key. The secret key share can be generated using JVRSS as described above. At this point, each participant i has a secret key share and a public key (a i , P), where P is the notation of the public key corresponding to the shared secret key. The threshold of the shared secret key has a threshold (t + 1).

[0068] Pre - calculation: In step S302, each participant 102 calculates a shared temporary key share and the corresponding public key. For example, each participant 102 can calculate the shared temporary key using the calculation of JVRSS and the given public key. Next, each participant 102 can calculate an inverse share based on the temporary secret key. As a result, each participant has an inverse share (k i -1 , r) with a threshold (t + 1).

[0069] In step S303, each participant 102 creates two different shared blind key shares. For example, each participant 102 creates a shared α shared by participant i. i =JVRSS(i) and shared β i Having =JVRSS(i), two shared secrets can be created such that each shared secret has a threshold (t+1). Note that in some examples, not all shared secrets need to have the same threshold.

[0070] In step S304, each participant 102 calculates their median share and broadcasts that median share to the other participants. For example, each participant i calculates their median share λ i =k i -1 a i r+β i This value can be calculated. This value has a threshold of (2t+1).

[0071] In step S305, the first participant 102a calculates the median value based on at least the intermediate shares. For example, the first participant 102a can calculate the median value using interpolation over (2t+1) shares: λ=interpolate(λ1,…,λ 2t+1 )=k -1 ar+β.

[0072] In step S306, the first participant 102a is (r,k i -1 ,λ,β i ) possesses knowledge of and stores this together with the private key share and the corresponding public key (a i ,P).

[0073] Since a different temporary key is used for each signature, multiple temporary keys can be set at once. That is, by repeating steps S302 to S306, multiple temporary keys can be created during the pre-computation and stored for later use. These can be executed concurrently so as not to require additional communication rounds. It should be noted that, preferably, different values ​​for α and β should be used for each signature.

[0074] Signature generation: To sign the message msg, at least (t+1) participants must perform steps S307 and S308. In step S307, at least a threshold number of participants 102 obtain the message to be signed and compute the message digest. For example, the coordinator 101 can send a request to (t+1) participants to create a signature share of the message msg. Each participant i can compute the message digest e = hash(msg). In some examples, this hash function is a double SHA-256 hash function. A different hash function can be used.

[0075] In step S308, at least a threshold number of participants 102 calculate their signature share and send it to the coordinator 101. For example, each participant i calculates their own signature share s i =k i -1 e-β i Calculate this signature share (r,s i Send the value r to the coordinator. Note that the value r may not be sent by all participants.

[0076] In step S309, the coordinator 101 calculates the signature. For example, the coordinator 101 calculates s = interpolate(s1, ..., s t+1 ) + λ = k -1 e+k -1 We compute ar, and finally the signature (r,s). This cancels out the β term, so we obtain the expected signature share. (kα)-1 If and r are included in the calculation, a similar variation of this protocol can be performed as described above.

[0077] It should be noted that the secret thresholds can be different. That is, the thresholds for a, k, α, and β do not necessarily have to be the same in order to execute the signature generation scheme. For example, if there are six groups and three are needed to generate signatures and / or private keys, technically the calculation can be performed with a threshold of 4 for k and a threshold of 3 for the other shared secrets, and they will have a threshold-optimized scheme.

[0078] Please note that the present invention can be applied to any threshold signature scheme (optimal or non-optimal) and is not limited to the example shown in Figure 3 above.

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

[0080] The "lock scripts" and "unlock scripts" expressed in scripts can take the following forms: Locking script=OP_DUP OP_HASH160<Public KeyHash> OP_EQUAL OP_CHECKSIG Unlocking script= <signature><Public Key>

[0081] Referring to the above embodiment,<Public Key> P=a child It can be equal to G, <signature>This includes the threshold signature s, and the previous transaction is the message to be signed. Note that, as mentioned above, the ECDSA signature is in the form (r,s).

[0082] It should be noted that the described signature generation method is not limited to specific use cases and can generally be used to generate signatures based on any message. Signing all or part of a blockchain transaction is merely an illustrative example. The described method can be used, for example, to sign and / or approve legal documents (e.g., wills, deeds, or other contracts), communications between one or more parties, digital certificates (e.g., issued by a certification authority), medical prescriptions, bank transfers or financial products, mortgages or loan applications, etc.

[0083] As a specific example, a group of participants (for example, a total of 5 participants) may form a company's board of directors. The company's voting matters may require a majority of the board (i.e., at least 3 participants) to agree on a particular vote. The board can use the described signature generation method to prove that at least 3 board members have agreed to vote in favor of a particular outcome. In this example, the threshold for the signature generation method is 3. This means that at least 3 board members must provide their respective signature shares for the coordinator to successfully generate the signatures. If the signatures are successfully generated, at least the threshold (i.e., 3) of board members must have agreed to vote in favor of the outcome. Thus, the successful generation of signatures serves as a record of the vote, proving that a majority of the board voted in a particular manner.

[0084] Another use case of the present invention is in the field of digital certificates, for example, digital certificates issued by the X.509 standard. A digital certificate contains a signature that signs some data. Generally, the data can be any data, but a particular example of data included in a digital certificate is a public key. The public key of a digital certificate is often called a “certified public key”. The issuer of a digital certificate (e.g., a “certificate authority”) performs one or more checks on the owner of the public key (e.g., a know-your-customer check), and if the checks are successful, the certificate authority issues a digital certificate containing the certified public key. A user can use the certified public key to prove who they are, for example, by signing a message with the private key corresponding to the certified public key. One specific use of a certificate authority is signing certificates used for HTTPS for secure browsing on the internet. Another common use is the issuance of government identification cards used to electronically sign documents. The certificate authority signs the public key (or other data to be certified) using its private key.

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

[0086] <Conclusion> Other variations or uses of the disclosed technology may become apparent to those skilled in the art upon disclosure herein. The scope of this disclosure is not limited by the embodiments described herein, but is limited only by the appended claims.

[0087] It will be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs can be provided according to any one or more of the following descriptions.

[0088] (Statement 1) A computer-based method performed by a first participant of a group of participants to prove that a target subgroup of the group has generated a digital signature, wherein the signature can only be generated based on each participant's signature share of at least a threshold, each participant of the group has their own private key share of a shared private key, the group is divisible into a plurality of unique subgroups, each subgroup includes at least the threshold of participants, and the method is: A step of generating each first temporary private key share of each shared temporary private key for each subgroup to which the first participant belongs, wherein each other participant in each subgroup generates each temporary private key share of each shared temporary private key, For each shared temporary private key, the step is to generate a shared temporary public key, A step of generating a first signature share of the signature, wherein the first signature share is generated based on the first private key share of the shared private key, the first temporary private key share of the target shared temporary private key for each shared temporary private key, and the message. Steps include: making the first signature share available to the coordinator to generate the signature based on each signature share of the threshold, wherein each signature share is based on each private key share of the shared private key and each temporary private key share of the target shared temporary private key of each shared temporary private key, and the signature includes a component based on each shared temporary public key corresponding to the target shared temporary private key of each shared temporary private key; A method that includes this.

[0089] (Statement 2) The first participant is the coordinator, and the method is, The steps include obtaining at least one signature share of the threshold, The steps include generating the signature based on at least the signature shares of the threshold, The method described in Statement 1, including the method described in Statement 1.

[0090] (Statement 3) A step of making available to the verifier a list of each participant belonging to the subgroup associated with each shared public key corresponding to the target shared public key of each shared private key, The method described in Statement 1 or 2, including the method described in Statement 1 or 2.

[0091] (Statement 4) The method of statement 3, which includes the step of sending the message to the verifier.

[0092] (Statement 5) The aforementioned message is a method of any of statements 1 to 4, which includes at least a portion of a blockchain transaction.

[0093] (Statement 6) The method according to statements 2 and 5, which includes the step of sending the blockchain transaction to one or more nodes of the blockchain network.

[0094] (Statement 7) The aforementioned message is a method of any of statements 1 to 6, including a digital certificate.

[0095] (Statement 8) Each first temporary private key share is generated using a jointly verifiable secret sharing scheme, as described in any of statements 1 through 7.

[0096] (Statement 9) Each first-priority private key share is generated using Shamir's secret sharing scheme, in any of the manner described in statements 1 through 7.

[0097] (Statement 10) The group is divided into all possible unique subgroups, as described in any of statements 1 to 9.

[0098] (Statement 11) Computer equipment, Memory containing one or more memory units, A processing device including one or more processing units, Includes, A computer device in which the memory stores code configured to be executed on the processing device, and the code is configured to perform the method described in any of statements 1 to 10 when executed on the processing device.

[0099] (Statement 12) A computer program that is implemented on a computer-readable storage device and, when executed on a computer device, is configured to perform any of the methods described in statements 1 through 10.

[0100] According to another aspect disclosed in this specification, a method including the actions of the coordination party and the first participant may be provided.

[0101] According to another aspect disclosed in this specification, a system including computer equipment for the coordinating party and the first participant may be provided.< / signature> < / signature>

Claims

1. A computer-based method performed by a first participant of a group of participants to prove that a target subgroup of the group has generated a digital signature, wherein the signature can only be generated based on each signature share of at least a threshold, each participant of the group has each private key share of a shared private key, the group is divisible into a plurality of unique subgroups, each subgroup includes at least the threshold of participants, and the method is: A step of generating each first temporary private key share of each shared temporary private key for each subgroup to which the first participant belongs, wherein each other participant in each subgroup generates each temporary private key share of each shared temporary private key, For each shared temporary private key, the step is to generate a shared temporary public key, A step of generating a first signature share of the signature, wherein the first signature share is generated based on the first private key share of the shared private key, the first temporary private key share of the target shared temporary private key for each shared temporary private key, and the message. Steps include: making the first signature share available to the coordinator to generate the signature based on at least the threshold of each signature share, wherein each signature share is based on each private key share of the shared private key and each temporary private key share of the target shared temporary private key of each shared temporary private key, and the signature includes a component based on each shared temporary public key corresponding to the target shared temporary private key of each shared temporary private key; A method that includes this.

2. The first participant is the coordinator, and the method is, The steps include obtaining at least one signature share of the threshold, The steps include generating the signature based on at least the signature shares of the threshold, The method according to claim 1, including the method described in claim 1.

3. A step of making available to the verifier a list of each participant belonging to the subgroup associated with each shared public key corresponding to the target shared public key of each shared private key, The method according to claim 1, including the method described in claim 1.

4. The method according to claim 3, further comprising the step of sending the message to the verifier.

5. The method according to claim 2, wherein the message includes at least a portion of a blockchain transaction.

6. The method according to claim 5, further comprising the step of transmitting the blockchain transaction to one or more nodes of the blockchain network.

7. The method according to claim 1, wherein the message includes a digital certificate.

8. The method according to claim 1, wherein each first temporary private key share is generated using a jointly verifiable secret sharing scheme.

9. The method according to claim 1, wherein each first temporary private key share is generated using Shamir's secret sharing scheme.

10. The method according to claim 1, wherein the group is divided into all possible unique subgroups.

11. Computer equipment, Memory containing one or more memory units, A processing device including one or more processing units, Includes, A computer device wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to any one of claims 1 to 10 when executed on the processing device.

12. A computer program that is implemented on a computer-readable storage device and is configured to perform the method described in any one of claims 1 to 10 when executed on a computer device.