COMPUTER-IMPLEMENTED METHOD AND SYSTEM FOR OBTAINING DIGITALLY SIGNATED DATA - Patent application

Abstract

To disclose a method for acquiring data to be digital signatured.SOLUTION: The method contains a step of transmitting first data (e2) to a second participant of at least one of them from a first participant of at least one of a plurality of first participants, in which the first data can be accessed by the first participant of at least one of them, and second data (e) cannot be accessed by each of the second participant on the basis of the second data. A digital signature (s1) of the first data is received from the second participant of at least one of them, and the digital signature of the first data is processed by the plurality of first participants in order to provide a sharing of the digital signature (s) of the second data, and the digital signature of the second data can be accessed by using the sharing of a threshold, and cannot be accessed by the sharing smaller than the threshold.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to data security and computer-based resources. More specifically, the present invention relates to cryptocurrencies and cryptography, including Elliptic Curve Cryptography, Elliptic Curve Digital Signature Algorithm (ECDSA), and threshold cryptography. The present invention may be used to benefit in connection with blockchain-implemented cryptocurrencies, but is not limited in this respect and may have broader applicability. The present invention may be described in one embodiment as providing a distribution protocol for blind dealer-free thresholds. [Background technology]

[0002] Herein, we use the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referred to herein for convenience and illustrative purposes, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. The term "user" here may refer to a human or processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system, composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system, and contains at least one input and at least one output. Each block contains a hash of the previous block, and these blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since origin. Transactions contain small programs, known as scripts, that embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. In the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] In order for a transaction to be written to the blockchain, it must be validated. Network nodes (miners) perform the work to ensure that invalid transactions are rejected from the network and that each transaction is valid. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing the UTXO's lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must be (i) validated by the first node that receives the transaction, and if the transaction is valid, the node relays the transaction to other nodes in the network, (ii) added to a new block constructed by miners, and (iii) mined, i.e., added to the public ledger of past transactions.

[0005] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to exploit the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used to automate tasks and processes that are not limited to the cryptocurrency field. Such solutions could make their uses more diverse while taking advantage of the benefits of blockchain (e.g. permanence, tamper resistance of the record of events, decentralized processing, etc.).

[0006] The concept of decentralization is fundamental to the Bitcoin method. A decentralized system offers the advantage that there is no single point of failure, unlike distributed or centralized systems. Thus, a decentralized system offers an enhanced level of security and reliability. This security is further enhanced by the use of known encryption techniques, such as Elliptic Curve Cryptography and ECDSA.

[0007] However, while the Bitcoin protocol itself has proven to be resilient against any significant attacks at the time of filing this application, attacks exist against exchanges and wallets that complement or are built on the Bitcoin network. As Bitcoin's value grows, more incidents like those involved with Mt Gox and Bitfinex are likely to occur in standard centralized systems.

[0008] There is therefore a need for solutions that further improve the security of such systems.The present invention provides, among other things, such advantages. Summary of the Invention

[0009] The present invention provides methods and systems as defined in the accompanying claims.

[0010] According to the invention there is provided a method for obtaining digitally signed data, the method comprising the steps of: transmitting first data from at least one first participant to at least one second participant of a plurality of first participants, the first data being based on second data accessible to at least one of the first participants, the second data being data inaccessible to each of the second participants; receiving a digital signature of the first data from at least one of the second participants; processing the digital signatures of the first data by a plurality of the first participants to provide shares of the digital signatures of the second data, the digital signatures of the second data being accessible with a threshold number of the shares and inaccessible with shares less than the threshold number; A method may be provided that includes:

[0011] A plurality of first participants process digital signatures of first data to provide shares of digital signatures of second data, where the digital signatures of the second data are accessible to the holder for a threshold number of shares and inaccessible for fewer than the threshold number of shares. This provides the advantage of improving security since the second participants do not have access to the second data but can sign the first data and provide digital signatures for the second data, while still using a threshold number configuration to further improve security. This provides the advantage that the first participants can designate the second participants as custodians of private keys for signing messages such as blockchain transactions, while preventing the second participants from making unauthorized use of the key since the second data is inaccessible by the second participants.

[0012] Each of the shares of the digital signature of the second data may include shares of a plurality of first secret values ​​shared among a plurality of the first participants using joint random secret sharing (JRSS).

[0013] This has the advantage of improving security by providing a dealer-free secret value sharing scheme in which the first secret value is selected jointly by the first participants, thereby avoiding the weaknesses of single dealer type systems.

[0014] Each of the shares of the digital signature of the second data may include at least one first masking share shared using joint zero secret sharing (JZSS) among a plurality of the first participants.

[0015] The first data may be generated using shares of the first data such that the first data is accessible using a threshold number of the shares and is inaccessible with shares less than the threshold number.

[0016] Each of the shares of the first data may include shares of a plurality of the first secret values ​​shared using joint random secret sharing (JRSS) among a plurality of the first participants.

[0017] Each of the shares of the first data may include at least one second masking share shared using joint zero secret sharing (JZSS) among a plurality of the first participants.

[0018] The method may further include receiving third data from at least one of the second participants, the third data being based on the second secret value.

[0019] This provides the advantage of facilitating the generation of a digital signature of second data from a digital signature of first data.

[0020] A digital signature of the first data may be generated using shares of the digital signature of the first data shared among a plurality of the second participants, the digital signature of the first data being accessible using a threshold number of the shares and inaccessible with shares fewer than the threshold number.

[0021] Each of the shares of the digital signature of the first data may include shares of a plurality of second secret values ​​shared among a plurality of the second participants using joint random secret sharing (JRSS).

[0022] Each of the shares of the digital signature of the first data may include at least one third masking share shared using joint zero secret sharing (JZSS) among a plurality of the second participants.

[0023] The second data may be a message.

[0024] The second data may be a hash value of the message.

[0025] The first data may be a blockchain transaction.

[0026] At least one digital signature may be based on a cryptosystem that has homomorphic properties.

[0027] At least one of the digital signatures may be based on an elliptic curve cryptosystem.

[0028] The present invention also provides a system including a processor and a memory including executable instructions that, upon execution by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0029] The present invention also provides a non-transitory computer readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to at least perform a computer-implemented method as described herein.

[0030] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, and with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0031] [Figure 1] 1 is a schematic representation of a blind signature distribution system embodying the present invention; [Diagram 2] FIG. 1 illustrates a schematic diagram of a computing environment in which various embodiments can be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] In this application, a threshold-based dealerless blind signature distribution system is described that is fully compatible with Bitcoin. The system builds on a group signature scheme that departs from the traditional individual signature system deployed within Bitcoin wallets and adds a new system designed to enable distributed threshold blind signing of messages. When deployed, the system is scalable and robust, and can withstand errors and malicious adversaries. The system can support deployment in both dealer and dealerless systems, and infinite flexibility of distribution.

[0033] Blind signature schemes allow for the signing of messages without knowing the contents of the messages. In Bitcoin, this includes the ability to act as custodians of Bitcoin private keys without knowing which addresses or keys they are trusted to use.

[0034] When combined with a threshold signature scheme where a document can be validly digitally signed by a threshold number of participants, but not fewer than a threshold number, this allows the holder of a Bitcoin private key to create a system of trust where messages can be signed by the party who controls the address without knowing the amount being held. Thus, the second participant, Alice, the owner of the amount of Bitcoin, can store her key with the first participant, Bob, in a way that does not allow Bob to know how much Bitcoin Alice controls. Alice can send more to (or receive from other parties) the blinded address without Bob discovering how many Bitcoins Alice holds and controls (or anything about Bitcoin addresses).

[0035] Combined with a threshold system, Alice can allow several parties to act in concert without having to

[0036] (1) Knowing the identity of other blind parties, (2) Secure her Bitcoin across multiple systems in a way that allows her to access her funds even if the party is no longer available.

[0037] Threshold blinding keys result in signed messages that include the use of blind signatures so that parties cannot collude to access Alice's funds, even if they too gain access to the identity of the other party and obtain a sufficient threshold number of shares to be able to blind sign a message, since this message is only valid when not blinded into a standard ECDSA Bitcoin signed transaction.

[0038] Threshold blinding techniques also add an additional addressable randomness to the security of the base system, helping to protect against faulty Random Number Generators (RNGs). The blind signing party can act as a key custodian or escrow. This can be a backup to the primary key in case of loss or to add a second layer of certification and control. The use of several systems or operators allows for a RAID-like key management system with added redundancy and added security when several independent parties are used as trust guardians.

[0039] In existing implementations of Bitcoin, payer wallets can be lost, damaged, or stolen. Thus, funds are lost or cannot be restored. Hardware cryptocurrency wallets can be compromised or lost. In the system described herein, the hardware system can be separated into multiple parts and the hardware devices can be securely moved and regenerated. The following symbols are used in this application: [Table 1] Standard ECDSA values ​​apply:

[0040] w=s -1 mod n u1=ew mod n u2=rw mod n x=u1G+u2D A All standard ECDSA rules apply: It is possible to construct a linear transformation, so that s=x.e+b This relationship is used in blinding the message to be signed: a second participant (Alice) can sign a blind message instead of the message to be signed, keeping the message and simply transmitting the blind message hash.

[0041] (1) Alice sends a blind hash of her message to the first participant, Bob.

[0042] (2) Bob signs the "blind hash" and returns the signed value to Alice.

[0043] (3) Alice "un-blinds" Bob's value and obtains a signature, which can be used to reconstruct a valid Bitcoin transaction.

[0044] Threshold blinding can be achieved scalably by:

[0045] (1) Alice's key is split, (2) Bob's value is divided, (3) Both Bob and Alice's keys are split, (4) Alice and Bob's entire keys are split, not just the blinding values.

[0046] Suppose Alice chooses a value α in the range [1,(n-1)]. Then we compute:

[0047] β = hash(α + 1) γ = hash(α + β) δ = hash(α + γ) If β is a threshold, Alice u It is considered to be a group of parties, A1~A Tv A i is a sliced ​​or thresholded version of Alice with a particular instance denoted as α, where α is chosen using Algorithm #1 detailed below.

[0048] Preliminary work Shamir Secret Sharing Scheme (SSSS) Shamir (1979) first introduced a dealer-based secret sharing scheme that allows for decentralized management of keys. Problems associated with this scheme arise from the need to trust the dealer, who cannot be verified. This form of scheme is fully compatible with the system disclosed in this application and can be used for group distribution of the individual key slices generated through the process presented here.

[0049] Joint Random Secret Sharing (JRSS, Pedersen, 1992) The stated goal of this procedure is to generate a way for a group of participants to collaboratively share a secret without any participant knowing the secret. Each participant chooses a random value as their local secret and distributes a value derived by the group using SSSS. Each participant then adds up all shares from participants, including its own. This sum is the joint random secret share. The randomness provided by a single honest participant is sufficient to maintain the authenticity of the combined secret value. This condition is true even if all (n-1) other participants intentionally chose non-random secret values.

[0050] Joint Zero Secret Sharing (JZSS, Ben-Or, 1988) JZSS is similar to JRSS, except that each participant shares a zero instead of a random value. The shares generated using this technique help eliminate any possible weak points in the JRSS algorithm.

[0051] Desmedt

[1987] introduced the concept of group-oriented cryptography. This process allows participants to send messages to a group of people in a way that only a selected subset of participants are allowed to decrypt the message. In this system, members are informed if the sender needs to know them with a public key, and a group is anonymous if there is a single public key for the group that is kept independent of the members. The system disclosed in this application integrates both methods, allowing known anonymous senders and signers to exist simultaneously within a group.

[0052] Blind Signatures (Chaum, 1982) Blinded signatures allow a party to generate a valid signature for another party in a secure manner, without the message being seen by the signer. In this system, only the signer can generate a valid signature, while the owners of the message to be signed are assured that their message has not been altered and was delivered correctly, allowing them to redeem their funds in systems such as those used in Bitcoin. Furthermore, the system is inconceivable in that no party other than the party requesting that the signature be applied can derive the relationship between the blinded and unblinded values ​​and the signature pair.

[0053] The introduction of blind signatures into the threshold system allows for the signing of messages in the Bitcoin protocol where the signer cannot link ownership to a Bitcoin address. In this way, the signer cannot determine the amount of funds held by the party they are protecting or the amount to be transferred. This additional level of privacy adds additional security since it is no longer possible to collude within the threshold group protecting the keys to steal funds. This becomes infeasible since it would require knowing which blind keys are associated with which deposits. In a peer group, such a system can be constructed where a threshold number of group members act to protect the keys of other members. In this scenario, a group of depositors may each divide the signing function among the other members. As a result, no member knows the shares of others in the group.

[0054] This scenario can also be used with other forms of message exchange, allowing a distributed peer group to protect the privacy of all members while simultaneously not disclosing any confidential information related to members of the group.

[0055] <Method and implementation> The protocol of the present invention can encrypt any secret information that needs to be transmitted between participants using elliptic curve cryptography (ECC) based on a hierarchical derivation of a private key. In this case, it is possible and sensible to collate all messages into a single packet that is to be sent to all users. As a result, verification can be performed when necessary against a potentially compromised or hostile participant.

[0056] Signature generation is proposed by a coordinating participant p(c). By default, any key slice can act as a coordinating participant, the requirements depend on the specific implementation of the protocol. The algorithms used are described below and later chapters provide details on their deployment.

[0057] <Generate dealer-less blind ECDSA threshold key> In the system according to the embodiment of the present invention, the first participant, Alice (i) This group is owned by the second participant's group, Bob (i) With the ability of the group or system to be the advantageous custodians of the private keys to be blind signed.

[0058] <Aliceグループ> First, we use the unblinded threshold group Alice. (i) selects a set of first secret values ​​in the form of random numbers.

number

[0059] Algorithm 1: Key Generation - For a more detailed version of Algorithm 1, see the Appendix below. Domain parameters (CURVE, Cardinality n, Generator G) Input: N / A Output: Blind key share: A a1 ,..A ai ,A b1 ,…A bi ,A c1 …A ci ,A d1 …A di . Using Algorithm 1, the members of Alice’s group are v Of T u We can follow the threshold exchange. Here, Alice's T v A threshold number T of members u is the second secret value A a are required to generate or use

[0060] Similarly, the JRSS process can be used with algorithm 1 to generate a further second secret value A b A bi Along with A c A ci Along with A d A di Generated together with.

[0061] Each of the values ​​can be used and generated using the same threshold group (u,v) or each value can be split and generated using individual thresholds and members.

[0062] In this system, various secret A ai ,A bi ,A ci and A di are only used once. If these values ​​need to be used again, Algorithm 2, detailed below, is used to re-share the secret using a variant of JZSS.

[0063] Algorithm 2: Secret Key Update - For a more detailed version of Algorithm 2, see the Appendix below. Input: Participant P i ,Private key A a ,A b ,A c ,A d The shares of A ai ,A bi ,A ci ,A di It is shown as: Output: Participant P i New private key share: A' ai ,A' bi ,A' ci ,A' di In the ideal case, there would be only one set of shares (T u ,T v )), there is only a single Alice group, and the operation is to use T v Request a broadcast.

[0064] A ai ,A bi ,A ci ,A di can each be sent in a single broadcast message.

[0065] <Bobグループ> First participant Bob group Bob (i) is defined as a signature group. This group consists of (T u ',T v '), or the T required to share and use the first secret value (Bp, Bq) v 'T of all people u ' members, and Bp and Bq are regenerated blind values ​​used by the Bob group to sign blind messages for the Alice group.

[0066] <Algorithm 4: Blind key of Bob group> (1) Bob(i), a member of the Bob group, selects a set of second secret values ​​in the form of random numbers.

number

[0067] (2) The Bob group calculates the following values: BP=(Bp -1 .G) BQ = (Bq.Bp -1 .G) Here, BP is calculated using a variant of Algorithm 3, which is described in more detail in the appendix to this application.

[0068] (3) Generate mask shares: Using JRSS ai ←Z q By JZSS bi ,b ci ←Z q 2

[0069] (4) Broadcast: α i =Bp i .b ai +b bi mod q β i = G × b ai

[0070] (5) χ = Interpolate(α i,…, α Tv ) [=Bp.b a mod q] Here, the operation Interpolate(α i,…, α Tv ) is the share α i represents the recovery of a secret value shared among the participants.

[0071] (6) δ = Exp-Interpolate(β i,…, β Tv ) =Gxb a Here, the operation Exp-Interpolate(β i ,…,β Tv ) is the share beta i represents the recovery of the elliptic curve point secret value shared among the participants.

[0072] (7)

number

[0073] (8)Bq i , that is, B q , and (Bp -1 .G) to Bob (i) Each member of broadcasts: i =Bq i x(Bp -1 .G)

[0074] (9)

number

[0075] (10) The two EC points, i.e., BP and BQ, are sent to the Alice group in the form of a third data. A secret exchange, implemented for example as disclosed in International Patent Application WO2017 / 145016, can be used to maintain authenticity.

[0076] <Threshold messages to be blinded> Next, the Alice(i) group uses the values ​​from the Bob(i) group to compute a value that can be safely issued when blinded using (5).

[0077] <Algorithm 5: Alice (single group)> Alice knows BP and BQ from a previous broadcast in the Bob(i) group.

[0078] Alice starts by calculating a secret value. K =(A c .A a ) -1 BP This is done as follows:

[0079] (1) Generate mask shares: M using JZSS ai Therefore, JZSS ai ←Z q 2

[0080] (2) Alice(i) broadcasts the following values:

number

[0081] (3) Alice(i) group calculates Aμ. A μ =Interpolate(A μ1 ,…,A μTv )mod q =A c .A a mod q Here, A μ -1 =(A c .A a ) -1

[0082] (4)

number

[0083] Bob group is A T Or A K A T and not be involved in any transfer of funds to or from the associated Bitcoin addresses, a ,A b ,A c , and A d If the Alice group maintains these as secure thresholds, Bob or any other party will never know Alice's details.

[0084] Alice uses public key A in the standard generation of Bitcoin addresses. T, further weakening Bob(i)’s ability to determine her address even if it was instrumental in helping Bob sign the transaction.

[0085] <Algorithm 6: Alice calculates the public key> (1) Generate mask shares: Using JRSS, ai ←Z q (2) Generate mask shares: JZSS generates mask shares for M bi ,M ci ←Z q 2 . (3) Calculate:

number

number

number

number

number

number

number

[0086] <Generate a Bitcoin address> This public key is converted in a standard way to generate a Bitcoin address. A T = A T (x,y) (1) A T (y)'s parity and the complete A T (x) coordinates are used to represent the public key. (2) Hash the public key twice. (a) Use SHA256. (b) Use RIPEMD160. (3) Append the version (which is the Bitcoin address version number) number at the beginning. If the protocol is standard, version 01 is used. If P2SH is used, it is also possible to make this version 03. (4) Append a checksum to the end of the version-appended public key hash from (3). The checksum is the first 4 bytes of the double SHA256 hash of the value returned from (3). (5) BASE58 encodes the value produced in (4). This is a standard format Bitcoin address that the Alice(i) group may receive payments to, and this address at this point appears like any normal bBitcoin address. Any party, including Bob, can determine whether Alice has value A a ,A b ,A c and A d Unless you leak the information, who can tell? T I don't know who owns the address.

[0087] Even if they are leaked, Alice(i) does not need to inform anyone that these values ​​are associated with Bob(i)'s signing group. If Alice has a bad RNG, she remains secure because Bob(i) can introduce randomness into the procedure.

[0088] <Blind signature in threshold group> To sign a message, which is a requirement for using Bitcoin, or to sign any other message (such as an email message on an anonymous host), Alice(i) needs to have the hash of the message or transaction e=h(m). Given the message (or transaction) and the signed hash, Alice(i) can reconstruct the message (transaction) and use the Bitcoin public key A T You can also redeem funds from the associated Bitcoin basic 58 address.

[0089] Algorithm 3: Key Generation - For a more detailed version of Algorithm 3, see the Appendix below. Domain parameters (CURVE, Cardinality n, Generator G) Input: Message to be signed → e = H(m) Private key share → d A(i) ∈Z n * Output: Signature → For e = H(m), (r,s) ∈ Z n * Alice maintains privacy by not letting Bob(i) know the contents of the message (transaction). Therefore, Bob(i) knows that he T Alice(i) blindly processes the hash value, unaware that she is signing a message related to

[0090] <Algorithm 7: Blind processing of hash values> Alice generates first data in the form of a blinded version of second data, which is a hashed message (transaction) e.

[0091] Here, e2=A a .e+A b (mod q).This is generated as follows: (1) Alice(i) starts by generating a mask share: Mai ← Zq using JZSS. (2) Alice(i) sends a value: Av(i) = Aa(i)e + Ab(i) + Ma(i) mod q Alice(i) sends the value Av(i) to other members of Alice who can insert this set of values. (3) e2 = Interpolate(Av1, …, Av v )=A a .e+A b mod q (4) e2 is broadcast to the Bob(i) group using an encrypted channel where Bob verifies Alice's identity. This can be achieved using, for example, the arrangement disclosed in International Patent Application WO2017 / 145016, where Alice pays Bob for a signature and exchange over a closed encrypted session channel.

[0092] If Bob receives a message from a non-Alice party and signs it, the value cannot be unblinded and therefore remains secure. Even if Bob has the payment and record, he has no information about Alice's signed transaction because the value e2 was blinded and Alice only sent Bob the blinded hash and not the message.

[0093] The Bob group signs the blinded hash and returns this, a digital signature of the first data, to Alice.

[0094] Bob(i) generates message s1 = Bp.e2 + Bq mod q.

[0095] s1 is returned to Alice and is a blinded version of the signature.

[0096] To do this, Bob(i) signs s1 from his threshold group using Algorithm 8 and returns it to Alice(i).

[0097] <Algorithm 8> s1=Bp.e2+Bq mod q (1) Bob(i) generates mask shares using JZSS. By JZSS, M b(i) ←Z q 2 (2) Bob(i) is Bs i =Bp (i) .e2+Bq (i) +Mb(i) Broadcast mod q. (3)

number

[0098] Alice then verifies the blinded s1 part of the signature and (A K(x) ) an r portion.

[0099] Alice(i) can use the threshold unblinding method to recover the s signature value, i.e., the digital signature of the second data, from the s value blinded using Algorithm 9.

[0100] <Algorithm 9> Alice(i) wants to obtain the unblinded s signature component from the s1 blinded part. She wants to obtain s = A c .s1+A d We do this by computing (mod q).

[0101] To do this, she does the following: (1) Generate hash shares using JZSS. By JZSS, M a(i) ←Z q 2 (2) Alice(i) broadcasts the following: s i =A c(i) s1+A d(i) +M a(i) To all other Alice members. (3)

number

[0102] It can be shown that S is a valid ECDSA signature of e as follows: Expand s: s=A c s1+A d =A c (Bpe2+Bq)+A d =A c Bp(A a e+A b )+A c Bq+A d =A c BpA a e+A c BpA b +A c Bq+A d =(A c BpA a )(e+A a -1 [A b +BqBp -1 +A d A c -1 Bp -1 ) However, from the above formula 1, public key A T The private key d corresponding to A teeth, A a -1 A K(x) -1 (A b +BqBp -1 +A d A c -1 Bp -1 ) From now on, it is as follows: s = (A c BpA a )[e+A K(x) d A ]=k -1 [e+A K(x) d A], where k=(A c BpA a ) -1 From this, we can see that s is a valid ECDSA signature of e and can be verified with the public key AT.

[0103] This signature on the message can form a standard Bitcoin transaction, where Alice(i) can redeem the funds when the transaction is broadcast to the Bitcoin network.

[0104] Bob(i) has no information about which address Alice has used.

[0105] He doesn't know the Bitcoin address, the amount of the transaction, or where it's being sent.

[0106] Even though Bob(i) holds and protects the key, he has no knowledge of the transaction.

[0107] <Security considerations> Benger et.al. (2014) proposed an example of ECDSA private key recovery using the Flash and Reload method. This is, however, an example of an attack against system RAM and Cache. These methods would like to use procedures such as Shamir's SSS

[1979] when reconstructing the private key. Furthermore, in any scenario where the private key is reconstructed, a requirement of trust is introduced. In this scenario, one must rely on the system and the processes of the entity that holds the private key. Even if the trusted party is not malicious, one must rely on their processes. As seen from many recent breaches, this reliance on reconstructing the private key opens the way for attacks.

[0108] It is a perfect replacement for existing ECDSA implementations, and at the same time is completely transparent and compatible with the current Bitcoin protocol, so no hard or soft forks are required for its implementation, and the implementation is indistinguishable from any current transactions. The present invention allows for group signing of keys with recovery capabilities, where individuals can be treated as separate participants. As an example, a 2-of-2 (two of two) scheme can be implemented with 4k key slices, where the online wallet provider or exchange maintains two key slices and the end user maintains two slices. The exchange and user each have a 2-of-2 transaction for their key slice, which are then used in combination with each other for secure signing of messages when needed.

[0109] In this scheme, group Bob(i) can at least see the hash of the message provided by Alice(i).

[0110] 1. No member of Bob(i) may, either together or independently, a Or A b Since no member of this group can know e, no member of the group can determine whether e2 is a blinded version of the message hash e.

[0111] 2. Similarly, Bob(i) receives the value A c Or A d Since we do not know the relationship between the signature values ​​s and s1, we cannot determine the relationship between the signature values ​​s and s1.

[0112] 3. In a similar way to that used in computing Rabin() signatures, Bob(i) is the a A c cannot be determined immediately. Under the assumption of the elliptic curve discrete logarithm problem, Bob(i) is A T The relationship between (x) and the elliptic curve point BP cannot be determined.

[0113] 4. In a similar manner, Bob(i) finds that the value BP or BQ is the public key A in Alice(i)’s group. TIt does not gain knowledge of whether it was used in constructing (x,y).

[0114] 5. Now, when the unblinded message is broadcast by Alice(i), the value of the public key associated with the transaction remains unknown. If Alice(i) delays broadcasting the blinded message signature she received from Bob(i), the inclusion of many other transactions in the Bitcoin block means that Bob(i) can only determine that Alice(i) has a signed message and may have processed it after it was received.

[0115] 6. There is no need for external parties to have information about the transaction between Alice(i) and Bob(i), thus increasing the level of privacy between these parties.

[0116] An effective outcome of this process is that a threshold group of Alice(i), which may or may not represent the entire group, can be sent to a Guardian group Bob(i) who can assist in signing a transaction or message, while the content of the message provided by Alice(i) remains hidden.

[0117] As long as Alice(i) remains in a position to some degree of deniability in sending messages, and the amount of messages in a system (such as Bitcoin) remains significantly above zero, Bob(i) cannot determine which messages may be coming from Alice(i).

[0118] In this method, when Alice(i) signs different hash values, a &A bIt is important that these values ​​are not reused. If they are reused with a different value e, this allows Bob(i) to compute information that links the obscured hash e2 to the original hash value e of the broadcast message. This means that adding further linear equations shows that Bob(i) a &A b This gives rise to a scenario in which a message e can be inserted into the blockchain, and so a relationship between the two is created. As a result, Bob(i) can look up the value e on the blockchain and find the corresponding public key A T (x,y) can potentially be linked to other derived public keys associated with this group.

[0119] Similarly, and importantly, the parameter A c &A d makes it possible to compute the relationship between the signature blinded to Bob(i) and the signature issued by Alice(i), and therefore the parameter A c &A d In a similar way to the reuse of T (x,y) can be determined, so Alice(i) has parameter A c &A d Do not reuse.

[0120] Similarly, parameter B p &B q And the BP&BQ generated by Bob(i) should not be reused. Without them, Alice(i) would not be able to forge the blinded signature generated by Bob(i), and therefore would not be able to use the public key A T It is not possible to unblind a signature that appears to have been produced by (x,y). Value B p &B q is computed by Bob(i) using the derived key scheme, e.g., using the construction as disclosed in International Patent Application WO2017 / 145016, so that B p &B qEach value of is unique for each message generated by Alice(i), and under the assumption of a collision-free hash algorithm, any party using the service can use the B generated for each message to never be reused. p &B q have their own version of

[0121] The present invention extends what cryptocurrencies seek to achieve by introducing a group signature process. Adding a fault-tolerant signature system to the combination of a distributed key generation system removes all centralization and trust requirements. Many systems evolve with the need for trust. Furthermore, the introduction of an implicitly decentralized system allows for the creation of more robust and resilient protocols. The compatibility between ECDSA [Johnson, 2001] and Shamir's SSS [Shamir, 1979] allows for the introduction of a system that extends Bitcoin with a new verifiable secret sharing scheme. This system is much more efficient than those derived by Feldman [Feldman, 1987] or Pedersen [Pedersen, 1992] without losing anything in security.

[0122] As a result of the introduction of threshold signature blinding, which extends the work of Chaum (1982), trusted parties do not even need to be present in a web-based exchange. A true form of pseudonymous digital cash or asset transfer system can now be maintained, and further linked to a secure private voting system.

[0123] This application discloses a system that extends the functionality of Bitcoin without requiring changes to the underlying protocol. Using the system of the present invention: 1) No trusted third party is required for the selection or distribution of key secrets. 2) It is possible to create a decentralized banking system that does not rely on the trust of a third party. 3) Each member or group of members may independently verify that the private key shares they hold correspond to the Bitcoin addresses and advertised public keys. 4) There is a protocol for refreshing the private key slices to reduce the impact of eavesdropping and related attacks. 5) No trusted third party is required for group signing of transactions and messages. 6) A third party can maintain the integrity of the keys within a threshold group. This group of signers does not know how many Bitcoins or other assets are held under their custody. Because this is a threshold system, if some members of the signing group are unavailable, other members can still blind sign transactions, allowing the transfer of funds to be protected.

[0124] The system of the present invention solves many existing security risks since sensitive data does not appear in memory. It also enables systems based on decentralization of transactions, web wallets, and other forms of commerce. In this system, hierarchical threshold groups can interact with other hierarchical threshold groups to ensure the integrity of keys over time. In this scenario, a solution can be created that allows the transfer of funds due to a given event. Such scenarios include the transfer of wills and assets that can be controlled and protected, allowing key recovery in a variety of scenarios.

[0125] Referring to FIG. 2, an illustrative simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the illustrated systems described above. For example, the computing device 2600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 2, the computing device 2600 may include one or more processors with one or more levels of cache memory and memory controller (collectively labeled 2602) that may be configured to communicate with a storage subsystem 2606 that includes a main memory 2608 and a permanent storage device 2610. The main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read only memory (ROM) 2620 as shown. The storage subsystem 2606 and the cache memory 2602 may be used for storage of information such as details associated with transactions and blocks as described in this disclosure. The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0126] The processor 2602 may also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0127] Bus subsystem 2604 may provide a mechanism that allows the various components and subsystems of computing device 2600 to communicate with each other as intended. Although bus subsystem 2604 is illustrated generally as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0128] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616, in some embodiments, may act as an interface to receive data from and transmit data to other systems in the computing device 2600. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network so that the data technician can send data to and receive data from the device without being in a remote location, such as a data center.

[0129] User interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into computing device 2600.

[0130] The one or more user interface output devices 2614 may include a display system, a printer, or a non-visual display such as an audio output device, or the like. The display subsystem may include a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a flat-panel device such as a projection, or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface and facilitate user interaction with applications that perform the processes and transformations described herein, when such interaction is appropriate.

[0131] The storage subsystem 2606 may provide a computer-readable storage medium that stores basic programming and data structures that provide the functionality of at least one embodiment of the present disclosure. Applications (e.g., programs, code modules, instructions) that, when executed by one or more processors, provide the functionality of one or more embodiments of the present disclosure may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 also provides a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The permanent storage device 2610 may provide permanent (non-volatile) storage of programs and data and may include a magnetic hard disk drive, one or more floppy disk drives associated with removable media, one or more optical drives (e.g., CD-ROM, or DVD, or Blue-Ray) drives associated with removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments described in this disclosure, and data associated with the transactions and blocks described in this disclosure.

[0132] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device that can be connected to the computing device 2600 may include multiple ports configured to receive optical fiber connectors. The device may thus be configured to convert optical signals into electrical signals that are transmitted to the computing device 2600 through the ports connecting the devices for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 2 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 2.

[0133] It should be noted that the above-described embodiments illustrate, rather than limit, the invention, and that those skilled in the art can devise many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs in parentheses are not intended to limit the claims. The terms "comprising" and "including" and the like do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "having or consisting of" and "comprising" means "comprising or consisting of". A singular reference of an element does not exclude a plural reference of such an element. Vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage.

[0134] <Appendix> Algorithm 1: Key generation Domain parameters (CURVE, Cardinality n, Generator G) Input: N / A Output: Blinding Key Shares α A(1) ,α A(2) ,…,α A(i) ,…,α A(m) For a threshold of l slices from (m) participants, we use blind key segments α associated with participant (i) and (m-1) participants designated as participant (h) who are other parties with whom participant (i) exchanges secrets to sign blind keys. A(i) i is constructed.

[0135] In this method, m is the total number of participants, and 1≦m, so i=m-1.

[0136] ·Therefore, there exists a (l+1,m) threshold sharing scheme.

[0137] The method in Algorithm 1 is as follows.

[0138] (1)(j) Each participant p (i) exchanges an ECC public key (or Bitcoin address in this implementation) with every other participant, where 1≦i≦j. This address is the group identity address and does not need to be used for any other purpose.

[0139] Note that this is a key based on an address derived, for example as disclosed in International Patent Application WO2017 / 145016, and a shared value between each of the participants from the process disclosed therein.

[0140] (2) Each participant p (i) is a polynomial f of degree (k-1) with random coefficients in a manner that is secret from all other parties. iSelect (x).

[0141] This function is the participant's secret a0 chosen as the free term of the polynomial. (i) This value is not shared. It is calculated using a derived private key.

[0142] fi(h) is the value at point (x=h) of participant p (i) is defined as the result of a function f(x) selected by participant p (i) The basic equation for the function: (x) =Σ p=0 (k-1) a p x p It is defined as:

[0143] In this formula, a0 (i) is each participant p (i) is a secret and will not be shared.

[0144] Therefore, for each participant p (i) is a free term a0 defined as the participant's secret (i) A secret function f i (x).

[0145] f i(x) =Σγ =0 (k-1) a γ x γ mod n (3) Each participant p (i) Participant P (h) f to ∀h={1,…,(i-1),(i+1),…,j} i (h) t is expressed as P (h) Encrypt using public key 1 of (h) Exchange the values ​​of

[0146] Note that for any base point G,

number

[0147] Z n If Z is a field and we can efficiently perform Lagrange interpolation modulo n on the value chosen as the ECC private key, then Shamir's Secret Sharing Scheme (SSSS) [5] can be used to n There are conditions that lead to the conclusion that it can be implemented.

[0148] (4) Each participant P (i) broadcasts the following value to all participants:

[0149] (a) K (i) G∀k={0,…,(k-1)} (b)f i (h) G∀h = {1,…,j} The value associated with the variable h in the above formula is (h) As a result, participant P (h) If represents a third participant in the scheme, h=3, or equivalently, the value of the ECC public key used by the participant may be represented as an integer. There are use cases and scenarios for either implementation. In the latter implementation, the value h={1,...,j} may be replaced by an array of values ​​that map to the public keys used by the individual participants.

[0150] (5) Each participant P (h≠i) verifies the consistency of the shares received with those from each other participant, i.e.: Σ K=0 (k-1) h k a k (i)G=f i (h)G And f i (h) G equals the participant's share.

[0151] (6) Each participant P (h≠i) The participant (P (h≠i) ) and verify that the received shares match other received shares.

[0152] a0 (i) G=Σ h∈B β j f i (h)G∀P (h≠i) If this does not match, the participant rejects the protocol and starts again.

[0153] (7) Participant p (i) Their share A(i) is calculated as follows:

[0154] SHARE(p (i) )=d A(i) =Σ h=1 j f h (i) mod n Here, SHARE(p (i) )∈Z n and d A(j) and Where:

number

[0155] Therefore, the private key share dA(i) ←Z n * is generated without knowledge of the other participants.

[0156] Algorithm 2: Update the secret key Input: Private key d A Participant P i Share of A(i) Output: Participant P i , new private key share d A(i) ' Algorithm 2 can be used to update the secret key and to add randomness to the protocol.

[0157] Hierarchical subkey recalculation can be performed without having the existence of reconstruction or computed private keys. In this way, it is possible to construct a hierarchy of Bitcoin addresses and private key slices that, if deployed correctly, eliminates any large scale fraud or database theft that has occurred in the past.

[0158] (1) Each participant chooses a random polynomial of degree (k-1) with zero as a free term. This is similar to Algorithm 1, but each participant must verify that all other participants' chosen secrets are zero.

[0159] The following should be noted:

number

[0160] Using this formula, all active participants verify the following function:

number

[0161] Generate zero shares:z i ←Zn * (2)d A(i) '=d A(i) +z i (3)Return value: d A(i) ' The result of this algorithm is a new key share associated with the original private key. Variations of this algorithm allow the ability to both increase the randomness of the first algorithm or engage in a re-sharing exercise that results in new key slices without the need to change the Bitcoin address. In this manner, the protocol of the present invention allows participants to additionally mask private key shares without changing the underlying private key. This process can be used to minimize any possible key leakage associated with the successive use and deployment of individual key shares without changing the underlying Bitcoin address and private key.

[0162] Algorithm 3: Signature Generation Domain parameters (CURVE, Cardinality n, Generator G) Input: Message to be signed: e = H(m) Private key share:d A(i) ∈Z n * Output: Signature: For e = H(m), (r,s) ∈ Z n * A) Distributed key generation (1) Generate ephemeral key shares using algorithm 1: D k(i) ←Z n * (2) Generate the mask share using Algorithm 1: α i ←Z n (3) Generate the mask share using Algorithm 2: β i ,c i ←Z n 2 signature generation (4) e = H(m): Verify the hash of message m.

[0163] (5) Broadcast the following:

number

number

number

number

[0164] (10)S i =D k(i) (e+D A(i) r)+C i Broadcast mod n.

[0165] (11) S = Interpolate(s i ,…,s n ) mod n If s=0, repeat Algorithm 3 from the beginning (A.1).

[0166] (12)Return (r,s).

[0167] (13) In Bitcoin, transactions with an (r,s) pair are reconstructed to form a standard transaction.

[0168] References 1) Bar-Ilan, J. Beaver, "Non-Cryptographic Fault-Tolerant Computing in a Constant Number of Rounds", Proc. of 8th PODC, pp. 201-209, 1989. 2) Berlekamp, Elwyn R. (1968), Algebraic Coding Theory, McGraw-Hill, New York, NY. 3) Benger, N., van de Pol, J., Smart, N.P., Yarom, Y.: "Ooh Aah... Just a Little Bit": A Small Amount of Side Channel Can Go a Long Way. In: Batina, L., Robshaw, M. (eds.) Cryptographic Hardware and Embedded Systems | CHES 2014, LNCS, vol. 8731, pp. 75-92. Springer (2014) 4) Ben-Or, M., Goldwasser, S., Wigderson, A.: “Completeness theorems for noncryptographic fault-tolerant distributed computation”. In: Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing. pp. 1-10. STOC ’88, ACM, New York, NY, USA (1988) 5) BIP 65 OP_CHECKLOCKTIMEVERIFY https: / / github.com / bitcoin / bips / blob / master / bip-0065.mediawiki 6) Chaum, David (1983). "Blind signatures for untraceable payments" (PDF). Advances in Cryptology Proceedings of Crypto. 82 (3): 199-203. 7) Chen T.S. Huang G.S. Liu T.P. and Chung Y.F (2002), ‘Digital Signature Scheme Resulted from Identification Protocol for Elliptic Curve Cryptosystem’, Proceedings of IEEE TENCON’02. pp. 192-195 8) Chinnici M. (1995), ‘CUDA Based Implementation of Parallelized Pollard’s rho algorithm for Menezes A. and Vanstone S. Elliptic Curve Systems’, Proposed IEEE P1363 Standard, pp. 142. 9) Chwei-Shyong Tsai, Min-Shiang Hwang, pei-ChenSung, “Blind Signature Scheme Based on Elliptic Curve Cryptography” (http: / / mshwang.ccs.asia.edu.tw / www / myjournal / P191.pdf.) 10) Dawson, E.; Donovan, D. (1994), "The breadth of Shamir's secret-sharing scheme", Computers & Security, 13: Pp. 69-78 11) Desmedt. Yuo (1987). “Society and Group Oriented Cryptography: A New Concept”. In A Conference on the Theory and Applications of Cryptographic Techniques on Advances in Cryptology (CRYPTO '87), Carl Pomerance (Ed.). Springer-Verlag, London, UK, UK, 120-127. 12) ElGamal T. (1985), ‘A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms’, IEEE Transactions on Information Theory, Vol.31, pp. 469-472. 13) Feldman. P. “A practical scheme for non-interactive verifiable secret sharing”. In Proceedings of the 28th IEEE Annual Symposium on Foundations of Computer Science, pages 427-437, 1987. 14) Gennaro, R., Jarecki, S., Krawczyk, H., Rabin, T.: “Robust threshold DSS signatures”. In: Proceedings of the 15th Annual International Conference on Theory and Application of Cryptographic Techniques. pp. 354-371. EUROCRYPT’96, SpringerVerlag, Berlin, Heidelberg (1996) 15) Ibrahim, M., Ali, I., Ibrahim, I., El-sawi, A.: “A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme”. In: Circuits and Systems, 2003 IEEE 46th Midwest Symposium on. vol. 1, pp. 276-280 (2003) 16) Johnson, D., Menezes, A., Vanstone, S.: “The elliptic curve digital signature algorithm (ecdsa)”. International Journal of Information Security 1(1), 36-63 (2001) 17) Chakraborty, Kalyan & Mehta, Jay (2011) “A Stamped Blind Signature Scheme based on Elliptic Curve Discrete Logarithm Problem” (http: / / ijns.femto.com.tw / contents / ijns-v14-n6 / ijns-2012-v14-n6-p316-319.pdf). 18) Kapoor, Vivek, Vivek Sonny Abraham, and Ramesh Singh. "Elliptic Curve Cryptography." Ubiquity 2008, no. May (2008): 1-8. 19) Knuth, D. E. (1997), “The Art of Computer Programming, II: Seminumerical Algorithms” (3rd ed.), Addison-Wesley, p. 505. 20) Koblitz, N. "An Elliptic Curve Implementation of the Finite Field Digital Signature Algorithm" in Advances in Cryptology -- Crypto '98. Lecture Notes in Computer Science, vol. 1462, pp. 327-337, 1998, Springer-Verlag. 21) Liu, C. L. (1968), “Introduction to Combinatorial Mathematics”, New York: McGraw-Hill. 22) National Institute of Standards and Technology: FIPS PUB 186-4: “Digital Signature Standard” (DSS) (2003) 23) Pedersen, T.: “Non-interactive and information-theoretic secure verifiable secret sharing”. In: Feigenbaum, J. (ed.) Advances in Cryptology - CRYPTO ’91, LNCS, vol. 576, pp. 129-140. Springer (1992) 24) Rabin T. & Ben-Or. M. (1989) "Verifiable secret sharing and multiparty protocols with honest majority". In Proc. 21st ACM Symposium on Theory of Computing, pages 73--85, 1989. 25) Shamir, Adi (1979), "How to share a secret", Communications of the ACM, 22 (11): Pp. 612-613 26) Wright, C. & Savanah, S. (2016) “Determining a common secret for two Blockchain nodes for the secure exchange of information” "Application Number: 15087315". 2016: n. pag. UK

Claims

1. 1. A method for obtaining digitally signed data, the method comprising: transmitting first data by a first participant of a plurality of first participants to a second participant of a plurality of second participants, the first data being based on second data accessible to at least one of the first participants, the second data being inaccessible to each of the second participants, each of the first and second participants being a computer system; receiving, by the first participant, a digital signature of the first data from a second participant; processing the digital signature of the first data by the first participant to provide a digital signature of the second data; The method includes:

2. 2. The method of claim 1, wherein the digital signature of the second data is provided by processing the digital signature of the first data by the multiple first participants to provide shares of the digital signature of the second data, the digital signature of the second data being accessible with a threshold number of the shares and inaccessible with shares less than the threshold number.

3. 3. The method of claim 2, wherein each of the shares of the digital signature of the second data comprises shares of a plurality of first secret values ​​shared among the plurality of first participants using joint random secret sharing (JRSS).

4. 4. The method of claim 3, wherein each of the shares of the digital signature of the second data comprises at least one first masking share shared among the plurality of first participants using joint zero secret sharing (JZSS).

5. 5. The method of claim 3, wherein the first data is generated using shares of the first data such that the first data is accessible using a threshold number of the shares and is inaccessible with shares less than the threshold number.

6. 6. The method of claim 5, wherein each of the shares of the first data comprises shares of a plurality of the first secret values ​​shared using joint random secret sharing (JRSS) among a plurality of the first participants.

7. 7. The method of claim 6, wherein each of the shares of the first data includes at least one second masking share shared among the plurality of first participants using joint zero secret sharing (JZSS).

8. The method of claim 1, further comprising receiving, from the second participant, third data based on the plurality of second secret values.

9. 9. A method according to any one of claims 1 to 8, wherein the digital signature of the first data is generated using shares of the digital signature of the first data shared among the plurality of second participants, the digital signature of the first data being accessible using a threshold number of the shares and inaccessible with shares less than the threshold number.

10. 10. The method of claim 9, wherein each of the shares of the digital signature of the first data comprises shares of a plurality of second secret values ​​shared among a plurality of the second participants using joint random secret sharing (JRSS).

11. 11. The method of claim 10, wherein each of the shares of the digital signature of the first data includes at least one third masking share shared using joint zero secret sharing (JZSS) among a plurality of the second participants.

12. The method according to any one of claims 1 to 11, wherein the second data is a message.

13. The method of claim 1 , wherein the second data is a hash value of the message.

14. 14. The method of claim 1, wherein the first data is a blockchain transaction.

15. 15. The method of claim 1, wherein at least one of the digital signatures is based on a cryptosystem having homomorphic properties.

16. The method of claim 15 , wherein at least one of the digital signatures is based on an elliptic curve cryptosystem.

17. 1. A computer-implemented system comprising: A processor; a memory containing executable instructions which, upon execution by the processor, cause the system to perform a method according to any one of claims 1 to 16; A system including:

18. A non-transitory computer readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to perform at least a method according to any one of claims 1 to 16.

Images