2PC-MPC: ecdsa threshold signature based on a threshold additively homomorphic encryption

Abstract

Method and system for generating digital signature following one or more secure protocols based on a threshold additively homomorphic encryption (TAHE) over a broadcast channel, where a threshold of parties of a decentralized network produces digital signature by following a Universally Composable secure protocol configured to output Elliptic curve digital signature algorithm (ECDSA) signature or a Schnorr signature. At least one client may cooperate with the threshold of parties to generate digital signature, or threshold of parties may cooperate to generate digital signature without a client. Method may include additively homomorphic encryption (AHE) distributed key generation (DKG), ECDSA / Schnorr DKG, ECDSA / Schnorr presigning, providing ECDSA / Schnorr child keys, ECDSA / Schnorr signing, wallet transfer and / or network reconfiguration.

Description

[0001] PC-MPC: ECDSA THRESHOLD SIGNATURE BASED ON A THRESHOLD ADDITIVELY HOMOMORPHIC ENCRYPTION

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S Provisional Application No. 63 / 547,714, filed on 8 November 2023, and claims priority to U.S Provisional Application No. 63 / 700,778, filed on 30 September 2024, the entire contents of each of which are incorporated herein by reference.

[0004] TECHNICAL FIELD

[0005] The present disclosure generally relates to the field of cryptography, and more particularly to public-key encryption schemes.

[0006] BACKGROUND

[0007] A homomorphic encryption scheme enables mathematical operations or computations to be performed on encrypted data without requiring its decryption. Therefore, the data remains confidential while being processed, even in an untrusted environment. As a result, useful operations may be performed on the encrypted data by a third party without requiring the third party to properly secure the data, as the original data cannot be identified without the decryption key. For example, a person or organization may apply standard encryption techniques to secure sensitive data on cloud platforms, but processing or validating the encrypted data in the cloud would require its decryption, which raises privacy issues and security vulnerabilities and may entail additional costs and resources. By utilizing homomorphic encryption, private data may be shared and evaluated securely in commercial cloud environments without endangering privacy. The cloud service provider only has access to the encrypted data (ciphertext) and can perform computations on the data without decryption. The results of the encrypted processing may be provided to the owner of the private data who can then decrypt the data (into plaintext) via the decryption key. In addition to cloud services, homomorphic encryption can be used by entities in a wide vary of businesses and industries, such as financial services, healthcare, retail, information technology and artificial intelligence systems, to allow access to encrypted data while protecting client or patient privacy.

[0008] Homomorphic encryption schemes may be classified into several categories, including partially homomorphic encryption, somewhat homomorphic encryption, and fully homomorphic encryption. A partially homomorphic encryption allows only a single operation to be performed on the ciphertext, such as addition or multiplication. In contrast, fully homomorphic encryption (FHE) supports multiple operations indefinitely, such as both addition and multiplication, enabling a wider range of arbitrary computations to be performed on the ciphertext. However, FHE is characterized by certain limitations, particularly a very large computational overhead and high inefficiency due to protracted time for performing computations. Many FHE schemes are based on lattice mathematics, such as derived from the ring learning with errors (RLWE) problem, and are generally considered secure from breaches by quantum computing (i.e., post-quantum cryptography).

[0009] An Elliptic curve digital signature algorithm (ECDSA) is among the NIST (National Institute of Standards and Technology) standards for digital signature. Much effort has been put into thresholdizing ECDSA in past years, and threshold ECDSA schemes have been widely deployed, mainly due to its widespread use as an authentication scheme for decentralized blockchain instruments, such as cryptocurrencies (e.g., Bitcoin, Ethereum), in which the signature constitutes a proof of ownership of the funds.

[0010] Threshold signature based solutions in the cryptocurrency industry flourish and focus on two main types of use cases: “distributed custody” (e.g., Fireblocks, Zengo, and Qredo) and “decentralized bridges” (e.g., Thorchain, Keep Network, and the Internet Computer). Distributed custody leverages threshold signature protocols to mitigate the self-custodial risks of lost and theft, by distributing the secret signing key of the client, who is the legal owner of the funds, between multiple signers. The signing key is secret shared in a way that requires the active consent of both the client and the distributed custodian to produce a signature. A distributed bridge consists of a network of nodes who distributively manage multiple signing keys for different wallets, each holding a pool of funds on different blockchains used to form cross-chain liquidity pools. This enables a single entity (the network) to permissionlessly own, manage and transfer funds (and information) across different blockchains. When a client owning wallets on two different blockchains wishes to transfer funds between them, it can send funds to one end of the bridge’s liquidity pool and request a withdrawal of an equivalent amount to the client’s wallet on the other end. The bridge network then creates and distributedly signs a corresponding transaction that can then be broadcasted by the client to the other blockchain, to complete the exchange.

[0011] Due to inherent limitations of existing proposals for threshold signing protocols, all real -world networks are deployed with a rather small number of nodes (for example, on the order of about 10-20). This is not in par with the vision of decentralization since when the number of nodes is small it is difficult to argue that these nodes are not colluding.

[0012] To date, practical threshold ECDSA schemes are generally designed to work over unicast channels, assuming secure point-to-point (P2P) channels between every pair of parties. While secure point-to-point channels can be constructed in theory (under an appropriate PKI setup), in practice they inherently incur a high network load (i.e., maintaining a high number of sessions concurrently) and a message complexity of Q(n2). as each party computes and sends a message in private to every other party. For a protocol to take advantage of a broadcast channel it needs to avoid private messages over secure channels (i.e., Pi sending a message to be seen only by Pj), rather, all messages must be public.

[0013] Generic MPC protocols in the broadcast channel model are ubiquitous, and oftentimes enjoy extra desirable properties, such as “identifiable abort” and “public verifiability”. The broadcast channel itself may be either implemented in-house by the protocol’s participants or rely on an external implementation. In recent years the use of a blockchain as a broadcast channel has surged, as it offers immutability of messages (which enables easy recovery from failures) as well as incentive mechanisms for faithful participation. However, multiparty threshold ECDSA protocols are rarely designed to operate in a broadcast communication model. One exception is described in Gennaro et al. (Rosario Gennaro, Steven Goldfeder, and Arvind Narayanan. Threshold-optimal DSA / ECDSA signatures and an application to bitcoin wallet security. In International Conference on Applied Cryptography and Network Security, pages 156-174. Springer, 2016.) that relies on a trusted setup, which hinders its applicability to the aforementioned use cases, which were incepted in order to avoid the trusted party in the first place. Emulating the setup phase of Gennaro et al. in a distributed setting may be possible in theory but is considered infeasible since it requires a distributed generation of safe primes from which the parameters to a zero-knowledge proof system are derived.

[0014] SUMMARY

[0015] In accordance with an aspect of the present disclosure, there is provided a method for generating at least one digital signature, including following one or more secure protocols based on a threshold additively homomorphic encryption (TAHE) over a broadcast channel, where a threshold of parties of a decentralized network (DN) produces the digital signature by following a Universally Composable (UC)-secure protocol configured to output at least one of an Elliptic curve digital signature algorithm (ECDSA) signature or a Schnorr signature. At least one client and a threshold of parties of the decentralized network may cooperate to generate the digital signature. The threshold of parties of the decentralized network may cooperate to generate the digital signature without a client. The method may include generating a distributed key using a distributed key generation (DKG) protocol of the one or more secure protocols. The DKG protocol may be a DKG protocol over a synchronous communication channel (“DKG Protocol Sync”), the DKG Protocol Sync being parameterized with a group description (G, G, q) and interacting with n + 1 parties including a client A, and DN parties B = (Bt}ie[n] , where all parties hold a public key (pk) as input and agree on a fresh session-identifier (sid) that uniquely identifies a session. The DKG protocol may be a DKG protocol over an asynchronous communication channel (“DKG Protocol Async”), the DKG Protocol Async being parameterized with a group description (G, G, q). an access structure rB, a unique session identifier sid, and an encryption key to a TAHE scheme pk, where the DKG Protocol Async interacts with a centralized party ApidAand a set of parties B = {Bihefnb where the set of parties B can only send messages to parties in A through a functionality ^global-broadcast- The method may further include distributing, by a client that holds a private signing key, the private signing key between the client and the decentralized network. The method may further include pre-signing using a presign protocol of the one or more secure protocols. The presign protocol may be a presign protocol using an ECDSA scheme over a synchronous communication channel (“Presign Protocol ECDSA / Sync”), the Presign Protocol ECDSA / Sync interacting with n + 1 parties including a client A, and DN parties B = (Bt}je[n] , where all parties hold a public key (pk) and an encryption of a network share under TAHE (ctkey) as input, where all parties verify that a session-identifier sid has never been used before. The presign protocol may be a presign protocol using a Schnorr scheme over a synchronous communication channel (“Presign Protocol Schnorr / Sync”), the Presign Protocol Schnorr / Sync interacting with n + 1 parties including a client A, and DN parties B = (Bt}je[n] , where all parties have an encryption of a network share under TAHE (ctkey) as input, where all parties verify that a session-identifier (sid) has never been used before. The presign protocol may be a presign protocol using an ECDSA scheme over an asynchronous communication channel (“Presign Protocol ECDSA / Async”), the Presign Protocol ECDSA / Async parameterized with: a group description (G, G, q), an access structure fB, a unique session identifier sid, an encryption key to a TAHE scheme pk, an ECDSA verification key X, a centralized party share of the verification key XA, and an encryption of a share of a distributed party of a signing key ctkey, the Presign Protocol ECDSA / Async interacting with a centralized party ApidAand a set of parties B = {Bj}ie[n] , where the set of parties B can only send messages to parties in A through a functionality Fgiobai-broadcast- The presign protocol may be a presign protocol using a Schnorr scheme over an asynchronous communication channel (“Presign Protocol Schnorr / Async”), the Presign Protocol Schnorr / Async parameterized with: a group description (G, G, q), an access structure rB, a unique session identifier sid, and an encryption key to a TAHE scheme pk, the Presign Protocol Schnorr / Async interacting with a centralized party ApidAand a set of parties B = (Bt}je[n] , where the set of parties B can only send messages to parties in A through a functionality ? global-broadcast- The method may further include signing a message using a sign protocol of the one or more secure protocols. The sign protocol may be a sign protocol using an ECDSA scheme over a synchronous communication channel (“Sign Protocol ECDSA / Sync”), the Sign Protocol ECDSA / Sync interacting with n + 1 parties including a client A, and DN parties B = {Bi}i6[n], where all parties hold a public key (pk), network public nonce shares (RB, RB), and a commitment on A’s share of the nonce for signature (K^), as input, where all parties verify that a session-identifier (sid) has never been used before. The sign protocol may be a sign protocol using a Schnorr scheme over a synchronous communication channel (“Sign Protocol Schnorr / Sync”), the Sign Protocol Schnorr / Sync interacting with n + 1 parties including a client A, and DN parties B = (Bt}je[n] , where all parties have a public key (pk), network public nonce shares (RB, RB), a commitment on As share of the nonce for signature (K^ ), an encryption of a network share (ctkey) , and encryptions of nonces k0,

[0016] (ctfc0’ctfci)asinput, where all parties verify that a session-identifier (sid) has never been used before. The sign protocol may be sign protocol using an ECDSA scheme over an asynchronous communication channel (“Sign Protocol ECDSA / Async”), the Sign Protocol ECDSA / Async parameterized with a group description (G, G, q), a public generator (H) used for Pedersen commitments, an access structure rB, a unique session identifier (sid), an encryption key to a TAHE scheme pk, an ECDSA verification key X, a centralized party share of the verification key XA, an encryption of a share of a distributed party of a signing key ctkey, an output of a uniquely determined previous presign protocol presX, sid = (cty, cty.key, cty.ko, cty.ki, RB , and a message to be signed (msg), the Sign Protocol ECDSA / Async interacting with a centralized party ApidAand a set of parties B = {Bj}ie[n] , where the set of parties B can only send messages to parties in A through a functionality Fgiobai-broadcast, where the parties output a valid ECDSA signature a = (r, s) with verification key X. The sign protocol may be a sign protocol using a Schnorr scheme over an asynchronous communication channel (“Sign Protocol Schnorr / Async”), the Sign Protocol Schnorr / Async parameterized with: a group description (G, G, q), an access structure TB, a unique session identifier (sid), an encryption key to a TAHE scheme pk, a public verification key X, an encryption of the share of the distributed party of the private signing key ctkey, an output of a unique presign presx= (KB O, KBI), and a message to be signed (msg), the Sign Protocol Schnorr / Async interacting with a centralized party ApidAand a set of parties B = {Bihefnb where the set of parties B can only send messages to parties in A through a functionality ^global-broadcasts where each party Btoutputs a valid Schnorr signature (z, e) to the verification key X. Each DN party may have a respective voting power, and the method may further include changing the voting power of at least one DN party using a network reconfiguration routine. The network reconfiguration routine may include a reconfiguration protocol with a varying threshold (“Reconfiguration Protocol Varying Threshold”), the Reconfiguration Protocol Varying Threshold parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme (PVSS), a computational security parameter K, a statistical security parameter o. an initial threshold t and a final threshold t', the Reconfiguration Protocol Varying Threshold interacting with a transferringquorum ^^ = {^^^}^∈[^] and a receiving quorum ^^′ = {^^′^ᇱ}^ᇱ∈[^ᇱ], where the transferring quorumholds a ^^-^^^^^^-^^^^-^^ secret sharing[sk]^on a secret key of a TAHE (sk), where the transferring quorum and the receiving quorum hold a public ke ^^^^ he encryption scheme, verification keys of the transferring quorum {vk^}^∈[^], and an encryption of the secret key ct^^= Encp^k (^^^^; ^^), where the Reconfiguration Protocol Varying Threshold outputs a fresh ^^′-^^^^^^-^^^^-^^′secret shares[sk]^ᇱon the secret key (sk) held by ^^′ and public verification keys{vk'^ᇱ}^ᇱ∈[^ᇱ]corresponding to the secret shares, where when the Reconfiguration Protocol Varying Threshold begins the parties already executed PVSS.Setup and PVSS.Gen successfully, and holds public keys for the new parties{pk^ᇱ}^ᇱ∈[^ᇱ]. The network reconfiguration routine may include a reconfiguration protocol with a constant threshold (“Reconfiguration Protocol Constant Threshold”), the Reconfiguration Protoc l Constant Threshold parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme PVSS, a computational security parameter ^^, and a threshold ^^, the Reconfiguration Protocol Constant Threshold interacting with a transferringquorum ^^ = {^^^}^∈[^] and a receiving quorum ^^′ = {^^′^ᇱ}^ᇱ∈[^ᇱ], where the transferring quorumholds a ^^-^^^^^^-^^^^-^^ secret sharing [sk]^on a secret key of a TAHE sk, where the transferring quorum and the receiving quorum hold a public key ( ncryption scheme, and verification keys of the transferring quorum {vk^}^∈[^], where the Reconfiguration Protocol Constant Threshold outputs a fresh ^^-^^^^^^-^^^^-^^ secret shares[sk]^ᇱon the secret key sk held by ^^′ and public verification keys {vk'^ᇱ}^ᇱ∈[^ᇱ]corresponding to the secret shares, where when the Reconfiguration Protocol Constant Threshold begins the parties already executed PVSS.Setup and PVSS.Gen successfully, and holds appropriate public keys for the new parties {pk^ᇱ}^ᇱ∈[^ᇱ]. A plurality of clients and the threshold of parties of the decentralized network may cooperate to generate the digital signature, and the method may further include transferring ownership of a resource from a sender client of the plurality of clients to a receiver client of the plurality of clients using an ownership transfer protocol of the one or more secure protocols. The ownership transfer protocolmay be parameterized with a group description (^^, ^^, ^^), and interacts with parties ^^^^ௗ, ^^^^௪ andwhere ^^^^ௗtransfers its secret key to ^^^^௪and{^^^}^∈^^approves the transfer, where all arties hold: a public key (pk) to the encryption scheme; a public key of ^^^^௪(pk^^^^); a public share of ^^^^ௗof a signing key a public verification key (^^) as input, and where the parties agree on a fresh session identifier At least one secure protocol of the one or more secure protocols may include an identifiable abort. At least one secure protocol of the one or more secure protocols may be publicly verifiable. At least one secure protocol of the one or more secure protocols may be performed over an asynchronous communication channel and comprises guaranteed output delivery. The method may further include performing a generic transformation to securely transform a plaintext space of the TAHE, to align the plaintext space with an ECDSA / Schnorr group of order q. The method may further include a secure function evaluation for the TAHE, allowing a user to evaluate a private affine function ^^ homomorphically on a tupleof ciphertexts ^^^^^ = ^^^^^^(^^^, ^^^) without revealing information on function ^^ except foreven given a secret key of the TAHE and randomizers ^^^ and plaintexts ^^^ for theencryptions The TAHE may be tied with elliptic curve group elements, such that corresponding witnesses thereof satisfy linear relations and have range constraints, using at least one generic zero- knowledge (zk) range proof. The parties of the decentralized network may hold a single secret share, for an underlying TAHE scheme, and a network share of each secret signing key may be stored publicly encrypted under a corresponding TAHE public key. The presign protocol may be configured to generate at least one presign offline in a common pool of presigns shared with all clients in the network, such that upon signing the clients could use the common pool of pre signs to sign transactions. The method may include performing at least one performance boosting procedure include one or more of: (i) batching zero knowledge proofs; (ii) redundant range proofs when using Class-Groups; (iii) amortized decryption; and (iv) synchronous decryption. The decentralized network may be selected from one or more of: a blockchain system; a directed acrylic graphs DAG-based consensus platform; and a blockchain-DAG hybrid. The digital signature may be used for at least one application selected from one or more of: digital wallets; future transactions; bridging blockchains; wallet transfer; and decentralized autonomous organization (DAO). A public key of a digital wallet generated on a first blockchain may be configured to be used as a digital wallet on a second blockchain. A policy may be specified upon generation of the digital wallet on the first blockchain, and the first blockchain may enforce the policy when using the digital wallet for the second blockchain participating in signing requests only on transactions valid with the specified policy. A future transaction may include a signed transaction of a client configured to be executed when a predetermined condition is met, where the blockchain is configured to delay execution of the transaction. A decentralized autonomous organization (DAO) may include at least one child key derived from a parent key, where the child key includes fewer permissions than the parent key.

[0017] In accordance with an aspect of the present disclosure, there is provided a system for generating a digital signature, including a decentralized network (DN) including a plurality of parties, configured to follow one or more secure protocols based on a threshold additively homomorphic encryption (TAHE) over a broadcast channel, where a threshold of the plurality of parties of the DN produces the digital signature by following a Universally Composable (UC)-secure protocol configured to output at least one of an Elliptic curve digital signature algorithm (ECDSA) signature or a Schnorr signature. At least one client and a threshold of parties of the decentralized network may cooperate to generate the digital signature. The threshold of parties of the decentralized network may cooperate to generate the digital signature without a client. The system may include a network distributed key generation (DKG) module, configured to generate a distributed key using a distributed key generation (DKG) protocol of the one or more secure protocols. The DKG protocol may be a DKG protocol over a synchronous communication channel (“DKG Protocol Sync”), the DKG Protocol Sync being parameterized with a group description (G, G, q) and interacting with n + 1 parties including a client A, and DN parties B = {Bt}je[n] , where all parties hold a public key (pk) as input and agree on a fresh session-identifier (sid) that uniquely identifies a session. The DKG protocol may be a DKG protocol over an asynchronous communication channel (“DKG Protocol Async”), the DKG Protocol Async being parameterized with a group description (G, G, q). an access structure fB, a unique session identifier sid, and an encryption key to a TAHE scheme pk, where the DKG Protocol Async interacts with a centralized party ApidAand a set of parties B = (Bt}je[n], where the set of parties B can only send messages to parties in A through a functionality global-broadcast- The system may be configured to distribute, by a client that holds a private signing key, the private signing key between the client and the decentralized network. The system may include a network ECDSA / Schnorr presign module, configured for pre-signing using a presign protocol of the one or more secure protocols. The presign protocol may be a presign protocol using an ECDSA scheme over a synchronous communication channel (“Presign Protocol ECDSA / Sync”), the Presign Protocol ECDSA / Sync interacting with n + 1 parties including a client A, and DN parties B = (Bt }ie[n] , where all parties hold a public key (pk) and an encryption of a network share under TAHE (ctkey) as input, where all parties verify that a session-identifier sid has never been used before. The presign protocol may be a presign protocol using a Schnorr scheme over a synchronous communication channel (“Presign Protocol Schnorr / Sync”), the Presign Protocol Schnorr / Sync interacting with n + 1 parties including a client A, and DN parties B = {Sihe^q- where all parties have an encryption of a network share under TAHE (ctkey) as input, where all parties verify that a session-identifier (sid) has never been used before. The presign protocol may be a presign protocol using an ECDSA scheme over an asynchronous communication channel (“Presign Protocol ECDSA / Async”), the Presign Protocol ECDSA / Async parameterized with: a group description (G, G, q). an access structure rB, a unique session identifier sid, an encryption key to a TAHE scheme pk, an ECDSA verification key X, a centralized party share of the verification key XA, and an encryption of a share of a distributed party of a signing key ctkey, the Presign Protocol ECDSA / Async interacting with a centralized party ApidAandaset °f parties B where the set of parties B can only send messages to parties in A through a functionality global-broadcast- The presign protocol may be a presign protocol using a Schnorr scheme over an asynchronous communication channel (“Presign Protocol Schnorr / Async”), the Presign Protocol Schnorr / Async parameterized with: a group description (G, G, q), an access structure rB, a unique session identifier sid, and an encryption key to a TAHE scheme pk, the Presign Protocol Schnorr / Async interacting with a centralized party ApidAand a set of parties B = (Bt}je[n], where the set of parties B can only send messages to parties in A through a functionality Fgiobai-broadcast- The system may include a network ECDSA / Schnorr sign module, configured for signing a message using a sign protocol of the one or more secure protocols. The sign protocol may be a sign protocol using an ECDSA scheme over a synchronous communication channel (“Sign Protocol ECDSA / Sync”), the Sign Protocol ECDSA / Sync interacting with n + 1 parties including a client A, and DN parties B = (Bt}je[n] , where all parties hold a public key (pk), network public nonce shares (Rg , R^), and a commitment on A’s share of the nonce for signature (K^), as input, where all parties verify that a session-identifier (sid) has never been used before. The sign protocol may be a sign protocol using a Schnorr scheme over a synchronous communication channel (“Sign Protocol Schnorr / Sync”), the Sign Protocol Schnorr / Sync interacting with n + 1 parties including a client A, and DN parties B = {Bj}ie[n] , where all parties have a public key (pk), network public nonce shares (RB, RB), a commitment on A’s share of the nonce for signature (K^), an encryption of a network share (ctkey) , and encryptions of nonces k0, kT(ctko, ctki) as input, where all parties verify that a session-identifier (sid) has never been used before. The sign protocol may be sign protocol using an ECDSA scheme over an asynchronous communication channel (“Sign Protocol ECDSA / Async”), the Sign Protocol ECDSA / Async parameterized with a group description (G, G, q), a public generator (H) used for Pedersen commitments, an access structure TB, a unique session identifier (sid), an encryption key to a TAHE scheme pk, an ECDSA verification key X, a centralized party share of the verification key XA, an encryption of a share of a distributed party of a signing key ctkey, an output of a uniquely determined previous presign protocol presX, sid = and a message to be signed (msg), the Sign Protocol ECDSA / Async interacting with a centralized party ApidAand a set of parties B = {Bi}i6[n], where the set of parties B can only send messages to parties in A through a functionality ^global-broadcast, where the parties output a valid ECDSA signature a = (r, s) with verification key X. The sign protocol may be a sign protocol using a Schnorr scheme over an asynchronous communication channel (“Sign Protocol Schnorr / Async”), the Sign Protocol Schnorr / Async parameterized with: a group description (G, G, q), an access structure rB, a unique session identifier (sid), an encryption key to a TAHE scheme pk, a public verification key X, an encryption of the share of the distributed party of the private signing key ctkey, an output of a unique presign presx= (KB O, KBif and a message to be signed (msg), the Sign Protocol Schnorr / Async interacting with a centralized party Ap[dAand a set of parties B = {Bihefnb where the set of parties B can only send messages to parties in A through a functionality ^global-broadcasts where each party Btoutputs a valid Schnorr signature (z, e) to the verification key X. Each DN party may have a respective voting power, and the system may include a network reconfiguration module, configured for changing the voting power of at least one DN party using a network reconfiguration routine. The network reconfiguration routine may include a reconfiguration protocol with a varying threshold (“Reconfiguration Protocol Varying Threshold”), the Reconfiguration Protocol Varying Threshold parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme (PVSS), a computational security parameter K, a statistical security parameter o. an initial threshold t and a final threshold t', the Reconfiguration Protocol Varying Threshold interacting with a transferring quorum B = {BJiefn] and a receiving quorum B' = where the transferring quorum holds a t-out-of-n secret sharing [sk], on a secret key of a TAHE (sk), where the transferring quorum and the receiving quorum hold a public key (pk) to the encryption scheme, verification keys of the transferring quorum {vkj}je[nj, and an encryption of the secret key ctsfe= EnCpk(sk; rj), where the Reconfiguration Protocol Varying Threshold outputs a fresh t' -out-of -n' secret shares [sk]j, on the secret key (sk) held by B' and public verification keys {vk1j,}i,e[w] corresponding to the secret shares, where when the Reconfiguration Protocol Varying Threshold begins the parties already executed PVSS. Setup and PVSS. Gen successfully, and holds public keys for the new parties {pkj,}j,e[n,j . The network reconfiguration routine may include a reconfiguration protocol with a constant threshold (“Reconfiguration Protocol Constant Threshold”), the Reconfiguration Protocol Constant Threshold parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme PVSS, a computational security parameter K, and a threshold t, the Reconfiguration Protocol Constant Threshold interacting with a transferring quorum B = {Bj}je[n] and a receiving quorum B' = where the transferring quorum holds a t-out-of-n secret sharing [sk], on a secret key of a TAHE sk, where the transferring quorum and the receiving quorum hold a public key (pk) to the encryption scheme, and verification keys of the transferring quorum {vkj}je[nj, where the Reconfiguration Protocol Constant Threshold outputs a fresh t-out-of-n secret shares [sk]j, on the secret key sk held by B' and public verification keys {vk'j,}j,e[n,] corresponding to the secret shares, where when the Reconfiguration Protocol Constant Threshold begins the parties already executed PVSS.Setup and PVSS. Gen successfully, and holds appropriate public keys for the new parties {pkj,}j,e[n,] . A plurality of clients and the threshold of parties of the decentralized network may cooperate to generate the digital signature, and the system may include an ownership transfer verification module, configured for transferring ownership of a resource from a sender client of the plurality of clients to a receiver client of the plurality of clients using an ownership transfer protocol of the one or more secure protocols. The ownership transfer protocol may be parameterized with a group description (G, G, q). and interacts with parties Aoid. Anewand where Aoidtransfers its secret key to Anewand approves the transfer, where all parties hold: a public key (pk) to the encryption scheme; a public key of Anew(pkj4new); a public share of Ao[dof a signing key (Xio;d);apublic verification key (X) as input, and where the parties agree on a fresh session identifier (sid). At least one secure protocol of the one or more secure protocols may include an identifiable abort. At least one secure protocol of the one or more secure protocols may be publicly verifiable. At least one secure protocol of the one or more secure protocols may be performed over an asynchronous communication channel and comprises guaranteed output delivery. The system may be configured for performing a generic transformation to securely transform a plaintext space of the TAHE, to align the plaintext space with an ECDSA / Schnorr group of order q. The system may be configured for performing a secure function evaluation for the TAHE, allowing a user to evaluate a private affine function f homomorphically on a tuple of ciphertexts ctt= Enc(wL, ri) without revealing information on function f except for xn). even given a secret key of the TAHE and randomizers and plaintexts xtfor the encryptions ct, . The TAHE may be tied with elliptic curve group elements, such that corresponding witnesses thereof satisfy linear relations and have range constraints, using at least one generic zeroknowledge (zk) range proof. The parties of the decentralized network may hold a single secret share, for an underlying TAHE scheme, and a network share of each secret signing key may be stored publicly encrypted under a corresponding TAHE public key. The presign protocol may be configured to generate at least one presign offline in a common pool of presigns shared with all clients in the network, such that upon signing the clients could use the common pool of pre signs to sign transactions. The system may be configured for performing at least one performance boosting procedure include one or more of: (i) batching zero knowledge proofs; (ii) redundant range proofs when using Class-Groups; (iii) amortized decryption; and (iv) synchronous decryption. The decentralized network may be selected from one or more of: a blockchain system; a directed acrylic graphs DAG-based consensus platform; and a blockchain-DAG hybrid. The digital signature may be used for at least one application selected from one or more of: digital wallets; future transactions; bridging blockchains; wallet transfer; and decentralized autonomous organization (DAO). A public key of a digital wallet generated on a first blockchain may be configured to be used as a digital wallet on a second blockchain. A policy may be specified upon generation of the digital wallet on the first blockchain, and the first blockchain may enforce the policy when using the digital wallet for the second blockchain participating in signing requests only on transactions valid with the specified policy. A future transaction may include a signed transaction of a client configured to be executed when a predetermined condition is met, where the blockchain is configured to delay execution of the transaction. A decentralized autonomous organization (DAO) may include at least one child key derived from a parent key, where the child key includes fewer permissions than the parent key. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The present disclosure will be understood and appreciated more fully from the following detailed description taken in conjunction with the drawings in which:

[0019] Figure 1 is a schematic illustration of a system for generating a digital signature, constructed and operative in accordance with an embodiment of the present disclosure;

[0020] Figure 2 is a schematic illustration of a decentralized network party of the system of Figure 1, constructed and operative in accordance with an embodiment of the present disclosure;

[0021] Figure 3 is a schematic illustration of a client of the system of Figure 1, operative in accordance with an embodiment of the present disclosure;

[0022] Figure 4 is a schematic illustration of a threshold additively homomorphic encryption (TAHE) distributed key generation (DKG) process, operative in accordance with an embodiment of the present disclosure;

[0023] Figure 5 is a schematic illustration of exemplary secret key shares of a decentralized network party with a given voting power, operative in accordance with an embodiment of the present disclosure;

[0024] Figure 6 is a schematic illustration of a network reconfiguration process, operative in accordance with an embodiment of the present disclosure;

[0025] Figure 7 is a schematic illustration of an ECDSA / Schnorr distributed key generation DKG process, operative in accordance with an embodiment of the present disclosure;

[0026] Figure 8A is a schematic illustration of an ECDSA / Schnorr asynchronous presign process, operative in accordance with an embodiment of the present disclosure;

[0027] Figure 8B is a schematic illustration of a Schnorr presign process, operative in accordance with an embodiment of the present disclosure;

[0028] Figure 9 is a schematic illustration of an ECDSA / Schnorr signing process, operative in accordance with an embodiment of the present disclosure;

[0029] Figure 10 is a schematic illustration of an ownership transfer process, operative in accordance with an embodiment of the present disclosure;

[0030] Figure. 11 illustrates a diagrammatic representation of a machine in the example form of a computing device within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed; and

[0031] Figure 12 is a flow diagram of a general method for generating a digital signature, operative in accordance with an embodiment of the present disclosure. DETAILED DESCRIPTION

[0032] The disclosed embodiments relate to universal composability (UC) secure threshold ECDSA protocols that may overcome the disadvantages of the prior art by reducing message complexity from O(n2) to O(n) and reducing computational complexity from O(n) to practically 0(1), while maintaining the important identifiable abort (if protocol fails can identify a malicious party). To this end, the disclosed embodiments utilize a threshold additively homomorphic encryption, as well as novel zero-knowledge proofs, allowing parties for the first time to communicate publicly over a broadcast channel, which is important for use cases such as permissionless bridges and decentralized custody in which P2P channels between every pair of parties cannot be assumed.

[0033] Protocols of the present disclosure may employ novel batching and amortization techniques, which are of independent interest, to further reduce the computation and communication complexity. This may be done by leveraging the fact that all messages are public in two novel ways. First, the cost of threshold decryption is amortized to 0(1) exponentiations per party per ciphertext, instead of the naive Q(n). It may be shown that combining decryption shares can be done by a single designated party only, who can inform the others about the result in a verifiable manner. Second, the present disclosure provides a batchable and fully aggregateable zeroknowledge proof system that allows verification of a single proof rather than verifying multiple proofs from each prover.

[0034] Aggregating proofs comes at a cost of increasing the round complexity, which leads to offering two variants of the protocol: one is on par with 3-round variants known in the art, that scales linearly with the number of parties, while a second one is practically independent in the number of parties but incurs 7 rounds.

[0035] The present disclosure introduces the notion of a “2PC-MPC protocol”, in which a user participates in a two-party (2PC) protocol with a distributed party that emulates the second party in multiparty computation (MPC). This notion assures that both the user and a threshold of the distributed party are required to participate in signing (as in hierarchical threshold access structures) whilst abstracting away the internal structure of the distributed party. In particular, the communication and computation complexity of the user remain constant, which allows for distributed custody use-cases to employ decentralization for the first time, as recent growing interest in the industry demands.

[0036] Protocols that use a broadcast channel naturally reduce the message complexity from Q(n2) to 0(n). yet each party intuitively reads and processes a message from every other party, and so the computational overhead remains Q(n).

[0037] The disclosed embodiments may leverage the fact that all messages are public in order to demonstrate two ways to further reduce the computational complexity of processing these messages to practically 0(1). First, in the threshold decryption sub-protocol the parties broadcast their decryption shares, which are then combined to obtain a final plaintext. Combining the decryption shares may incur Q(n) exponentiations per party per ciphertext. However, this can be done by a single designated party only, who can inform the other parties about the result in a verifiable manner. When many executions of threshold decryption are run in parallel, picking a different designated party for each ciphertext can reduce the amortized complexity to 0(1) exponentiations per party per ciphertext. Secondly, to ensure correctness of the execution, each operation by the parties may be accompanied by a zero-knowledge proof. Typically, the parties separately verify a proof broadcasted by any other party before proceeding to the next protocol step. Considering that zero-knowledge proof verification is one of the computationally heaviest operations in many threshold ECDSA protocols, the present disclosure relates to novel zeroknowledge proof systems that may be considered “fully aggregateable”. Namely, one can first aggregate the n proofs into a single aggregated proof, and then verify only one aggregated proof. While verification of the aggregated proof remains a heavyweight operation, aggregating is orders of magnitude cheaper. Thus, the overall computational complexity consists of a simple aggregation of n proofs (n multiplications in a group) followed by only a single proof verification (0(1) exponentiations) and so even considering thousands of parties, the computational complexity may be reduced to practically 0(1). Such amortization and aggregation mechanisms can thus be taken to the full extent in the context of threshold ECDSA.

[0038] Considering concrete efficiency (i.e., wall-clock time to produce a signature), the “DKLS protocol” described in Doemer at al. (Jack Doemer, Yashvanth Kondi, Eysa Lee, and Abhi Shelat. Threshold ECDSA in three rounds. IACR Cryptol. ePrint Arch., page 765, 2023) demonstrates that 250 parties can produce a signature in a few seconds. That protocol, however, relies on a P2P network which requires a large bandwidth. In addition, the DKLS protocol lacks identifiable abort, which hinders it from being used for permissionless use-cases such as the aforementioned bridge, as it would be quite easy for every single party to amount a denial-of-service attack. In that context, one exemplary protocol that has identifiable abort is disclosed in Canetti et al. (Ran Canetti, Rosario Gennaro, Steven Goldfeder, Nikolaos Makriyannis, and Udi Peled. UC non-interactive, proactive, threshold ECDSA with identifiable aborts. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, pages 1769- 1787, 2020). Canetti et al. offers two variants to achieve identifiable abort: the first requires each party to verify O(n2) zeroknowledge proofs, which is not scalable, whereas the second requires O(n) verifications, at the cost of three additional communication rounds. Both versions of the protocol are not scalable with the number of parties and become impractical at around 10-20 parties.

[0039] The above-mentioned improvements in communication and computation may enable distributed signing solutions like bridges, where the signing key owner is the network itself, to scale to an extremely large number of participants. In contrast, when the owner of the signing key is an external client, as in the distributed custody use case, the signing protocol must be held between the custodial and the client, which motivated designing practical two-party signature protocols, such as described in Lindell (Y ehuda Lindell. Fast secure two-party ECDSA signing. In Annual International Cryptology Conference, pages 613 -644. Springer, 2017). In such protocols, the custodian acts as a service provider who cannot sign without participation of the client. Such custodian solutions may increase the trust in the service provider but still suffer from centralization. For instance, the service provider may completely deny service from a client or censor specific transactions. In addition, it leaves open the following attack vector. Consider a client who is an organization with multiple authorized signers. Deploying a two-party signing protocol in that setting means duplicating the client share of the signing key among all authorized signers, while the service provider possesses the other share. Thus, it is sufficient for the service provider to collude with only a single member of the organization in order to steal all the client funds. These issues motivate the need for a decentralized service provider, meaning that the service provider share of the signing key is now shared among a network of n participants that emulate the operation of the provider. This, however, requires a distributed signing protocol for an access structure that is different than the usual threshold access structure known in the art. In the new access structure, half of the signing key is in possession of the client whereas the network, collectively, possesses the other half. To produce a signature, the client along with at least t + 1 honest parties must collaborate, keeping the client safe even in the extreme case that all network participants are compromised. In terms of security, a protocol must be proven secure under “universal composition (UC)” in order to be able to run it in parallel with many clients. Bourse et al. (Florian Bourse, Rafael Del Pino, Michele Minelli, and Hoeteck Wee. FHE Circuit Privacy Almost for Free. In Advances in Cryptology - CRYPTO 2016 - 36th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 14-18, 2016, Proceedings, Part II, volume 9815 of Lecture Notes in Computer Science, pages 62-89. Springer, 2016) addresses a similar access structure in the UC framework, however, since the parties must separately verify zero-knowledge proofs from each other party it cannot scale well for large networks.

[0040] Addressing that special access structure can take different approaches. For instance, one may model the client as n virtual parties, so its power is equal to that of the service provider, as described for example in Zyskind et al. (Guy Zyskind, Avishay Yanai, and Alex “Sandy” Pentland. Unstoppable wallets: Chain-assisted threshold ECDSA and its applications. IACR Cryptol. ePrint Arch., page 832, 2023). This approach incurs a high computation and communication complexity on the client, that is dependent on the network size. An alternative would be to use an hierarchical threshold secret sharing scheme with two levels of hierarchy - the client is at the top and the network participants are at the bottom such that reconstruction is possible only by a collaboration between the client and at least t + 1 network participants.

[0041] The disclosed embodiments relate to Universally Composable (UC)-secure large-scale threshold ECDSA protocols and introduce the notion of 2PC-MPC. Specifically, the client and each network participant possess only one share. However, in contrast to a hierarchical secret sharing scheme, the client is agnostic to the fact that it interacts with a distributed party. Instead, the client follows the protocol as if the client is interacting with a single party only (hence “2PC”), which is emulated by the network via a multiparty computation (MPC) protocol.

[0042] It is appreciated that the disclosed embodiments may overcome disadvantages of the prior art in several ways. The disclosed protocols are natively designed to use only a broadcast channel (for sending messages to multiple parties), which makes them inherently applicable to blockchain networks where direct communication channels between pairs of parties are not available. The disclosed protocols may be accompanied with a security proof via a UC simulation and hence match real world needs where a distributed service has to handle many clients concurrently.

[0043] The disclosed protocols may differ from existing protocols in at least two aspects. The first differing aspect is access structure. The disclosed protocols may address two access structures together. The first access structure is a two-level hierarchy, and captures the setting of 1 + n parties. The first party is alone at the top level and the other n parties are at the second level, such that a qualified set consists of the party at the first level together with any t + 1 parties from the second level. Thus, this structure can be referred to as “one plus t out of n”. When parties have voting powers, then t+1 of the voting powers (rather than of the parties) are required. The second access structure is the usual t out of n (‘threshold’) access structure. Our protocol for the latter is a byproduct of the former, such that taking the protocol for the first structure and ignoring the first party results in a usual (t, n) signature protocol. That is, a protocol may be designed without a client. The present disclosure is primarily focused on the first, hierarchical, access structure.

[0044] The second differing aspect is round complexity vs computational complexity. Each party needs to complete a communication round before continuing to the next round. The disclosed protocols may be optimized to minimize either a number of rounds or computational complexity. When optimized to the number of rounds, a three (3) rounds protocol is obtained, where presignature takes two rounds and the signature takes one round, matching that of existing protocols such as Doemer et al. The disclosed protocols build on a broadcast channel rather than P2P channels, which is leveraged to achieve identifiable abort. However, the number of expensive operations (exponentiations) to be done by each party is linear with the number of parties. The number of expensive operations can be reduced to practically constant when optimizing the protocol for computational complexity, thereby scaling to even thousands of participants becomes practical. This, however, is at the cost of increasing the number of communication rounds to seven (7), six of them for presignature.

[0045] Achieving 0(1) exponentiations per party is challenging and may be reflected in two contexts in the disclosed protocols: “threshold decryption” and “zero-knowledge proof verification”. Optimizing threshold decryption may be performed via an amortization technique that is applicable for batches of ciphertexts, even from different contexts (i.e., different signing sessions and different clients). This means that the parties can process a batch of n ciphertexts at the cost of 1, namely, each party only performs 0(1) exponentiations. Optimizing zero-knowledge verification may be done via novel aggregateable zero-knowledge proof systems designed for NP relations used in the disclosed protocols. These two optimizations, together with a careful protocol crafting, lead to a situation where the computation of each party is practically independent of the number of parties.

[0046] Addressing the aforementioned hierarchical access structure, the present disclosure introduces the concept of a “2PC-MPC threshold” ECDSA / Schnorr. In such a protocol, the user interacts with a network while being unaware of the topology, or even of the precise size of the network. From the user point of view it is interacting with a single party and hence its computation and communication overhead remains low. The network almost perfectly emulates the second party in a 2-out-of-2 ECDSA / Schnorr protocol (i.e., the user is the first party), where messages from the network participants are aggregated into a single message which is effectively the only one received and processed by the user. This feature is important in case the network operates as a blockchain, in which case a user cannot be expected to directly interact with the blockchain nodes, but rather the user broadcasts its messages to be processed by the blockchain and is notified whenever the blockchain has a response. Such a communication model may reduce the attack surface of the system in a real deployment, since the user is unaware of the identities of the participant endpoints over the network. Such a concept may pave the path to a topology hiding protocol, in which the network properties (e.g., size and topology) are hidden from the user.

[0047] A 2PC-MPC notion may include an access structure of t + 1-out-of-n, where a client is not aware of an internal structure of the distributed system communicated thereto, and from a perspective of the client, experiences a 2PC protocol. In particular, the communication complexity of the user is independent of n. In addition, for Class-Group based TAHE, where range proofs are redundant, the computation time is independent of n.

[0048] Aspects of the present disclosure may be used for a blockchain-based massively decentralized cryptosystem for securely maintaining digital wallets for any other blockchain. The blockchain may be permissionless, and before the beginning of every epoch, reconfiguration may allow for validators to join or leave the network. The blockchain may be based on a Proof of Stake (PoS), where each validator has a voting power proportional to its stake. In turn, at every reconfiguration validators may also withdraw part of their stake, or increase their stake, which could change their voting power accordingly. The term “blockchain” as used herein may also encompass variations, such as directed acrylic graphs (DAG)-based consensus platforms or blockchain-DAG hybrids. DAG-based designs may allow validators to propose blocks in parallel. This may improve “system latency”, i.e., the time to create a digital wallet or sign a transaction, as well as the “throughput”, i.e., the number of transactions or wallets produced per unit time. In every signing request, aggregation of the decryption shares may be considered a bottleneck, such that each validator can process decryption shares of a different subset of signing requests, amortizing this cost. Clients may communicate with the blockchain by sending transactions and reading blocks. MPC party emulation subprotocols may be implemented over a consensus channel used for producing blocks. A block proposer validator may be responsible for aggregating the last MPC round, computing the message to send to the client, and including it in its proposed block. Such a communication channel may be asynchronous or partially synchronous.

[0049] Upon creation, wallets may specify policies, either by using smart contracts implemented on-chain, or using light-clients in order to validate policies posted on another blockchain. Before validators participate in signing a transaction, they validate that it matches the policy of the corresponding wallet. Policies may specify, for example, a “whitelist” or a “blacklist” of accounts, a “transaction limit”, a limit on the number of transactions per epoch, or anything else that can be specified in a smart contract. Compromising a client may not allow an adversary to bypass the policy of its wallet. Compromising the blockchain may only be exploited to bypass policies for wallets for which the client share was also compromised. This may ensure that security can only be enhanced by sharing the key with the blockchain.

[0050] The present disclosure may be used in various applications.

[0051] One example is digital wallets for any blockchain. The address of a wallet is typically a hash of its public key. Therefore, public keys generated on a blockchain according to disclosed embodiments can be used as accounts on other blockchains (e.g., BitCoin or Ethereum®). A client can make a transaction by initiating a signing protocol with a blockchain according to disclosed embodiment. With this motivation in mind, protocols of the disclosed embodiments support both ECDSA (Elliptic Curve Digital Signature Algorithm) and EdDSA (Edwards-curve Digital Signature Algorithm) signatures, which may support a substantial majority of current blockchains. In one example, upon creation of a digital wallet on a first blockchain, a policy may be specified. The first blockchain may enforce the specified policy when using the digital wallet for the second blockchain participating in signing requests only on transactions that are valid with the specified policy. Another example is future transactions. A future transaction is a signed transaction published by some client, which is only executed when and if a certain predetermined condition is met. For instance, client A would send xAbitcoin to fund F when and if bitcoin (BTC) is worth < tBTCdollars. In aspects of the present disclosure, the user signing round sends an encryption of the signature, and therefore the blockchain has the capability of delaying transaction execution. For example, validators would send their decryption shares only when and if the condition is met.

[0052] A further example is bridging blockchains. An appealing private case of future transactions are bridges. Clients can transfer, for instance, BTC in exchange for Ether. Client A would send a future transaction transferring xABTC to liquidity pool P, and condition it on receiving at least yPEther from the liquidity pool. In this manner, blockchains can be bridged without relying on implementation of smart contracts or light-clients on either of them. This may allow for bridging BTC with other blockchains.

[0053] An additional example is recovery. Clients may produce a future transaction that transfers all of their funds and / or wallet to some other entity. This can be used for recovery of the wallet and its funds in case the client share of the key is lost or compromised. The condition for initiating this recovery transaction can be signing a transaction with another wallet whose client share is more protected, or a combination of signatures from a subset of white list wallets with a certain threshold, such as counting on “friends”.

[0054] Yet another example is wallet transfer. Wallets may have intrinsic value, similar to non-fiingible tokens (NFTs). Therefore, transferring ownership of a wallet can be of independent interest, and is not necessarily equivalent to transferring all of its funds. In aspects of the present disclosure, this may be achieved by transferring the client share, in a publicly verifiable manner. The blockchain can then associate the wallet with the receiver client.

[0055] Yet a further example is Decentralized Autonomous Organization (DAO). The “BIP32” standard enables deriving child keys from master keys, as in Xcfliid= a ■ Xparent+ b ■ G, for public values of a and b . Child keys may have less permissions than their parent key. For instance, the master key may be capable of updating the wallet policy, its child could transfer funds to any address up to a certain amount, and each of its children can transfer funds to certain whitelists of clients. It may be shown that for EdDSA (and Schnorr), protocols of the disclosed embodiments are compatible with the BIP32 standard, even with presigns. Specifically, by choosing tweaks (a, b) adaptively after observing the presigns, cannot be exploited by an adversary in order to forge signatures.

[0056] The disclosed embodiments may overcome disadvantages of the prior art by providing a 2PC- MPC protocol for a massively decentralized permissionless Proof-of-Stake (PoS) blockchain, servicing multiple clients concurrently to securely maintain and manage digital wallets for any blockchain. The number of secret shares a validator stores is proportional to its voting power, and is independent of the number of clients in the system. The disclosed embodiments include two reconfiguration protocols for redistribution of such shares. The network party may work over an asynchronous reliable broadcast channel, where the (valid) subset of participating parties in each MPC round is arbitrary and post-determined. This is on par with the asynchronous reliable broadcast channel used in blockchains, where in each round the subset of parties can arbitrarily change and is not known in advance. Protocols of the disclosed embodiments may support both ECDSA and EdDSA (Schnorr).

[0057] In terms of round complexity, the first (commitment) round of the client may be removed at the distributed key generation (DKG) phase, as well as at the “presign” phase of the signing protocol. As a result, both the DKG phase and sign phase may be a one-round trip between the blockchain and the client. The sign phase can be broken into a presign phase that can be executed before the message to be signed is decided, and an online-signing phase. When folded back to the standard threshold access structure (removing the client), DKG may be one-round for Schnorr and two-rounds for ECDSA, and sign may be a single round.

[0058] In addition, the disclosed embodiments may alleviate the need for zero-knowledge proofs toward the client. In existing protocols, the client verifies proofs from the blockchain, which therefore must be aggregated, to form proofs over aggregated statements. The intuition is that the client behaves as a signing oracle with its secret key share, and therefore even when operating on maliciously generated messages from the blockchain, the transcript cannot be exploited to forge signatures. Although this may lead to vulnerabilities, the disclosed embodiments may provide for optimization and UC-simulation, which may dramatically reduce the round complexity compared to existing protocols, such as those in which proof aggregation requires three rounds.

[0059] Protocols of the disclosed embodiments may be proven secure in a UC-framework, and realize the standard threshold signing functionality. The protocols may be simulated with black-box access to carefully chosen signing oracles. The signing oracles may be less strict than expected, such that the simulation of disclosed asynchronous protocols may be intuitive. On the other hand, the unforgeability with respect to the signing oracles may be reduced to well-known hardness assumptions. Specifically, forging the slightly-enhanced Schnorr signing oracle may reduce to breaking Algebraic One-More Discrete Log (AOMDL), and forging the slightly-enhanced ECDSA signing oracle may be proven secure in the Elliptic Curve Generic Group Model (EC-GGM). Notably, disclosed protocols may circumvent the need to assume Enhanced-ECDSA unforgeability, which is proven in EC-GGM up to q1^3. which may not suffice when working over a 256-bit elliptic curves. Instead, the disclosed EC-GGM reduction may suggest security up to q1 / 2, which is on-par with security of standard assumptions over elliptic curves (e.g., discrete logs).

[0060] For Schnorr signatures, the presign is client independent. In other words, the presign message does not depend on the blockchain secret key share of some wallet. The present disclosure may prove that presigns can be generated off-line in a common pool shared with all clients in the network. Upon signing, clients could use the same pool of presigns to sign transactions. This may save the cost of generating presigns for wallets that are abandoned, and allows the system to prepare for critical points from being overloaded. The slightly-enhanced Schorr signing oracle of the disclosed embodiments may allow the adversary to ask for an arbitrary number of keys and presigns, and adaptively choose the key-presign-message binding in parallel for all signing requests to follow. The disclosed protocols may support the BIP32 standard and allow adding tweaks in the signing phase for the public key. Despite all the signing freedom given to the adversary, breaking the signing oracle may be reduced to AOMDL. It is appreciated that the term “Schnorr” or references to a “Schnorr signature” or “Schnorr algorithm” herein may also encompass variations to Schnorr signature schemes, including but not limited to an Edwards-curve Digital Signature Algorithm (EdDSA) digital signature scheme.

[0061] The phrase “a threshold of parties” or variations thereof as used herein may further encompass instances of “a threshold of voting power” of parties.

[0062] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the specification and claims and should not be interpreted in an idealized or overly formal sense unless expressly so defined herein. Well-known functions or constructions may not be described in detail for brevity and / or clarity.

[0063] It will be understood that, although the terms first, second, etc., may be used herein to describe various elements, components, regions, layers and / or sections, these elements, components, regions, layers and / or sections should not be limited by these terms. Rather, these terms are only used to distinguish one element, component, region, layer and / or section, from another element, component, region, layer and / or section.

[0064] It will be understood that when an element is referred to as being “on”, “attached” to, “operatively coupled” to, “operatively linked” to, “operatively engaged” with, “connected” to, “coupled” with, “contacting”, “added to, another element, it can be directly on, attached to, connected to, operatively coupled to, operatively engaged with, coupled with, added to, and / or contacting the other element or intervening elements can also be present. In contrast, when an element is referred to as being “directly contacting” another element or “directly added” to another element, there are no intervening elements and / or steps present.

[0065] Whenever the term “about” or “approximately” is used, it is meant to refer to a measurable value such as an amount, a temporal duration, and the like, and is meant to encompass variations (e.g., ±20%, ±10%, ±5%, ±1%, ±0.1%) from the specified value, as such variations are appropriate to perform the disclosed methods.

[0066] Certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

[0067] Whenever terms “plurality” and “a plurality” are used it is meant to include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. The term set when used herein may include one or more items. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

[0068] Throughout, this disclosure mentions “disclosed embodiments”, “disclosed systems” and “disclosed methods”, which refer to examples of inventive ideas, concepts, and / or manifestations described herein. The fact that some disclosed embodiments are described as exhibiting a feature or characteristic does not mean that other disclosed embodiments necessarily share that feature or characteristic.

[0069] This disclosure employs open-ended permissive language, indicating for example, that some embodiments “may” employ, involve, or include specific features. The use of the term “may” and other open-ended terminology is intended to indicate that although not every embodiment may employ the specific disclosed feature, at least one embodiment employs the specific disclosed feature.

[0070] The term “user” is used herein to refer to any individual person or group of persons using or operating a method or system of a disclosed embodiment.

[0071] Notation

[0072] Throughout the present disclosure, group elements and sets are denoted by uppercase (large) letters while field elements are typically denoted by lowercase (small) letters. Algorithms are denoted by calligraphic uppercase letters. Message identifiers may be denoted in a sans-serif font (identifier). Subscripts are usually reserved for descriptors, and superscripts are used for indexing. In cases where only a descriptor or only an index are needed it will be subscripted. For a finite set A. the notation: x «- A implies that x is sampled uniformly at random from A. The notation x «- A may also indicate the output of an algorithm. The notation (^) denotes all the subsets of B of size t.

[0073] The disclosure relates to the ideal functionalities Bbroadcast, -^global-broadcast representing two modes of communication used in the disclosed protocols. One mode is an internal communication happening inside the distributed entity B and global communication in which B is presented as a single entity communicating with another of parties A .

[0074] Definition: "Internal Broadcast Functionality ^broadcast”-

[0075] The functionality interacts with a set of parties B and an adversary c / Z.

[0076] • Upon receiving (broadcast, sid, i, msg) send (broadcast, sid, i, msg) to <£. and record.

[0077] • Upon receiving (req-output, sid, i,j) from <£. check if (broadcast, sid, i, msg) was recorded, if so send (broadcast, sid, i, msg) to Bj.

[0078] Definition:

[0079] The functionality interacts with two sets of parties A = [ApidAj. B = {BJiefn] and an adversary cA. • Upon receiving (global-broadcast, sid, i, msg) send

[0080] (global-broadcast, sid, i, msg) to c / Z and record.

[0081] • Upon receiving (req-output, sid) from c / Z check if (broadcast, sid, i, msg) was recorded for some i G B, if so send (global-broadcast, sid, i, msg) to all parties in A.

[0082] ^global-broadcastseemsalmost identical to ^broadcast, however the receiver does not obtain information on the sender among the parties in B and thus sees them as a single entity.

[0083] Another difficulty which arises in an asynchronous model is agreeing upon a subset that has sent valid messages and that has been received by enough parties to continue the execution. Furthermore, an adversary may have some effect on this chosen subset. This is modelled by the ideal functionality T"ACS. defined as follows:

[0084] Definition: “Asynchronous Common Subset Functionality .

[0085] The functionality interacts with a set of parties B = {BJiefn] and an adversary c / Z controlling a subset UBc B of the parties. It is parameterized by a set of legal subsets SBc 2B..

[0086] • Upon receiving (validate, sid, i,j) from Bbrecord and send (validate, sid, i,j) to c / Z.

[0087] • Upon receiving (req-output, sid, i, SB) from c / Z the functionality does as follows: o Check if it has recorded (authorized-subset, sid, S'B) for S'BSB. If so, ignore the message o Check that VBy G SBit has a record (validate, sid, i,j) and that SBG SB. If record (authorized-subset, sid, SB) and outputs

[0088] (authorized-subset, sid, SB) to B, . Else it ignores the message.

[0089] Definition: “Aggregation Protocol

[0090] The protocol interacts with a set of parties B = {Bj}je[n]- It is parameterized by an access structure IBc 2Balong with a Maurer language L. Each party B, holds a tuple (Ybviy) G L.

[0091] • Each Bi does as follows:

[0092] 1. Run a ZK protocol [^(Yp Wi) generating a proof nt. Send (broadcast, sid, i(proof, Ybto ?broadcast.

[0093] 2. Upon receiving (broadcast, sid, i(proof, Yj, Tij')} verify the proof iij. If the proof verifies then send (validate, sid, i,j) to PAcs- else consider Bj as malicious.

[0094] 3. Receive (authorized-subset, sid, SB) from tFACSoutput •

[0095] A Shamir secret sharing scheme presented over a finite field is known in the art. But in some use cases, such as when working over a group of unknown order, it is necessary for the sharing to be correct over the integers.

[0096] Definition: “Shamir Secret Sharing Over the Integers”. Let s G 2 A [— b, b] be a secret. Define An= n! and define some bound / (a, n, b) on the absolute value of the coefficients of the polynomial. The algorithm Sharet„(s) picks alt••• , at<- [— I(o, n, b), I(o, n, b)] and outputs ([s]1;••• , [s]n) where [s]7- = p(J) and p(x) = An■ s +Z 'ti=1aixl. Reconstruction works as follows: Given a set S G then p(0) = AQ7[S]7- = A„s. where is the Lagrange coefficient corresponding to the interpolation of the point i with the point j using the subset S. However, since the Lagrange coefficients might not be integers, they are first multiplied by A„ to obtain:

[0097] X jeS A), / [s] j

[0098] A2= S

[0099] For a t-out-of-n, the upper bound on the absolute value of the share on s is denoted by D (a, n, t, b) .

[0100] Definition: “Additively Homomorphic Encryption (AHE)”.

[0101] An additively homomorphic encryption scheme is associated with an ensemble {%K}Kand consists of four polynomial time algorithms AHE = (Gen, Enc, Dec, Add), specified as follows:

[0102] • Gen(lK, aux) -> (pk; sk) A probabilistic algorithm that is given a security parameter 1Kand possibly some auxiliary information aux and samples a key pair (pk; sk) from %K. The following assumes that the resulting pk contains the description of the security parameter 1K, the auxiliary information aux, as well as the plaintext, randomness and ciphertext spaces Ppk, Rpk, Cpk. respectively, where Ppkis a Z-module. In addition, for the present disclosure an AHE scheme is associated with a language icenAHEW={pk; aux | (pk; sk) = Gen(lK, aux)} that expresses the fact that pk was generated correctly.

[0103] • Enc(pk, pt; rjenc) -> ct. A deterministic algorithm that on input a public key pk, a plaintext pt G Ppk. and a randomness rjencG Rpk, outputs a ciphertext ct G (?pfe. Enc(pk, pt) is defined as a probabilistic algorithm that first universally samples r]encG Rpkand then outputs ct' = Enc(pk, pt; ?7enc) G Cpk.

[0104] • Dec(sk, ct) -> pt. A deterministic algorithm that on input a secret key sk and a ciphertext ct G Cpk. outputs a plaintext pt G Ppk.

[0105] • Add(pk, ct1;ct2) -> ct3. A deterministic algorithm that on input a public key pk and two ciphertexts ctpct2G Cpk. outputs a ciphertext ct3G Cpk. such that if ctx= Enc(pk, r]^ and ct2= Enc(pk, m2; r]2) then ct3= Enc(pk, m1+ m2; rj1+ ??2), where + m2and r / i + r / 2are over Ppkand respectively. Imposing correctness will ensure that Add is a homomorphic addition. It is noted that efficient homomorphic scalar multiplication is implied by the Add operation (e.g., via double-and-add).

[0106] In addition, a homomorphic addition of two ciphertexts ctxand ct2is denoted by ctx® ct2, and a multiplication of a ciphertext ct by a scalar a is denoted by a O ct.

[0107] Every affine function can be efficiently computed homomorphically by an algorithm Eval(pk, f, ct1;••• , ctf; 77eva|). Whenever the randomness in Eval(pk, f, ct1;••• , ctf) is omitted, one refers to the process of sampling a randomness ??eva| «- {0,l}poly^ and running Eval(pk, f, ct1;••• , ctf; ??eval). Given a public key pk, an affine function f(xr, ••• , x{) = a0+ £f=1djXj (with dj e Z and ■£, || a, ||2e poly( / c) for all 0 < i < ■£) and ■£ ciphertexts ct1;••• , ct£e 3?pfe, Eval outputs a ciphertext ct.

[0108] Definition: “AHE correctness”.

[0109] AHE is correct if for every K, every t G poly( / c), every Z’-ary affine function f as above, and every plaintext pt1;••• , pttG Ppk.

[0110] Pr [Dec (sk, Eval(p / c, f, (ct1;••• , cG))) = / (pt1;••• , pG)] > 1 — neg( / c), where (pk, sk) «- Gen(lK) and ct; «- Enc(pk, pt;), and the probability is over the coins used by the algorithms Gen, Enc and Eval.

[0111] For correctness, algorithm Eval may simply output ct = Enc(p / c, a0) ®f=1a, O ct;. However, such as algorithm may not satisfy secure function evaluation.

[0112] Definition: “AHE semantic security”.

[0113] AHE is semantically secure if for every PPT adversary c / Z there exists a PPT algorithm 5 such that for every pair of PPTs f; h: {0,1}* -> {0,1}*, and every pt G !Ppk:

[0114] |Pr [c / Z (lK,Enc(pk, pt), l'pt', h(lK, pt)) = f(lK, pt)]

[0115] — Pr [ 5 (1K, llptl, h(lK, pt)) = f(lK, Pt)j | < neg( / c) where (pk, sk) «- Gen(lK) and h refers to the auxiliary information function in possession of the adversary. The probability is over the random coins of Gen and Enc.

[0116] Definition: “Secure Function Evaluation”.

[0117] AHE has secure function evaluation if there exists a PPT algorithm £Evalsuch that for every PPT adversary c / Z, every Gary affine function f as above, every (pk, sk) and every plaintext pt2, -" , pG G J’pfc, and randomness rp,

[0118] |Pr [c / Z (lK,pk, sk, {pt£; i?;}f=1,Eval(pk, f, (ct1;••• , ctj)) = 1]

[0119] - Pr [ c / Z (lK,pk, sk, {pt;; ?7i}f=1, SEvai(pk, f, (PG, - , PG))) = 1] | < neg(tf) where ct; «- Enc(pk, pt; ; ??;), and the probability is over the coins used by Eval and the random coins of c / Z and <S\

[0120] A TAHE scheme is defined be a tuple of algorithms (Gen, Enc, Add, TDec, Rec). Gen, Enc, Add works similarly to the definition of AHE, while TDec (threshold decryption) is an operation that each party runs locally on the ciphertext and generates a decryption share. Collecting t + 1 such decryption shares as inputs to Rec outputs a correct decryption.

[0121] Definition: “Threshold additively homomorphic encryption (TAHE)”. Threshold additively homomorphic encryption is associated with an ensemble {KK}Kand consists of five polynomial time algorithms TAHE=(Gen, Enc, Add, TDec, Rec) specified as follows:

[0122] • Gen(lK, i, t, n, aux) -> (p / c, sk^). A probabilistic (possibly interactive) protocol that is given a security parameter 1K, the number of parties n, a threshold 1 < t < n and possibly some auxiliary information aux and samples a keypair (p / c, {sk}je[n] )eKK. In the following, it is assumed that the resulting pk contains the description of the security parameter 1K, the auxiliary information aux, as well as the plaintext, randomness and ciphertext spaces Ppk> Rpk> Cpk, respectively, where tPpk is a 1-module.

[0123] • Enc(p / c, pt; penc)- A deterministic algorithm that on input a public key pk, a plaintext pt G Ppk, and randomness pencG 3?pfe, outputs a ciphertext ct G Cpk. Enc(pk, pt) is defined as a probabilistic algorithm that first uniformly samples penc«- tRpkand then outputs ct = Enc(pk, pt; penc) G Cpk.

[0124] • TDec(sk;, ct) -> cti. A deterministic algorithm that on input a secret key share sktand a ciphertext ct G Cpkoutputs a decryption share ct, G Cpk.

[0125] • Rec(S, {ct; }i6S) -> pt. A deterministic algorithm that on input of a set S G ( ) and a tuple of elements {ctiJieseCpk outputs a plaintext pt G Ppk.

[0126] • Add(p / c, ct1;ct2) -> ct3. A deterministic algorithm that on input a public key pk and two ciphertexts ct1;ct2G Cpkoutputs a ciphertext ct3G Cpk.

[0127] Definition: “TAHE correctness”.

[0128] TAHE is correct if for every K, every t G poly( / c), every -f-ary affine function f, any subset S G and every plaintext pt1;••• , pttG Ppk,

[0129] Pr [Rec (s, [TDec [[sk]itEval(pk, f , (ctr, --- , ctf)))j ) = / (pt1;••• , ptf)j > 1 — neg( / c) where (pk, {[skJihefn]) Gen(lK) and ct; «- Enc(pk, ptj), and the probability is over the coins used by the algorithms Gen, Enc and Eval.

[0130] A TAHE functionality ETAHEis defined below. Let B = {B1;• • • , Bn} be a set of parties and U c B, where | U | < t < n, be those parties under the control of the adversary. The TAHE functionality ?TAHE is parameterized with an AHE scheme AHE=(Gen, Enc, Dec, Add) with semantic security and secure function evaluation. The parties in B can generate a key and prove its validity to the certifiers. In the context of the disclosed 2PC-MPC protocol, the certifiers are the users (represent by client A) who engage with B. Finally, any set of t + 1 honest parties can decrypt a ciphertext using a previously generated key, unless the adversary decides to abort.

[0131] Definition: “TAHE functionality ETAHE The functionality interacts with B = (B1;• • • , B„). an adversary that statically corrupts a subset 11 of the parties and a set of certifiers. It is parameterized with AHE=(Gen, Enc, Dec, Add), K and t < n.

[0132] • Upon receiving {keygen, sid) from all parties in B, for a fresh sid, run (p / c; sk) <- AHE. Gen(lK). send pk to the adversary and receive the adversary response {continue , 11') . If continue = 1 or 11' n 11 = 0 then send {pubkey, sid, pk) to all parties in B and store {sid, pk; sk) , otherwise send {pubkey, sid, 1, 11' D 11) .

[0133] • Upon receiving {certify, pk) from some party, if (■, pk; ■) is stored then return 1 to that party, otherwise return 0.

[0134] • Upon receiving {decrypt, pk, ct) from at least t + 1 parties, if {sid, pk; sk) is stored for some sid and sk, compute pt = AHE.Dec(s / c, ct) , send {decrypted, pk, ct, pt) to the adversary and wait to the adversary response {continue, 11') . If continue = 1 or 11' D 11 = 0 then send {decrypted, pk, ct, pt) to everyone, otherwise send {decrypted, pk, ct, 1,11' n 11) to everyone.

[0135] Realization of a TAHE functionality ETAHEis done using a tuple of protocols (Gen, Enc, Add, TDec, Rec). The (Gen, Enc, Add) protocols are similar to a standard AHE, while TDec is an operation that each party runs locally on a ciphertext and generates a decryption share. Collecting t + 1 such decryption shares as inputs to Rec outputs a correct decryption. Since the TDec operation is local, typically one must add a ZK proof that this was done correctly and verify all proofs before applying Rec to them. Verifying these proofs, especially when the number of parties (hence t) is large, can dominate the protocol runtime. In addition, the combination in Rec itself may be very expensive, especially when the plaintext space is of unknown order and so the secret decryption key is shared over the integers (as in a Paillier scheme). One possible optimization is for one party to locally compute Rec and provide a proof of correct recombination. Unfortunately, generation and verification of such proofs may not be efficient in general. But in a case where encryption is of a signature, one may verify the correctness by verifying the signature.

[0136] Definition: “Dynamical TAHE”

[0137] In the disclosed protocols, the parties need to be able to re-share their secret keys such that the distribution of the secret keys represent their current stake in the blockchain. To this end, the TAHE may also include a reconfiguration protocol: ReConf(lK, I"7, t, t' , n, n',pk,aux, [sk]j) , which is a probabilistic (possibly interactive) protocol that is given a security parameter 1K, a statistical security parameter l'7, the initial threshold t, the final threshold t', the initial number of parties n, possibly some auxiliary information aux , and the output (AHE, [sk],) of the protocol. A DTAHE is considered secure if it realizes the ideal functionality defined below:

[0138] Definition: “Dynamical Access Structure AHE Version 2: ?DAHE”

[0139] The functionality interacts with a set of parties B = {B1, --- , Bn) and an adversary controlling a subset U Z? . It is parameterized with an AHE=(Gen, Enc, Dec, Add) along with an initial access Structure 1'keygen- 1. Key Generation: Upon receiving (keygen, pid, sid) from a subset SkeygenG Ykeygenfrom a fresh sid, run (pk; sk) «- AHE.Gen(lK), send pk to the adversary and receive the adversary response (continue, [ / ') . If U Cl U' = 0 then send (pubkey, sid, pk) to all parties in B, define T = rfeeyflenand store (access — structure, sid, T) to memory, otherwise send (pubkey, sid, 1, U Cl I / ') to all parties in B.

[0140] 2. Decryption: Upon receiving a (decrypt, pid, sid, ct) let Sdecrypt,sid,ct= Sdecrypt,sid,ctU {pid} (if no request was recorded yet treat •S‘decrypt,sid,ctas the empty set) and do the following:

[0141] (a) Check if (decrypted, sid, ct, pid) in memory else calculate pt «-

[0142] AHE.Dec(pk,ct; sk) and store (decrypted, sid, ct, pid) to memory.

[0143] (b) Check if S,decrypt sid ctU U G T for (access — structure, sid, T) in memory, if true send (decrypted, sid, ct, pid) to U.

[0144] (c) Check if Sdecrypt;Sid ctG P for (access — structure, sid, T), if true send (decrypted, pk,ct, pt) to the adversary and wait for the adversary response (continue, U”') if U Cl U" = 0 send (decrypted, sid, ct, pt) to everyone, otherwise send (decrypted, pk, 1, U Cl [ / ") .

[0145] 3. Reconfiguration: Upon receiving (re-configure,pid,sid, T') from a subset S G T, delete (re-configure,sid, T) and store (re-configure,sid, T') instead. Furthermore, delete any message titled decrypt or decrypted along with the sets 5decrypt;Sid ct.

[0146] The language associated with relation R is the set LR= {x | Bw : (x, w) G R}. L [params] = {S; s | / (params, S, s)} denotes a language {x | 3s : / (params, S, s) = 1}, where params typically refers to global parameters (e.g., a public key of an encryption scheme, or a global verification key), S refers to a set of public values, and s refers to a set of secret values. Note that PzRkimplicitly requires knowledge of the witness s from the prover P. Note that params may be omitted from a language specification when it is clear from context. The disclosed protocols may include the following languages:

[0147] • Knowledge of the discrete log of an elliptic-curve point:

[0148] LDL[((G, 6, q)] = {(?; %) | P = x ■ G}.

[0149] • Knowledge of decommitment:

[0150] • Knowledge of plaintext:

[0151] Lpt[AHE, pk]

[0152] If ct is a vector then interpret the language as proving knowledge of plaintext for each element in the vector.

[0153] • Commitment of discrete log: Vector Commitment of discrete log:

[0154] • Equality between two commitments with different public parameters:

[0155] • Committed affine evaluation:

[0156] ^DComEvai[pP<P^<ctq, s, K] = {ctEval, C; a; p, o), p | ctEval= AHE. Eval (p / c, / a(x),ct; q) A C = Compp(u; p) A a{e [0, q) A p e 7?ppA p e 7?pk}.

[0157] • AHE encryption of a discrete log:

[0158] ^EncDLtP^C^ G, <?)]={(ct, X; x, p) | ct = AHE.Enc(p / c, x; p) A X = x ■ G A x E [0, q)}.

[0159] • AHE scaling of a discrete log: hscaieDLtP^-C^ G, Q)> ct0]={(ct1;x> q) | ct = AHE. Scale (pk, ct0, x; p) / \ X = x ■ G / \ x E [0, <?)}•

[0160] • AHE analog of a DH tuple, namely ciphertexts of values ctz=AHE. Eval (pk, f, ctx; 0; pz~) s. t. f(x) = y ■ x mod q A y e [0, q)}.

[0161] • Correct AHE key generation:

[0162] All languages can be extended to include range claims, which may be done by adding range to the name of the language and including a vector representing the bounds on the witnesses.

[0163] A Publicly Verifiable Secret Sharing (PVSS) allows a dealer to share a secret among a set of recipients for some monotone access structure, while any recipient can verify the correctness of the shares of every other recipient without further communication. Typically, this is achieved by the dealer generating encryptions under public keys of each recipient while proving using a Non-Interactive Zero-Knowledge proof that the sharing was done correctly. A main advantage of the aforementioned approach is that it prevents the need for a complicated and communication complex accountability mechanism in case a recipient claim they received a wrong share.

[0164] Definition: “Publicly Verifiable Secret Sharing (PVSS)”

[0165] A PVSS scheme consists of the following algorithms:

[0166] • Setup: o pp <- Setup(lK,ip) outputs public parameters pp. The initial parameters ip contain information about the number of parties, privacy and Reconstruction thresholds and spaces of secrets and shares. The public parameters include a description of the key space %K, which should be thought of as a Cartesian product over the public key share and the private key share along with some relation they satisfy. o (pkj, nplk; skj) «- Gen(pp, j) where (pk; sk) e %Kand npkis a proof meant to assert that pk is a valid public key. o 0 / 1 «- Verify(pp,j, pky, np}k), a verification algorithm forthe proof

[0167] • Distribution: ({ctj }je[n]<nshare) Dist(pp, {pk}^^], s), where s e 5 is avalid secret, outputs “encrypted shares” ct,. and a proof that they are correct nshare.

[0168] • Distribution Verification: 0 / 1 <- VerifySharing(pp, {pk;, ctJieMi7rsftare), a verification algorithm for nshare.

[0169] • Reconstruction: o «- DecShare(pp, pkj, skj, ctj) outputs a decrypted share [s]j and a proof nDecof correct decryption. o (s') <- Rec(pp, {[s]j}jes) either returns abort if S g T or an element of the secret space s' e 5 if S e T.

[0170] • Reconstruction Verification: 0 / 1 «- VerifyDec(pp, pkj, ct,, [s]j, nDlec), a verification algorithm for nDlec.

[0171] Reference is made to Figure 1, which is a schematic illustration of a system 100 for generating a digital signature, constructed and operative in accordance with an embodiment of the present disclosure. System 100 includes a decentralized network (DN) 105 and a plurality of clients 210 (X1;••• An). Decentralized network 105 includes a plurality of parties 110 (B1, ••• Bn). Each party (Bi) has a respective voting power (VPi). Parties 110 are communicatively coupled with one another, such that each party 110 may receive and transmit messages or information to another party 110. Each client 210 may receive and transmit messages to or from at least one other party. In the example configuration depicted in Fig. 1, client 1 is communicatively coupled with party 1; each of client 2 and client 3 is communicatively coupled with party 3, and client 4 is communicatively coupled with each of party 2 and party 4.

[0172] Reference is made to Figures 2 and 3. Figure 2 is a schematic illustration of a decentralized network party 110 of system 100, constructed and operative in accordance with an embodiment of the present disclosure. Figure 3 is a schematic illustration of a client 210 of system 100, constructed and operative in accordance with an embodiment of the present disclosure. Each of decentralized network (DN) party 110 and client 210 may be implemented in several ways, such as for example as an integrated circuit, and / or an embedded software, application, module, process or subsystem of a computer, and may be used as part of one or more tools or activities over the Internet or an intranet. In one example, party 110 and client 210 are respectively embodied by an integrated circuit (IC) or system on chip (SOC) 120, 220 of a computing device, such as a smartphone, a laptop computer, a mobile computer, a tablet computer, a wearable computer, or any type of electronic device with computing and processing capabilities. It should be noted, however, that the present invention is not limited to the described embodiments and can be used in any system where digital signature generation may be implemented. SOC 120 of party 110 includes on-chip components, including a processor 122, a memory 124, a communication interface 126, and a plurality of DN party modules 130, which are interconnected or communicatively coupled via a bus 128. Similarly, SOC 220 of client 210 includes on-chip components, including a processor 222, a memory 224, a communication interface 226, and a plurality of client modules 230, which are interconnected or communicatively coupled via a bus 228. Processor 122, 222 performs data processing and may receive instructions or information from other components of SOC 120, 220. Memory 124, 224 is configured for data storage. Communication interface 126, 226 may transmit information to and / or receive information from an external source, such as one or more data networks, using any suitable communication channel or network model and data transmission protocol. Information may be conveyed between the components of respective SOC 120, 220 over bus 128, 228.

[0173] DN party modules 130 includes a network distributed key generation (DKG) module 140, a network ECDSA / Schnorr presign module 150, a network Schnorr presign module 155, a network ECDSA sign module 160, a network Schnorr sign module 165, a network dynamic threshold additively homomorphic encryption (DTAHE) module 170, and an ownership transfer verification module 180. Network DTAHE module 170 includes a network reconfiguration (reconfig) module 175. Client modules 230 includes a client distributed key generation (DKG) module 240, a client ECDSA / Schnorr presign module 250, a client Schnorr presign module 255, a client ECDSA sign module 260, a client Schnorr sign module 265, a client DTAHE module 270, and a client ownership transfer module 280. DN party modules 130 and client modules 230 are configured to execute cryptographic operations or protocols, such as by applying one or more mathematical operations, equations and / or processes on variables or input data, which may result in corresponding output data. Such cryptographic operations may include processes relating to digital signature generation, such as distributed key generation, pre-signature, signature, encryption, and decryption processes. Processing associated with DN party modules 130 may be implemented at least in part using network processor 122, while associated with client modules 230 may be implemented at least in part using client processor 222. It is noted that the functionality of DN party 110 may be implemented as a stand-alone network party module 130 but is described in Fig. 2 as part of an SOC 120. Similarly, the functionality of client 210 may be implemented as a stand-alone client module 230 but is described in Fig. 3 as part of an SOC 220. In embodiments, the functionality of one or more DN party modules 130 may be implemented in hardware, software, firmware, or a combination thereof.

[0174] DN party modules 130 and client modules 240 may be communicatively coupled through at least one communication network, and may be executed by one or more devices or components, each of which may reside at a respective location. Accordingly, information may be conveyed between the respective modules over the communication network as well as to / from other networks communicatively coupled thereto, via any suitable data communication channel or network, using any suitable channel or network model and any suitable data transmission protocol, such as via a secured communication protocol. For example, a client key generation may be implemented by a client DKG module 240 executing in a cloud server using a cloud computing platform.

[0175] The components and devices of system 100 may be based in hardware, software, or combinations thereof. It is appreciated that the functionality associated with each of the devices or components of system 100 may be distributed among multiple devices or components, which may reside at a single location or at multiple locations. For example, the functionality associated with processor 122, 222 may be distributed between a single processing unit or multiple processing units, including different types of processing units. Furthermore, at least part of the functionality associated with party 110 and / or client 210 may reside externally to SOC 120 or SOC 220. For example, the functionality of at least one of DN party modules 130 may operate at least partially on SOC 120 (e.g., using processor 122) and at least partially on a server or remote computer system accessible over a communications network, such as a cloud computing server. System 100 may optionally include and / or be associated with additional components or modules not shown in Figures 1, 2, 3 for enabling the implementation of the disclosed subject matter.

[0176] System 100 is generally configured for securely generating a digital signature. A digital signature scheme includes a key generation routine, a signing routine, and a signature verification routine. In turn, system 100 implements a secure distributed key generation protocol, a secure distributed signing protocol, and an optional secure distributed pre-signing protocol. A key generation routine outputs a private key and a corresponding public key, where the private key is selected from a set of possible private keys. System 100 implements key generation securely by implementing a distributed key generation (DKG) protocol, in which multiple parties contribute to the generation of a shared secret key. A DKG protocol does not rely on a trusted third party, but rather a threshold of honest parties determines whether a public and private key set can be computed successfully.

[0177] In accordance with a 2PC-MPC protocol of the disclosed embodiments, there are n independent parties ••• Bnthat together emulate a single party B interacting with a client A. When party B is distributed, all secret values of B are distributed as well. In particular, the AHE private key sk should also be shared amongst the parties B1, --- Bn. This leads to the definition of a threshold parameter t < n, and the assumption that an adversary may corrupt at most t parties out of Blt••• Bn. A UC-secure protocol for threshold AHE key generation and threshold decryption may be used as an instantiation.

[0178] The protocols of the present disclosure, including DKG, signing, and pre-signing protocols, may be based on threshold additively homomorphic encryption (TAHE). In one example, TAHE may be a dynamic TAHE (DTAHE) to allow for changing voting powers of parties.

[0179] Reference is made to Figure 4, which is a schematic illustration of a threshold additively homomorphic encryption (TAHE) distributed key generation (DKG) process, operative in accordance with an embodiment of the present disclosure. A TAHE-DKG routine is implemented by one or more parties 110 of decentralized network 105, for generating keys of a TAHE. Network DKG module 140 of a respective party (B,) implements a TAHE-DKG protocol to produce a respective secret private key (s / q) for each party, verification keys (vk) for all parties, a public key (pk), an optional evaluation key (evk), and an optional encryption of the secret key (ctsfe) . For example, network DKG module 140 implements Gen(lK, i, t, n, aux) -> (pk, ski) described previously (where pk may include vk, evk, ctsk)

[0180] In permissionless blockchains, voting power refers to the weight that a validator has in the consensus process, which is used to validate transactions and add new blocks to the blockchain. In Proof of Stake (PoS) blockchains, voting power is proportional to the amount of cryptocurrency that a participant has staked or locked up in the network. Validators are chosen to propose and validate new blocks based on the amount of staked coins they hold, meaning the more they stake, the higher the voting power. Reconfiguration may allow validators to join or leave the network, and validators may also withdraw part of their stake or increase their stake, which could change their voting power accordingly.

[0181] Reference is made to Figure 5, which is a schematic illustration of exemplary secret key shares of a decentralized network party with a given voting power, operative in accordance with an embodiment of the present disclosure. The number of shares of each party 110 is proportional to its voting power (VPj). Accordingly, as the voting power of a party increases so does the number of its secret key shares. For example, Party 1 produces a secret key (sk1) that is proportional to its voting power

[0182] The voting power of a party may be changed, when the protocols are based on a DTAHE. Reference is made to Figure 6, which is a schematic illustration of a network reconfiguration process, operative in accordance with an embodiment of the present disclosure.

[0183] In the example configuration depicted in Fig. 6, the voting power of Party 1 is changed from VP4to VPf, where AFPx > 0, such that the Party 1 increases its voting power (i.e., VPf > VPff The voting power of Party 2 is changed from VP2to VP2', where AVP2< 0, such that Party 2 decreases its voting power (i.e., VP2' < VP2). The voting power of Party 3 is changed from VP3to VP3’, where AFP3= — VP3, such that Party 3 remains with a voting power of 0 and no longer has any secret shares or voting power. Party 4 starts off with no voting power and no secret key shares (i.e., VP4= 0), and has its voting power increased to provide it with new secret key shares (i.e., FP4' = AFP4). Following the reconfiguration, each party obtains a secret key share in accordance with its new voting power: Party 1 generates skf based on VP / ; Party 2 generates sk2' based on VPf: Party 4 generates sk4' based on VPf: and Party 3 does not generate a secret key share (since VP3 = 0).

[0184] In one example the reconfiguration protocol uses an encryption of the secret key (ctsk) parameter generated by the DTAHE-DKG protocol, and in another example the reconfiguration protocol does not use ctsk. The first example also supports changing the threshold. This can potentially be used to adjust the resolution of the voting power distribution.

[0185] The following describes a reconfiguration protocol that uses ctsk.

[0186] Definition: “Reconfiguration Protocol with Varying Threshold”

[0187] (Re-Configu nration with Varying Threhsold var-th

[0188] : Re-conf igure(T AH E, PVSS, 1K, If t, t', n, n'))

[0189] Reconfigure

[0190] Reconfiguration Protocol with Varying Threshold is parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme PVSS, a computational security parameter K. a statistical security parameter a. an initial threshold t and a final threshold t'. The protocol interacts with a transferring quorum B = {Bjhefn] and a receiving quorum The transferring quorum holds a t-out-of-n secret sharing [sk] , on the secret key of the TAHE sk. Both quorums hold a public key pk to the encryption scheme, the verification keys of the transferring quorum {vk, }je[n] along with an encryption ofthe secret key ctsk= EnCpk(sk; 77). The protocol outputs a fresh t'-out-of-n' secret shares [sk] j, on the secret key sk held by B' and public verification keys {vk' i,}ue[nq corresponding to the shares. It is assumed that when the protocol begins the parties already executed the PVSS.Setup and PVSS.Gen successfully, and as such holds appropriate public keys for the new parties {pki,}i,e[n,j .

[0191] 1. Bi e B does as follows:

[0192] Round 1:

[0193] (a) Sample a mask

[0194] (b) Calculate ctmlask= EnCpi2^?;; 17,). Inaddition generate proof Hmask<_ to -B broadcast-

[0195] Broadcast Round:

[0196] (a) Receive

[0197] (broadcast, Sid, J from F broadcast-

[0198] (b) Verify the proofs. If any of them fail consider j malicious. Else send

[0199] (validate, sid,

[0200] Round 3 :

[0201] (a) Receive SBfrom FACSand set

[0202] (b) Set (dsj, 7Tjs) <- TAHE.TDeCpk(ctmasfeed-feey, vkj; [sk]f) and send (broadcast, sid, i, ) to Fbroadcast.

[0203] (a) Broadcast Round: Upon receiving (broadcast, sid,;, (dsj, nds^ verify that the proof ndsis valid; if it fails consider j malicious. (b) Collect a subset SBlE J+i) with validated proofs and calculate skmasked=

[0204] (c) Send

[0205] 2. Bf, E B does as follows:

[0206] (a) Upon receiving from ( )

[0207] (b) Calculate

[0208] (c) Calculate .

[0209] (d) Record

[0210] Definition: “Reconfiguration Protocol with Constant Threshold”

[0211] (Re-Configuration with Constant Threhsold

[0212] Reconfiguration Protocol with Constant Threshold is parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme PVSS, a computational security parameter K. and a threshold t. The protocol interacts with a transferring quorum B = {CUJteLriJaiqdareceiving quorum B' = The transferring quorum holds a t-out-of-n secret sharing [sk]£on the secret key of the TAHE sk. Both quorums hold a public key to the encryption scheme pk and the verification keys of the transferring quorum {vk, }£e[n] . The protocol outputs a fresh t-out-of-n secret shares [sk]£, on the secret key sk held by B' and public verification keys {vk\,}£,e[n,j corresponding to the shares. It is assumed that when the protocol begins the parties already executed the PVSS.Setup and PVSS.Gen successfully, and as such holds appropriate public keys for the new parties {pk£,}£,e^,j .

[0213] 1. Bi E B does as follows:

[0214] Round 1:

[0215] (a) Samples r£«- %K.

[0216] PVSS.Dist (pp, {pky,} .feM; n).

[0217] •F broadcast ■

[0218] Round 2:

[0219] (b) Verify the proofs and check the parameters of ^share.oidanc^nshare, new contain the same public commitment to the point at zero. If any of the checks fail consider j malicious, else send (validate, sid,pid) toJy^1

[0220] Round 3 :

[0221] (a) Receive (authorized-subset, sid, SBl) . For every j 6 SBset r.t=

[0222] PVSS.DecShare

[0223] (b) Setfsk] ,

[0224] (C) ({ctXre}?e[nr{C^)J7.,e[nr^hare) PVSS.Dist (PP, {pkj,} R .).

[0225] (d) Send (broadcast, sid,

[0226] Round 4:

[0227] (a) Receive (broadcast, sid, j,

[0228] (b) Verify the proofs n^hareand check that the commitment in the public parameters of Tis}h'ais equal to vky IfanY of the checks fail

[0229] ( W )B consider j malicious, else send (validate, sid, t) toT^t1

[0230] Broadcast Round:

[0231] (a) Receive (authorized-subset, sid, SB) from TACS. \=

[0232] •B global-broadc

[0233] 2. Bi E B does as follows:

[0234] (b) For every j* E SB, set r'yy = PVSS.DecShare (pp, pkr, skr, ct'^r

[0235] (c) For every j E SB, set r^i = PVSS.DecShare (pp, pk; / , sk; / , ct^are

[0236] (d) Set

[0237] (e) Set

[0238] (f) Record

[0239] The DKG protocol may apply for both an Elliptic Curve Digital Signature Algorithm (ECDSA) and a Schnorr algorithm. Reference is made to Figure 7, which is a schematic illustration of an ECDSA / Schnorr distributed key generation (DKG) process, operative in accordance with an embodiment of the present disclosure. A DKG operation is implemented by a network DKG module 140 of one or more parties 110 of decentralized network 105, and by a client DKG module 240 of one or more clients 210. Client 210 receives as input a party identifier (pid), a policy (policy), and a private key share (xA), and outputs a public key (X). Parties 110 and client 210 may access information from a shared database 190, which may include: an encryption of network share under the TAHE (ctkey), a public key share (XA), a public key (X), a party identifier (pid), a policy (policy), and a certificate. The certificate ensures the client that a subset of validators with enough voting power (at least t+1 VP) agree on this information (i.e., that the output was generated by a valid group of validators).

[0240] In one example, the ECDSA / Schnorr DKG operation is performed on a synchronous communication channel.

[0241] Definition: “DKG Protocol on Synchronous Communication Channel (DKG Protocol Sync)”

[0242] DKG Protocol Sync: (Key-Generation Hkeygen: KeyGen(G, G, q))

[0243] DKG Protocol - Sync is parameterized with the group description (G, G, q) . The protocol interacts with n + 1 parties A, Blt••• , Bn, where all parties hold pk as input. The parties agree on a fresh session identifier sid and do as follows: 1. X’s first message:

[0244] (a) A samples a random xA«- and computes XA= xA■ G .

[0245] (b) A sends (

[0246] 2. Bfs message:

[0247] (a) Each receives (receipt, pidA~) from ^om-zk-

[0248] (b) Each Bi samples a random xt and computes X, = xt■ G.

[0249] (c) Only on first execution: Each B, sends (keygen, sid) to FTAHEand waits for the functionality’s response. If the functionality responds with (pubkey, sid, 1 , U'RU) then output U'RU and abort; otherwise, if the functionality responds with (pubkey, sid, pk) then continue.

[0250] (d) Each Btcomputes cf = AHE. Enc(pk, xp for a randomly chosen pt.

[0251] (e) Each Btsends (prove, sid, pidt, Xt, ctp, xp, p^ to

[0252] 3. Bj’s verification:

[0253] (a) Each Btreceives (proof, sid, XB, ctkey) from ifnot- it receives and outputs the set of corrupted parties and aborts.

[0254] 4. X’s second message:

[0255] (a) A receives (broadcast, sid, XB) from F ‘ agg-zk-

[0256] (b) A sends (

[0257] 5. Bfs verification:

[0258] (a) Each Btreceives (decom-proof, pidA, XA) from ?com-zk’ ifnot- it aborts.

[0259] 6. Output:

[0260] • A outputs X = XA+ XBand records (keygen, XB, X; xA)

[0261] • Each Bi outputs X = XA+ XBand records (keygen, XA, X, ctkey, pk^ .

[0262] In a further example, the ECDSA / Schnorr DKG operation is performed on an asynchronous communication channel.

[0263] Definition: “DKG Protocol on Asynchronous Communication Channel (DKG Protocol Async)”

[0264] DKG Protocol Async: (Key-Generation Hkeygen- KeyGen(G, G, q, rB, sid, pkf)

[0265] DKG Protocol Async is parameterized with the group description (G, G, q) along with an access structure rB, a unique session identifier sid, and an encryption key to a TAHE scheme pk. The protocol interacts with a centralized party ApidAand a set of parties B = {Bi }ie[n] . The set of parties B can only send messages to parties in A through the functionality global-broadcast- The parties output the public verification key X and record the following:

[0266] • XA: the centralized party’s share of a public verification key for an ECDSA / Schnorr signature (implicitly gives the distributed party share);

[0267] • the distributed party B also records ctfeeyan encryption of the secret share held by the distributed party B;

[0268] • the centralized party ApidAalso records xA, its secret share of an ECDSA / Schnorr signature key.

[0269] The parties do as follows:

[0270] 1. Each Btdoes as follows:

[0271] Round 1

[0272] (a) Sample

[0273] (b) Compute Xt= Xf G, and ctj = AHE.Enc(pk, Xj; rji).

[0274] (c) Run n^EneDL[pk'(G'G'‘7)]on inputs receiving (XB, ctkey).

[0275] Broadcast Round:

[0276] (a) Send (global-broadcast, sid, i,

[0277] 2- &PidAdoesasfollows:

[0278] (a) Receive (global-broadcast, sid, (pid4,XB)) from TgtBobal.broadcast.

[0279] (b) Verify that XBE (G, else consider B malicious and abort.

[0280] (c) Sample set XA= xA■ G .

[0281] (d) Run n^Lu^G'G,<7)](XA, xA) generating a proof nDL.

[0282] (e) Send (broadcast, sid, pid^, X^,nBL) to Tbroadcast.

[0283] 3. Output:

[0284] Each Bi does as follows:

[0285] (a) Receive (sid, pid^X^ir^).

[0286] (b) Verify TVDL. if fails consider ApidAmalicious and abort, otherwise continue.

[0287] (c) Set X = XA+ XB.

[0288] (d) Output X and record (keygen, p i clx, X, XA, ctfeey) .

[0289] Party ApidAdoes as follows

[0290] (a) Set X = XA+ XB.

[0291] (b) Output X and record (keygen, pid^, X, XA; xA~). The signing process can be broken into a presign phase that can be executed before the message to be signed is decided, and an online-signing phase. Presigns can be used to reduce the latency at the online-signing phase. Specifically, presign may involve performing a preliminary computation before deciding on a message, that produces latency in the online signing phase where the message to be signed is being decided.

[0292] The presign protocol may apply for both a ECDSA or a Schnorr algorithm over both a synchronous or an asynchronous network. A presign protocol using ECDSA may be 2 rounds, and a pressing protocol using Schnorr may be one round. Reference is made to Figures 8A and 8B. Figure 8A is a schematic illustration of an ECDSA / Schnorr asynchronous presign process, operative in accordance with an embodiment of the present disclosure. Figure 8B is a schematic illustration of a Schnorr presign process, operative in accordance with an embodiment of the present disclosure.

[0293] Referring to Fig.8A, a first presign operation is implemented by an asynchronous network ECDA / Schnorr presign module 150 of one or more parties 110 of decentralized network 105, and by a client ECDA / Schnorr presign module 250 of one or more clients 210. Client 210 receives as input a party identifier (pid). Parties 110 and client 210 may access information from a shared database 190, which may include: two network public nonce shares (RB 0, RB,i), and a group of ciphertexts (cty), (cty.feey), (cty.feo), (cty.fel) to be used by the client during the online-signing phase for homomorphically evaluating the signature, a public key (X), and a certificate.

[0294] In one example, the presign routine is performed using an ECDSA signature scheme on a synchronous communication channel.

[0295] Definition: “Presign Protocol using ECDSA on Synchronous Communication Channel (Presign Protocol ECDSA / Sync)”

[0296] Presign Protocol ECDSA / Sync: (Presigning npres: Presign(G, G, qf sid)

[0297] Presign Protocol ECDSA / Sync interacts with n + 1 parties A, B1, --- , Bn, where all have pk and ctkeyas input. Before proceeding, all parties verify that session identifier sid has never been used before, then do as follows:

[0298] 1. 21 ’s message:

[0299] (a) A samples a random kA, pl and computes = Com(kA; pl).

[0300] (b) A sends (prove, sid, pidA, KA; kA, pl) to T^. fCom.

[0301] 2. B;’s message:

[0302] Round 1

[0303] (a) Bi receives (proof, sid, pidA, K^) from P^fCom. if not, it aborts.

[0304] (b) Btsamples kt«- Z* and computes = kt- G. Denote kB= Z ' i ki.

[0305] (c) Bi samples computes: ii. ct2l= AHE. Eval(pk,fbctkey; gmlask2), where: f (x) = Yf X; iii. ct3= AHE. Enc(pk, kp, rfmask3).

[0306] (d) Bi sends (prove, sid || y, pidbctf ct2l; ybpmlaskl, pmlaskJ to

[0307] (e) Bt sends

[0308] Round 2

[0309] (a) Bi receives (prove, sid || "y", pidi, ct1, ct2; ') from

[0310] (prove, sid, RB, ct3) from ?aggSCzk-

[0311] (b) Otherwise, if Btreceives (malicious, sid, U') from ^g^-zk^ ’Ctkey^ and / or (malicious, sid, U”) from ^agg^zk^ records the malicious parties (M and / or M'f

[0312] (c) Bi computes ct4= AHE. Eval(pk, f , ctp pmlask4) where: ff(x) = kt- x.

[0313] (d) Bi sends (

[0314] Proof verification:

[0315] (a) Bi receives (proof, sid || "k", pidbct3, ct4) from ^agg^zkPk’Ctli■ Otherwise, if Bi receives (malicious, sid, U") from ^agg^zk ^’^1^ it records the malicious parties and aborts.

[0316] 3. X’s verification:

[0317] (a) A receives (proof, sid || RB, ct3) from Fagg^zk’ ifnot- it aborts.

[0318] (b) A receives (proof, sid || "y"> ctbct2) from ^gg^k ^ ’Ctkey\ if not, it aborts.

[0319] 4. Output:

[0320] • A records (presign, sid, RB, ct4, ct2; kA, pl), where ct4and ct2are encryptions ofy and y ■ xB.

[0321] • Bi records (presign, sid, RB, KA, ct4, ct2, ct4), where ct4encrypts y ■ kBmod q.

[0322] In another example, the presign routine is performed using a Schnorr signature scheme on a synchronous communication channel.

[0323] Definition: “Presign Protocol using Schnorr on Synchronous Communication Channel (Presign Protocol Schnorr / Sync)”

[0324] Presign Protocol Schnorr / Sync: (Presign npres: Presign(G, G, q), sid) Presign Protocol Schnorr / Sync interacts with n + 1 parties A, B1, ••• , Bn. where all parties hold pk and B1, --- , Bnhave ctkeyas input. Before proceeding, all parties verify that session identifier sid has never been used before, then do as follows:

[0325] 1. X’s message:

[0326] (a) A samples a random kA, p «- 1qand computes = Com(kA; p).

[0327] (b) A sends (prove, sid, pidA, KA; kA, p) to TzLfCom.

[0328] 2. Bj’s message:

[0329] (a) Bi receives (proof, sid, pidA, K^) from EzlfCmn. if not, it aborts.

[0330] (b) Bi samples kf l<f <- %.qand computes Rf = kf ■ G and R* = l<f ■ G. Denote

[0331] (c) Bi samples pf E R pk, and computes AHE. Enc(pk, kf, pj).

[0332] (d) and

[0333] (e) Bi sends (prove, sid, pidi, Rf; kf) and (prove, sid, pidi. Rf kf) to

[0334] 3. Bj’s verification:

[0335] (a) Bi receives and (proof, sid, pid, Rg, ct^ from

[0336] (b) Otherwise, if Btreceives (malicious, sid, U") from ^agg^zk ^'6'^ ■> drecords malicious parties U and aborts.

[0337] 4. X’s verification:

[0338] (c) A receives (proof , sid, R^) and (proof , sid, R^) from not, it aborts.

[0339] 5. Output:

[0340] • A records (presign, sid, Rp, Rp, KA; kA, p) .

[0341] • Bi records (presign, sid, Rp, Rp, K^, ctko, ctk^f

[0342] In a further example, the presign routine is performed using an ECDSA signature scheme on an asynchronous communication channel.

[0343] Definition: “Presign Protocol using ECDSA on Asynchronous Communication Channel (Presign Protocol ECDSA / Async)”

[0344] Presign Protocol ECDSA / Async: (Presign npres: Presign^G, G, q, sid, pk, X, XA, ctkeyy)

[0345] Presign Protocol ECDSA / Async is parameterized with the group description (G, G, q) along with an access structure rB, a unique session identifier sid, an encryption key to a TAHE scheme pk, an ECDSA verification key X, the centralized party share of the verification key XA, and an encryption of the share of the distributed party of the signing key ctkey. The protocol interacts with a centralized party ApidAand a set of parties B = {Bj}ie[n] • The set of parties B can only send messages to parties in A through the functionality global-broadcast- Each party B, outputs:

[0346] • cty: an encryption of a randomizer y;

[0347] •cty-fcey: anencryption of the randomizer y multiplied by the signing key share of the blockchain xB, '

[0348] • cty.ko, cty.ki: an encryption of a randomized nonces k0■ y, and kT■ y, respectively;

[0349] • RB,(n RB,I - points on the curve equal to k0■ G, and kT■ G, respectively.

[0350] 1. Each Bi does as follows:

[0351] Round 1

[0352] (a) Sample a random yj and compute: i

[0353] (b) Runn^E«cDH[pk'ctfcey]on inpLlts(ctj,, c receiving

[0354] (Cty, Cty.fcgy^.

[0355] Round 2

[0356] (a) Sample a random k0l, k{ and q3l0, q3l1«- 5?pfe, and compute: i. ctj,.fe= AHE.Scale ii. ctj,.fe= AHE.Scale(pk, cty, k[, q3liy iii- RB,O = kg ■ G. iv. RBl1= k\ - G.

[0357] (b) Run nrB^scazeDLlpfc.CG.G.q),^] and receiving (

[0358] Broadcast Round:

[0359] (a) Send (global-broadcast, sid, i, (pid^, cty, cty.key, cty.feo, cty.fei, RB 0, RB,I)) to ^global-broadcast'

[0360] 2. Output: • ApidAreceives

[0361] (global-broadcast, sid, (pid^, cty, cty.fcey, cty.feo, cty.fei, RBf rom^global-broadcast •

[0362] • ApidAverifies that RB.O, RB,I 6 (G \ {0} and cty, cty.feey, cty.feo, cty.feie Cpk, else it aborts and considers B malicious.

[0363] • Each party B, records (sid, X, ctY, cty.key, cty.feo, cty.fei, RB 0,

[0364] In yet another example, the presign routine is performed using a Schnorr signature scheme on an asynchronous communication channel.

[0365] Definition: “Presign Protocol using Schnorr on Asynchronous Communication Channel (Presign Protocol Schnorr / Async)”

[0366] Presign Protocol Schnorr / Async: (Presign npres: SchPresign(G, G, q, rB, sid, pk))

[0367] Presign Protocol Schnorr / Async is parameterized with a group description (G, G, q) along with an access structure rB, a unique session identifier sid, and an encryption key to a TAHE scheme pk. The protocol interacts with a centralized party ApidAand a set of parties B = {Bj}je[n] • The set of parties B can only send messages to parties in A through the functionality Bgiobai-broadcaSL- Each party Btoutputs:

[0368] • KB O, KB 1: points on the curve equal to k0■ G, and k1■ G, respectively.

[0369] • The distributed parties also output ctfeo, ctfei: encryptions of kQ. kr, respectively

[0370] 1. Each Bi does as follows:

[0371] Round 1

[0372] (a) Btsamples a random k0l, k[ «- Rpk, and computes: ii. KBlA= k[ - G iii. iv.

[0373] (b) Run n^eDL[pfe'(G'G'<7)]on inputs (ct^, KBl0; k0l, q0l) and (ctkli, KBl1; k\, q^1receiving

[0374] Broadcast Round:

[0375] (a) Send (global-broadcast, sid, i, (pid4, KB 0, KB 1 global -broadcast ■

[0376] 2. Output: • ^pidA receives (global-broadcast, sid, from

[0377] ^global-broadcast •

[0378] • ApidA verifies that KB 0, KB 1e G \ {0}, else it aborts and considers B malicious.

[0379] • Both parties output KB 0, KB 1.

[0380] • Parties in B also record ctfen, ctfe.

[0381] An online-signing operation produces a signature given a message, a presign (if needed), and private key shares. The signing protocol may apply for both a ECDSA or a Schnorr algorithm over both a synchronous or an asynchronous network. Reference is made to Figure 9, which is a schematic illustration of an ECDSA / Schnorr signing process, operative in accordance with an embodiment of the present disclosure. A first signing routine is implemented by an asynchronous network ECD A sign module 160 of one or more parties 110 of decentralized network 105, and by a client ECDA sign module 260 of one or more clients 210. A second signing routine is implemented by an asynchronous network Schnorr sign module 165 of one or more parties 110 of decentralized network 105, and by a client Schnorr sign module 265 of one or more clients 210 Client 210 receives as input a party identifier (pid), an optional presign (presign), a private key share (xA), and a message (msg) to be signed. Parties 110 and client 210 may access information from a shared database 190, which may include: a signature and a certificate.

[0382] In one example, the signing routine is performed using an ECDSA signature scheme on a synchronous communication channel.

[0383] Definition: “Sign Protocol using ECDSA on Synchronous Communication Channel (Sign Protocol ECDSA / Sync)”

[0384] Sign Protocol ECDSA / Sync: (Signing Hsign: Sign[(Gi, G, q), sid, msg})

[0385] Sign Protocol ECDSA / Sync interacts with n + 1 parties A, Blt••• , Bn. where all have pk, K^, RBand RBas input. B1, --- , Bnhas in addition ctkey. ctko, and ctkias input. A has in addition kA, p, and msg as input. Before proceeding, all parties verify that session identifier sid has never been used before, retrieve a corresponding presign output if needed, then do as follows:

[0386] 1. 21 ’s message:

[0387] (a) A computes R = (kA)-1■ RB= (k^ks ■ G) and r = Rx-axismod q. Denote k = k^ks.

[0388] (b) A samples p2 G 3lppand computes UA= Com(kA■ xA; p2).

[0389] (c) A sets

[0390] (d) A homomorphically evaluates ct1, ct2on its private function fA(xA, xA) ■= di%i + a2x2: o ctA«- AHE. Eval(pk, fA, ct1, ct2; qevai)

[0391] (e) A sends message and the following proofs: o A sends o A sends (prove, sid, pidA, KA, UA; kA, xA, pl, p2) to

[0392] 2. Bi ’ s verification and output:

[0393] (a) Bi receives msg and the following proofs, otherwise it aborts: o (proof, sid || p idA, KA, RB) from o (proof, sid || p idA, KA, UA) from p^ComRatiolpp^^A]

[0394] (b) Bi verifies that the values used in the proofs are consistent with values obtained previously by Bt, specifically: o There are records (keygen, XA, X, ctkey, pk} and

[0395] (presign, sid, RB, KA, pt'); and o G = (r O UA) ® (m O KA) and C2= (r O KA), where r = Rx-axismod q and m = J-C(msg).

[0396] (c) Bi sends (decrypt, pk, ctA) and (decrypt, pk, ct4) to ?TAHEand waits for its response. Let the responses be (decrypted, pk, ctA, ptA, UA) and (decrypted, pk, ct4, pt4, U4) respectively; if ptA=1 or pt4=1 then output UAU U4and abort; otherwise, compute s' = ptf1■ ptAmod q (which is equal to (YkB)_1■ ((rkAxA+ mkA)y + rkAyxB} = k-1(rx + m)mod q as required) and output s = mines' , q — s'} (to ensure uniqueness of the signature).

[0397] 3. Output:

[0398] • Bi outputs <7 = (r, s') .

[0399] In another example, the sign routine is performed using a Schnorr signature scheme on a synchronous communication channel.

[0400] Definition: “Sign Protocol using Schnorr on Synchronous Communication Channel (Sign Protocol Schnorr / Sync)”

[0401] Sign Protocol Schnorr / Sync: (Signing Hsign: Sign[(Gi, G, q), sid, msg})

[0402] Sign Protocol Schnorr / Sync interacts with n + 1 parties A, Blt••• , Bn. where all have pk. K^.

[0403] RBand RBas input. B1, --- , Bnhas in addition ctkey. ctko, and ctkias input. A has in addition kA. p. and msg as input. Before proceeding, all parties verify that session identifier sid has never been used before, retrieve a corresponding presign output if needed, then do as follows:

[0404] 1. X’s message:

[0405] (a) A computes RA= kA■ G .

[0406] (b) A sends

[0407] (c) A calls the random oracle SC (msg ) and receives m.

[0408] (d) A calls the random oracle J-C (msg, RA, RB, RB) and receives p.

[0409] (e) A computes R = RA+ RB+ p - RB.

[0410] (f) A calls the random oracle SC(R, X, m) and receives e.

[0411] (g) A computes z = KA+ e ■ xz.

[0412] (h) A sends

[0413] 2. Bfs verification and output:

[0414] (a) Btreceives msg and z from A, and (proof, sid, pidA, KA, RA) from Otherwise, it aborts.

[0415] (b) Bi calls the random oracle SC (msg) and receives m.

[0416] (c) Bi calls the random oracle SC(m, RA, RB, RB) and receives p.

[0417] (d) Bi computes R = RA+ RB+ p ■ RB.

[0418] (e) Bi calls the random oracle SC(R, X, m) and receives e.

[0419] (f) Bi computes ctB= z ® ctk® (e © ctkey).

[0420] (g) Btsends (decrypt, pk, ctB) to ^TAHE and receives (decrypted, pk, ctB, ptB, SIA). Otherwise, it records the malicious parties and aborts.

[0421] (h) Bi verifies that ptB■ G = R + e ■ X. If not, it aborts.

[0422] 3. Output:

[0423] • Bi outputs c = (R, ptB).

[0424] In a further example, the sign routine is performed using an ECDSA signature scheme on an asynchronous communication channel.

[0425] Definition: “Sign Protocol using ECDSA on Asynchronous Communication Channel (“Sign Protocol ECDSA / Async)”

[0426] Sign Protocol ECDSA / Async:

[0427] (Sign Hsign: Sign(Gi, G, H, q, sid, fB, pk, X, ctkey, presX, msg^) Sign Protocol ECDSA / Async is parameterized with a group description (G, G, q) along with another public generator H used for Pedersen commitments, an access structure rB, a unique session identifier sid. an encryption key to a TAHE scheme pk. a public ECDSA verification key X. the centralized party share of the public verification key XA, an encryption of the share of the distributed party of the private signing key ctkey. the output of a uniquely determined previous presign protocol presX, sid = ctY.key, cty.ko, cty.ki, RB 0, RB,I), and the message to be signed msg. The protocol interacts with a centralized party ApidAand a set of parties B = {BJietn]- Tlqcset of parties B can only send messages to parties in A through the functionality global-broadcast- The parties output a valid ECDSA signature o = (r, s) with verification key X.

[0428] 1- ApidAdoes as follows:

[0429] (a) Calls the random oracle J-C(msg) and receives m.

[0430] (b) Samples computes: i. Ck= Pedersen. ComG H(kA; p0~) ii. Ca= Pedersen. ComG H(a; pr~) iii. Cp = Pedersen. ComG H(J3; p2~) iv. Ckx= Pedersen. ComXAiH(kA; p3)

[0431] (c) Calls the random oracle J-C(msg) and receives m.

[0432] (d) Runs the protocols generating proofs

[0433] (e) Calls the random oracle t(sid, G, G, q, H, X, presXsid, Ck, Ckx, XA, Ca, Cp, nk, na, np} and receives pk. It then computes: i

[0434] (f) Samples qQ, rp «- Rpk, and computes: ii. RB= (a ■ R'B) + (J3 ■ 6) iii. R = k^1■ RBand r = Rx.axisiv. aq = r ■ kA■ XA+ m ■ kAand a2= r ■ kA vi. Q = (r 0 Ckx) ® (m Q Ck~) and C2= r O Ck.

[0435] (g) Generate the following proofs:

[0436] (h) Send Each Bi does as follows:

[0437] Round 1

[0438] (a) Call the random oracle J-C(msg) and receives m.

[0439] (b) Receive

[0440] (c) Call the random oracle

[0441] (sid, msg, (G, G, qH, X, presX, sid, Ck, Ckx, XA, Ca, Cp, nkx, na, Tip) and compute: i iii. C1= (r Q Ckx) ® (m Q Ck) iv. C2= r O Ck.

[0442] (c) Verify the proofs. If fail abort and consider ApidA malicious.

[0443] (d) Send (decrypt,pk, ctA) and (decrypt,pk, ct a,[F) to TTAHE.

[0444] Broadcast Round:

[0445] (a) Receive (decrypt, pk, ctA, ptA) and (decrypt, pk, ct a, / 3, pt4~) from TTAHE.

[0446] (b) Compute s' = pt41■ ptAmod q and s = mines', q — s'}.

[0447] (c) Send (global-broadcast, sid, i, (r, s)) to TgiBobal.broadcast- Output:

[0448] • ApidAreceives (global-broadcast, sid, i, (r, s)) from

[0449] • ApidAverifies that (r, s) is a valid ECDSA signature, if the verification fails it aborts and considers B malicious. • Both ApidAand B output (r, s).

[0450] In yet another example, the sign routine is performed using a Schnorr signature scheme on an asynchronous communication channel.

[0451] Definition: “Sign Protocol using Schnorr on Asynchronous Communication Channel (Sign Protocol Schnorr / Async)”

[0452] Sign Protocol Schnorr / Async is parameterized with a group description (G, G, q) along with an access structure rB, a unique session identifier sid, an encryption key to a TAHE scheme pk. a public verification key X. an encryption of the share of the distributed party of the private signing key ctkey, the output of a uniquely presign presx= {KB 0, KB 1), and the message to be signed msg. The protocol interacts with a centralized party ApidAand a set of parties B = {BJietn]- The set of parties B can only send messages to parties in A through the functionality B ' giobai-broadcast- The parties output a valid Schnorr signature (z, e) to a verification key X.

[0453] 1- ApidAdoes as follows:

[0454] (a) Samples computes KA= kA- G.

[0455] (b) Calls the random oracle (sid, X, presX sid, KA, msg) and receives pk.

[0456] (c) Computes K = (KB,0) + (pk■ KB 1) + KA.

[0457] (d) Calls the random oracle (K, X,msg) and receives e.

[0458] (e) Computes zA= kA+ e ■ xA.

[0459] (f) Sends (broadcast, sid, (zA, KA~)) to Tbroadcast.

[0460] 2. Each Bi does as follows:

[0461] Round 1

[0462] (a) Receive (broadcast, sid, (zA, KA)) from BbroadcasLand verify that KAG G else consider ApidAmalicious and abort.

[0463] (b) Call the random oracle (sid, X, presX sid, KA, msg) and receives pk.

[0464] (c) Bi computes: i

[0465] (d) Calls the random oracle (K, X,msg) and receives e.

[0466] (e) Check that zAG = KA+ e ■ XA. l£ not, consider ApidAmalicious and abort.

[0467] (f) Compute ctB= ctfe® (e ■ ctfeey)ffizj4.

[0468] (e) Send (decrypt, pk, ctB) to ?TAHE-

[0469] Broadcast Round: (a) Receive (decrypted, pk, ctB, ptB) from ETAHE.

[0470] (b) Set <7 = (ptB, e).

[0471] (c) Send (global-broadcast, sid, i, a) to Fglobal-broadc.

[0472] 3. Output:

[0473] • ApidA receives (global-broadcast, sld, i, <J) from global— broadcas •

[0474] • AptdA verifies that o is a valid signature, else it aborts and considers B malicious.

[0475] • Both parties output o.

[0476] It is noted that any output of a disclosed protocol (e.g., a DKG and / or Presign protocol) of parties in B may be stored in a shared public database. This may allow for a different subset of parties who did not participate in DKG to continue with a presign routine, or a different subset of parties who did not participate in DKG and / or presign to continue with a sign routine.

[0477] A user may transfer ownership of a resource, such as a digital wallet, to another user. Reference is made to Figure 10, which is a schematic illustration of an ownership transfer process, operative in accordance with an embodiment of the present disclosure. A sender client 210 seeks to transfer ownership of a resource (e.g., a digital wallet) to a receiver client 210. An ownership transfer routine is implemented by client ownership transfer modules 280 of sender client 210 and receiver client, and the ownership transfer is verified by ownership transfer verification module 180 of one or more parties 110 of decentralized network 105.

[0478] Sender client 210 receives as input a sender party identifier (pids). a receiver party identifier (pidrf a receiver public key (X), and a private key share (xA). Receiver client 210 receives as input a receiver secret decryption key share (skr). and outputs a private key share (xA). Parties 110 and client 210 may access information from a shared database 190 for a share (Encpidr(xAy) . Sender client 210 encrypts its private key share (xA) under the receiver public key (X), along with a zeroknowledge proof of correctness. Network 105 verifies the proof and the policy and stores it in shared database 190. Receiver client 210 retrieves the encrypted share (Encpidr(xA)) from database 190 (after verifying the certificate), decrypts the share using its private decryption key, and derives and outputs the sender private key share.

[0479] Transfer Protocol: (Transfer Tlrransfer- Transfer^, G, q, sid, pk, pkAnewctkey)

[0480] The Transfer Protocol is parameterized with the group description (G, G, q) . The Transfer Protocol interacts with the parties where Aoldtransfers its secret key to Anewand {Bjjes approves this transfer. All parties hold pk, pk^new, XAold, X as input, where pk is a public key to the encryption scheme; pk^newis a public key of Anew(which may be accessed from a shared database by querying pidj4new; XAoldis a public share of Aoldof a signing key (used to prove to B and to Anewthat the correct secret share is transferred); and X is a public verification key . The parties agree on a fresh session identifier sid and do as follows: Aoiddoes as follows:

[0481] (a) Samples sets ctnew= EncpkAnew(xo[d; if).

[0482] (c) Sends (broadcast, sid, pid4oW, (cttransfer, Bi e B does as follows:

[0483] (a) Receives (broadcast, sid, pld^o^, from broadcast and verifies ^transfer- if the proof fails consider Aoldmalicious; otherwise send (global-broadcast, sid, i, cttransfer) to ?global-broadcast ■

[0484] (b) Records (X^^^ pid^^). Anewdoes as follows:

[0485] (a) Receives (global-broadcast, sid, ^transfer )' from 'Fgiobai— broadc ■> sets xnew

[0486] The present disclosure may support additive key derivation for ECDSA signatures.

[0487] Definition: “Slightly Enhanced ECDSA Signing Oracle: GSE-ECDSA "

[0488] Parameters include a cyclic group (G, G, q). a random oracle function J-C : {0,1}* -> 1q. Biased variables are denoted by ' . Slightly Enhanced ECDSA Signing Oracle operates as follows:

[0489] 1. On input (keygen, sid), sample compute X = x ■ G. record and send (sid, X; x).

[0490] 2. On input (biaskey,

[0491] 3. On input (pres, ssid), sample k0, kT«- 1q, compute Ro= k0■ G and / ?x= / q ■ 6, record and send (ssid, Ro, R^, k0, kft) .

[0492] 4. On input (sign, sid, SSid, msg, ft key’ ^pres,Q’ ftpres, Q’ &pres,l’ ftpres, l)' *^0.

[0493] (a) Retrieve (sid, X'; %') and (ssid, Ro, R±; k0, kft) . If no such (ssid, Ro, R1; k0, kft) or sid exist, ignore.

[0494] (b) Compute x" «- x' + ft'keyand X" «- X' + ft'key■ G .

[0495] (c) Compute kqcXp-res, o kqT ftpres, o and k (Xpres,i Rj. T ftpres, i-

[0496] (d) Set R’o = k’0- G and R\ = k’1- G.

[0497] (e) Set m = Jf(msg).

[0498] (f) Set [l H(X , R Q, R TEl, (Xpres,Q> ftpres,Q> ^pres,l> ftpres,l) ^md SCt R R Q T

[0499] (g) Set r = R'x-ax and compute s = k1■ (m + r ■ x").

[0500] (h) Erase (ssid, Ro, R^; k0, kft) from memory and return

[0501] (sld,ssld,msg, At least one of the disclosed protocols discussed herein may include an identifiable abort, where malicious parties causing failure of protocol are identifiable.

[0502] At least one of the disclosed protocols discussed herein may be publicly verifiable, such that any entity (including but not limited to each of the parties), given a protocol transcript (collection of all messages sent from all parties), can check a validity of the protocol execution and of an output thereof.

[0503] At least one of the disclosed protocols discussed herein performed over an asynchronous communication channel may include guaranteed output delivery, such that if an adversary does not control a threshold of the parties, then the protocol will execute successfully.

[0504] At least one of the disclosed protocols discussed herein may be extended to fit a distributed system serving a plurality of clients concurrently. The distributed parties may hold a single secret share for the underlying TAHE scheme, and the network share of each secret signing key may be stored publicly encrypted under the corresponding TAHE public key.

[0505] The disclosed embodiments may include a secure function evaluation for the TAHE, allowing a user to evaluate a private affine function f homomorphically on a tuple of ciphertexts ctt= Enctw^ ri) without revealing information on function f except for f(xr, ••• , xn~), even given a secret key of the TAHE and randomizers and plaintexts xtfor the encryptions ct, .

[0506] The TAHE may be tied with elliptic curve group elements, such that the corresponding witnesses thereof satisfy linear relations and have range constraints, using at least one generic zeroknowledge (zk) range proof. The ZK proof may be a novel ZK proof for allowing aggregation of batched statements from multiple provers into a single proof.

[0507] In accordance with the presign protocols of the present disclosure, it may be proven that the presigns can be generated offline in a common pool shared with all clients in the network. Upon signing, the clients may use the same pool of presigns to sign transactions.

[0508] In some aspects of the present disclosure, the same key may be used for both an ECDSA signature and for a Schnorr signature.

[0509] The disclosed embodiments may include one or more performance boosting procedures. One example is batching zk-proofs, such that a single proof can be derived by a prover for multiple statements from multiple parallel executions of at least one of the protocols. Another example is when using Class-Groups, range proofs are redundant and as a result the verification of such batched proofs weakly depends on the batch size (it is linearly dependent, but with a significantly smaller constant compared to the verification time of a single non-batched proof). A further example is amortized decryption, such that it is enough for a single party to combine decryption shares and derive the signature, where the rest of the parties will also validate the signature, and only if verification fails they will have to zk-prove validity of decryption shares and combine decryption shares on their own, such that each party is now 0(1) amortized in the online signing phase. Yet another example is synchronous decryption, where if the subset of parties participating in signing is predetermined and known before the threshold decryption round starts, each party can raise its decryption share to the corresponding Lagrange coefficient; then, combining the decryption shares only consists of n-group multiplication. Figure. 11 illustrates a diagrammatic representation of a machine in the example form of a computing device 300 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a Local Area Network (LAN), an intranet, an extranet, or the Internet. Computing device 300 may correspond, for example, to a computing device of a client 210 or party 110 of FIG. 1. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet computer, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines (e.g., computers) that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0510] The example computing device 300 includes a processing device 302, a main memory 304 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.), a static memory 306 (e.g., flash memory, static random access memory (SRAM), etc.), and a secondary memory (e.g., a data storage device 328), which communicate with each other via a bus 308.

[0511] Processing device 302 represents one or more general-purpose processors such as a microprocessor, central processing unit, or the like. More particularly, processing device 302 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device 302 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Processing device 302 is configured to execute the processing logic (instructions 326) for performing operations and steps discussed herein.

[0512] Computing device 300 may further include a network interface device 322 for communicating with a network 364. Computing device 300 also may include a video display unit 310 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 312 (e.g., a keyboard), a cursor control device 314 (e.g., a mouse), and a signal generation device 320 (e.g., a speaker).

[0513] Data storage device 328 may include a machine-readable storage medium (or more specifically a non-transitory computer-readable storage medium) 324 on which is stored one or more sets of instructions 326 embodying any one or more of the methodologies or functions described herein, such as instructions for one or more DN party modules 315, which may correspond to DN party modules 130 of FIG. 2 in embodiments. A non-transitory storage medium refers to a storage medium other than a carrier wave. The instructions 326 may also reside, completely or at least partially, within main memory 304 and / or within processing device 302 during execution thereof by computer device 300, main memory 304 and processing device 302 also constituting computer- readable storage media. Computer readable storage medium 324 may also store a software library containing methods for one or more of the DN party modules 315. While computer-readable storage medium 324 is shown in an example embodiment to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” shall also be taken to include any medium other than a carrier wave that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “computer-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.

[0514] Reference is made to Figure 12, which is a flow diagram of a general method for generating a digital signature, operative in accordance with an embodiment of the present disclosure. In first step 411, AHE DKG is performed. In a step 412, ECDSA / Schnorr presign pool is provided. In a step 413, background processes are performed. In a step 414, ECDSA / Schnorr DKG is performed. In a step 415, ECDSA / Schnorr presign is performed. In a step 416, ECDSA / Schnorr child keys are provided. In a step 417, ECDSA / Schnorr sign is performed. In a step 418, wallet transfer or sharing is performed. In a step 419, network reconfiguration is performed.

[0515] While certain embodiments of the disclosed subject matter have been described, so as to enable one of skill in the art to practice the present disclosure, the preceding description is intended to be exemplary only. It should not be used to limit the scope of the disclosed subject matter, which should be determined by reference to the following claims.

Claims

CLAIMS1. A method for generating at least one digital signature, comprising: following one or more secure protocols based on a threshold additively homomorphic encryption (TAHE) over a broadcast channel, wherein a threshold of parties of a decentralized network (DN) produces the digital signature by following a Universally Composable (UC)- secure protocol configured to output at least one of an Elliptic curve digital signature algorithm (ECD SA) signature or a Schnorr signature.

2. The method of claim 1, wherein at least one client and the threshold of parties of the decentralized network cooperate to generate the digital signature.

3. The method of claim 1, wherein the threshold of parties of the decentralized network cooperate to generate the digital signature without a client.

4. The method of claim 1, further comprising generating a distributed key using a distributed key generation (DKG) protocol of the one or more secure protocols.

5. The method of claim 1, The method of claim 4, wherein the DKG protocol is a DKG protocol over a synchronous communication channel (“DKG Protocol Sync”), the DKG Protocol Sync being parameterized with a group description (G, G, q) and interacting with n + 1 parties including a client A, and DN parties B = {E?i }fe[TL] , wherein all parties hold a public key (pk) as input and agree on a fresh session-identifier (sid) that uniquely identifies a session.

6. The method of claim 5, wherein the parties perform the following:

1. A’s first message:(a) A samples a random xA«-and computes XA= xA■ G;(b) A sends (com-prove, pidA, XA, xA~) to T^_zk',2. Bj’s message:(a) each B, receives (receipt, pid^ from ?com-z1A(b) each B[ samples a random X[ «- 1qand computes X[ = X[ ■ G;(c) only on first execution: Each Btsends (keygen, sid) to ETAHEand waits for ta response from E^_zk, -^com-zk responds with (pubkey, sid, 1, [ / 'Pit / ) then output U'RU and abort; otherwise, if ^om-zk responds with (pubkey, sid, pk) then continue;(d) each B, computes ct, = AHE. Enc(pk, xp pf) for a randomly chosen pp(e) each Bi sends (prove, sid, pidt, Xt, ctp, xp, pf) to p^njc idpk.iG.G.q)]3. Bys verification:(a) each B, receives (proof, sid, XB, ctkey^ from Fagg^zk’not- receives and outputs the set of corrupted parties and aborts;4. X’s second message:(a) A receives (broadcast, sid, XB) from E " ^gg- i(b) A sends (decom-proof, pidA) to Ecom-zk,'5. Bfs verification:(a) each Btreceives (decom-proof, pidA, XA) from E^^_zk, if not, it aborts;6. Output:• A outputs X = XA+ XBand records (keygen, XB,X; xA):• each Bi outputs X = XA+ XBand records (keygen, XA, X, ctkey, pkff7. The method of claim 4, wherein DKG protocol is a DKG protocol over an asynchronous communication channel (“DKG Protocol Async”), the DKG Protocol Async being parameterized with a group description (G, G, q), an access structure rB, a unique session identifier sid, and an encryption key to a TAHE scheme pk. wherein the DKG Protocol Async interacts with a centralized party ApidAand a set of parties B = {BJiepip wherein the set of parties B can only send messages to parties in A through a functionality Egiobai.broadcast.

8. The method of claim 7 wherein the parties output a public verification key X and record the following:XA: the centralized party’s share of a public verification key for an ECDSA / Schnorr signature;• the distributed party B also records ctkeyan encryption of the secret share held by distributed party B;• the centralized party ApidAalso records xA, its secret share of an ECDSA / Schnorr signature key, wherein the parties perform the following:

1. each Bi does as follows:Round 1(a) sample(b) computectj = AHE.Enc(pk, xt; r]i);(c) run n^EneDL[pk'(G'G'<?)]on inputs (Xi, xi, r]i') receiving (XB, ctfeey);Broadcast Round:(a) send (global-broadcast, sid, i, (pid4,XB)) to TgBobai.broadcast,-2. ApidA does as follows:(a) receive (global-broadcast, sid, (pid^Xg)) from TgBobal.broadcast,-(b) verify that XBe (G, else consider B malicious and abort;(c) sampleset XA= xA■ 6;(d) run n^L^G,G,q)1(XA; xA) generating a proof nDL.(e) Send (broadcast, sid, pid^, XA, nDL) to Tbroadcast.

3. Output: each Bi does as follows:(a) receive (sid, pid^ X^ n^);(b) verify TVDL. if fails consider ApidAmalicious and abort, otherwise continue;(c) set X = XA+ XB;(d) output X and record (keygen, pid^, X, XA, ctfeey);ApidA does as follows:(a) set X = XA+ XB;(b) output X and record (keygen, pid^, X, XA; xA~).

9. The method of claim 2, further comprising distributing, by a client that holds a private signing key, the private signing key between the client and the decentralized network.

10. The method of claim 1, further comprising pre-signing using a presign protocol of the one or more secure protocols.

11. The method of claim 10, wherein the presign protocol is a presign protocol using an ECDS A scheme over a synchronous communication channel (“Presign Protocol ECDSA / Sync”), the Presign Protocol ECDSA / Sync interacting with n + 1 parties including a client A. and DN parties B = {Bi }je[n] ■> wherein all parties hold a public key (pk) and an encryption of a network share under TAHE (ctkey) as input, wherein all parties verify that a session-identifier sid has never been used before.

12. The method of claim 11, wherein all parties further perform the following:

1. 21 ’s message:(a) A samples a random kA, pl «- TLqand computes= Com(kA; pl),-(b) A sends (prove, sid, pidA, KA; kA, pl) to EzkCom,-2. Bj’s message:Round 1(a) Bi receives (proof, sid, pidA, K^) from EzlfCmn. if not, it aborts;(b) Bi samples Ip «- 1qand computes Ri = Ip ■ G. Denote kB=(c) Bi samplescomputes: iv.v. ct2= AHE. Eval(pk,fbctkey; ifmask2), where: f (x) = y(■ x; vi. ct3= AHE. Enc(pk, kp, qmlask3),-(d) Bi sends (prove, sid || y, pidbct[, ct2l; ybqmlaskl, ifmaskJ to(e) Bi sendsRound 2(e) Btreceives (prove, sid || "y", pidbct1, ct2,- ) from(prove, sid, RB, ct3) from ^aggC-zL;(f) Otherwise,receives (malicious, sid, U1') from and / or(malicious, sid, U”) from ?agg-Czk’ it records the malicious parties (M and / or M');(g) Bt computes ct4= AHE. Eval(pk, f , ctp, ifmask4) where: ff(x) = kt- x\(h) Bi sends (Proof verification:(b) Bi receives (proof, sid || "k", pidbct3, ct4) from ^agg-DzH^Pk Ct^ otherwise, if Bi receives (malicious, sid, U") fromft records the malicious parties and aborts;3. X’s verification:(d) A receives (proof, sid || RB, ct3) from ^agg^ > ifnot- aborts;(e) A receives (proof, sid || "y", ct1;ct2) from ?agg-CzkPk Ctkey\ if not, it aborts;4. Output:• A records (presign, sid, RB, ct4, ct2; kA, pl), where ct4and ct2are encryptions of y and y ■ xB;• Bi records (presign, sid, RB, KA, ct1, ct2, ct4), where ct4encrypts y ■ kBmod q.

13. The method of claim 10, wherein the presign protocol is a presign protocol using a Schnorr scheme over a synchronous communication channel (“Presign Protocol Schnorr / Sync”), the Presign Protocol Schnorr / Sync interacting with n + 1 parties including a client^, and DN parties B = {Bi }je[„] , wherein all parties have an encryption of a network share under TAHE (ctkey) as input, wherein all parties verify that a session-identifier (sid) has never been used before.

14. The method of claim 13, wherein all parties further perform the following:

1. A’s message:(a) A samples a random kA, pand computes= Com(kA; p)\(b) A sends2. Bfs message:(a) Bi receives (proof, sid, pidA, K^) from EkfCom. if not, it aborts;(b) Bi samples kf kf «- 1*qand computes R? = kf ■ G and R( = kf ■ 6; denote k% = Zi kf and / ci = L / q1;(c) Bi samples pf E R pk. and computesAHE. Enc(pk, kf, pjf(d) Bi sends and(prove, sid, pidb(e) Bi sends (prove, sid, pidi, Rf; kf) and (prove, sid, pidi, Rf, kl) to3. Bj’s verification:(a) Bi receivesand (proof, sid, pid, Rg, ct^ from(b) Otherwise, if Btreceives (malicious, sid, U") frommalicious parties U and aborts;4. X’s verification:(f) A receives (proof , sid, Rg) and (proof , sid, R%) from ^a^5zfc^G’G’<7^, if not, it aborts;5. Output:• A records (presign, sid, Rg, Rf KA; kA, p~) ;• Bi records (presign, sid, Rg, Rg, KA, ctko, ctk^f15. The method of claim 10, wherein the presign protocol is a presign protocol using an ECDS A scheme over an asynchronous communication channel (“Presign Protocol ECDSA / Async”), the Presign Protocol ECDSA / Async parameterized with: a group description (G, G, qf an access structure rB, aunique session identifier sid, an encryption key to a TAHE scheme pk. an ECDSA verification key X. a centralized party share of the verification key XA, and an encryption of a share of a distributed party of a signing key ctkey. the Presign Protocol ECDSA / Async interacting with a centralized party ApidAand a set of parties B = {BjjepiE wherein the set of parties B can only send messages to parties in A through a functionality E global- broadcast -16. The method of claim 15, wherein each party Btoutputs: cty: an encryption of a randomizer y;•cty-fcey: anencryption of the randomizer y multiplied by the signing key share of the blockchain xB\• ctrfeo, cty.fei: an encryption of a randomized nonces k0■ y, and kT■ y, respectively;• RB O, RB,I - points on the curve equal to k0■ G, and kT■ G, respectively,1. each Bi does as follows:Round 1(a) Sample a random yjT]21<- 3?pfe, and compute: i(b) Runn^E«cDH[pk'ctfcey]on inpLlts(ctj,, creceivingRound 2(f) Sample a random k0l, k{and T]31O, RF3 1«- 3?pfe, and compute: i. ctj,.fe= AHE.Scaleii. ctj,.fe= AHE.Scale(pk, cty,iii-iv. RBl1= k\ - G’(g) Run nrB^scazeDLbfc / G.G.q),^] and(cty.fel, RB,i; ^L ^3,i) receiving (Broadcast Round:(b) Send (global-broadcast, sid, i, (pid^, cty, cty.fcey, cty.feo, cty.fei, to^global-broadcast'2. Output:• &pidAreceives(global-broadcast, sid, (pid^, cty, cty.feey, cty.feo, cty.fei, RBfrom^global-broadcast'• ApidAverifies that RB.O, RBAe G \ {0} and cty, cty.feey, cty.feo, cty.fele Cpfe, else it aborts and considers B malicious;• Each party Bj records (sid, X, ctY, cty.key, cty.feo, cty.fei, RB 0,17. The method of claim 10, wherein the presign protocol is a presign protocol using a Schnorr scheme over an asynchronous communication channel (“Presign Protocol Schnorr / Async”), the Presign Protocol Schnorr / Async parameterized with: a group description (G, G, q). an access structure rB, a unique session identifier sid. and an encryption key to a TAHE scheme pk. the Presign Protocol Schnorr / Async interacting with a centralized party ApidAand a set of parties B = wherein the set of parties B can only send messages to parties in A through a functionality global-broadcast ■18. The method of claim 17 wherein each party Btoutputs:• KBQ, KB 1: points on the curve equal to k0■ G, and kT■ G. respectively;• The distributed parties also output ctfeo, ctfei: encryptions of kQ. k±, respectively,1. each Bi does as follows:Round 1(a) Bi samples a random k0l, k[and q0l, q\ «- 7?pfe, and computes:ii. KBlA= k1i- G- iii.iv.(b) Run n^eDL[pfe'(G'G'<?)]on inputsreceiving (ctfeo, KB 0), (ctki, KB 1)-Broadcast Round:(c) Send (global-broadcast, sid, i, (pid4, KB 0, KB 1)) to Fglobal-broadcasts2. Output:• ApidAreceives ( global-broadcast, sid, (pid^, / fB 0, fromJg lobal- broadcast ~• ApidAverifies that KB 0, KB 1e G \ {0}, else it aborts and considers B malicious;Both parties output KB 0, KB 1:Parties in B also record ctfeo, ctfei.

19. The method of claim 1, further comprising signing a message using a sign protocol of the one or more secure protocols.

20. The method of claim 19, wherein the sign protocol is a sign protocol using an ECDSA scheme over a synchronous communication channel (“Sign Protocol ECDSA / Sync”), the Sign Protocol ECDSA / Sync interacting with n + 1 parties including a client A. and DN parties B = {Bjjeln] , wherein all parties hold a public key (pk). network public nonce shares (RB, Rg), and a commitment on A’s share of the nonce for signature (K^), as input, wherein all parties verify that a session-identifier (sid) has never been used before.

21. The method of claim 20, wherein all parties further perform the following:

1. 21 ’s message:(a) A computes R = (k^^1■ RB= (k^kg ■ G) and r = Rx-axismod q. Denote k = k^kg-(b) A samples p2 G 3lppand computes UA= Com(kA■ xA; p2);(c) A sets CL-L = r ■ kA■ xA+ m ■ kAand a2= r ■ kA. where m := J-C (msg);(d) A homomorphically evaluates ct1, ct2on its private function fA(xA, xA) ■= CL'^X'y T CL2X2'. o ctA«- AHE. Eval(pk, fA, ct1, ct2; T]evai)',(e) A sends message and the following proofs: o A sends (prove, sid, pidA, KA, RB; kA, pl) to j^^ComDLiPP^Gti^ • o A sends (prove, sid, pidA, KA, UA; kA, xA, pl, p2) to2. Bfs verification and output:(a) Btreceives msg and the following proofs, otherwise it aborts: o (proof, sid || pidA, KA, RB) from j:^ComDLiPP(-GG‘i^ • o (proof, sid || pidA, KA, UA) fromT^GomRatlApp^G^xA} .(b) Bi verifies that values used in the proofs are consistent with values obtained previously by Bt. specifically: o There are records (keygen, XA, X, ctkey, pk) and (presign, sid, RB, KA, pt'); and(c) Bi sends (decrypt, pk, ctA) and (decrypt, pk, ct4) to ?TAHEand waits for its response. Let the responses be (decrypted, pk, ctA, ptA, UA) and(decrypted, pk, ct4, pt4, U4) respectively; if ptA=1 or pt4=1 then output UAU U4and abort; otherwise, compute s’ = pt41■ ptAmod q (which is equalrequired) and output s = mines' , q — s'} (to ensure uniqueness of the signature);3. Output:• Bi outputs c = (r, s) .

22. The method of claim 19, wherein the sign protocol is a sign protocol using a Schnorr scheme over a synchronous communication channel (“Sign Protocol Schnorr / Sync”), the Sign Protocol Schnorr / Sync interacting with n + 1 parties including a client A. and DN parties B = {Bjhepi] , wherein all parties have a public key (pk), network public nonce shares (RB, R^), a commitment on X’s share of the nonce for signature (K^), an encryption of a network share (ctkey) , and encryptions of nonces k0, k4(ctko, ctki) as input, wherein all parties verify that a sessionidentifier (sid) has never been used before.

23. The method of claim 22, wherein all parties further perform the following:

1. 2Ts message:(a) A computes RA= kA- G;(b) A sends(c) A calls the random oracle (msg) and receives m;(d) A calls the random oracle J-C(msg, RA, RB, RB) and receives p;(e) A computes R = RA+ RB+ p ■ RB;(f) A calls the random oracle 3~C(R, X, -m) and receives e;(g) A computes z = KA+ e ■ xz\(h) A sends msg and z to {Bi}i<n;2. Bi ’ s verification and output:(a) Bi receives msg and z from A, and (proof, sid, pidA, KA, RA) from; otherwise, it aborts;(b) Bi calls the random oracle J-C(msg) and receives m;(c) Bi calls the random oracle J-Cfm, RA, RB, RB) and receives p\(d) Bi computes(e) Bi calls the random oracle J-C(R, X, m) and receives e;(f) Bi computes ctB= z ® ctk® (e © ctkey)-,(g) Bi sends (decrypt, pk, ctB) to TTAHEand receives (decrypted, pk, ctB, ptB, 'llA),- otherwise, it records the malicious parties and aborts;(h) Bi verifies that ptB■ G = R + e ■ X; if not, it aborts;3. Output:• Bi outputs c = (R, ptB).

24. The method of claim 19, wherein the sign protocol is a sign protocol using an ECDSA scheme over an asynchronous communication channel (“Sign Protocol ECDSA / Async”), the Sign Protocol ECDSA / Async parameterized with a group description (G, G, q), a public generator (W) used for Pedersen commitments, an access structure rB, a unique session identifier (sid), an encryption key to a TAHE scheme pk, an ECDSA verification key X, a centralized party share of the verification key XA, an encryption of a share of a distributed party of a signing key ctkey, an output of a uniquely determined previous presign protocol presX, sid = {cty, cty.key, cty.ko, cty.ki, RB 0, RBf), and a message to be signed (msg), the Sign Protocol ECDSA / Async interacting with a centralized party ApidAand a set of parties B = {Bi }je[n], wherein the set of parties B can only send messages to parties in A through a functionality ^global-broadcasts wherein the parties output a valid ECDSA signature o = (r, s) with verification key X.

25. The method of claim 24, wherein:1- ApidAdoes as follows:(a) calls the random oracle O-C(msg) and receives m;(b) samplescomputes: i. Ck= Pedersen. ComG H(kA, pQy, ii. Ca= Pedersen. ComG H(a; pt); iii. Cp = Pedersen. ComG H(J3; p2y iv. Ckx= Pedersen. ComXA,H(kA; p3);(c) calls the random oracle H'(msg) and receives m;(d) runs protocolsgenerating proofs nkand na, Up-(e) calls a random oraclethen computes: i. ct7- k = (ctY■ kQ} ffi(pkO cty■ kJ-(f) samples Pc Pi *“ Rpk, and computes:ii- RB = (A’ R'B) + ( / > ’ ^); vii. R = / cj1■ RBand r = Rx.axiS,' iii. iv.v. C1= (r © Ckx) ® (m Q Ck~) and C2= r O Q;(g) generate the following proofs:;;;111.i(h) send2. Each Bi does as follows:Round 1(a) call the random oracle Jf (msg) and receives m;(b) receive(c) call the random oracleJ-C (sid, msg, (G, G, qH, X, presX, sid, Ck, Ckx, XA, Ca, Cp, nkx, na, Up) and compute: iiii. Q = (r O Ckx) ® (m O Cfe); iv. C2= r © Ck;(h) verify the proofs; if fail abort and consider ApidAmalicious;(i) send (decrypt, pk, ctA) and (decrypt, pk, ct a, / 3) to ?TAHE', Broadcast Round:(d) receive (decrypt, pk, ctA, ptA) and (decrypt, pk, ct a, / 3, pt4) from TTAHE;(e) compute s' = pt41■ ptAmod q and s = mines', q — s'};(f) send (global-broadcast, sid, i, (r, s)) to TgBobai.broadcast,-4. Output:• ApidAreceives (global-broadcast, sid, i, (r, s)) from TgBobai.broadcast,-• ApidA verifies that (r, s) is a valid ECDSA signature, if the verification fails it aborts and considers B malicious;• Both ApidAand B output (r, s).

26. The method of claim 19, wherein the sign protocol is a sign protocol using a Schnorr scheme over an asynchronous communication channel (“Sign Protocol Schnorr / Async”), the Sign Protocol Schnorr / Async parameterized with: a group description (G, G, q). an access structure rB, a unique session identifier (sid), an encryption key to a TAHE scheme pk, a public verification key X, an encryption of the share of the distributed party of the private signing key ctkey, an output of a unique presign presx= (KB,O> KB,I), and a message to be signed (msg), the Sign Protocol Schnorr / Async interacting with a centralized party ApidAand a set of partiesB = wherein the set of parties B can only send messages to parties in A through a functionality ?giobai^roadcast, wherein each party Btoutputs a valid Schnorr signature (z, e) to the verification key X.

27. The method of claim 26, wherein:1- ^pidAd°es asfollows:(a) samplescomputes KA= kA- G.(b) calls the random oracle 3~C (sid, X, presX sid, KA, msg) and receives pk;(c) computes K = (KB O) + (pk■ KB 1) + KA,(d) calls the random oracle J-C (K, X,msg) and receives e;(e) computes zA= kA+ e ■ xA,(f) sends (broadcast, sid, (z4,7Q)) to Tbroadcast-2. each Btdoes as follows:Round 1(a) receive (broadcast, sid, (zA, f^)) from ?broadcastand verify that KAE (G else consider ApidAmalicious and abort;(b) call the random oracle (sid, X, presX sid, KA, msg) and receives pk;(c) Btcomputes: i- ctfc—ctfc0®Mfc ' otfci’ ii.(d) calls the random oracle J-C (K, X,msg) and receives e;(e) check that zAG = KA+ e ■ XA. If not, consider ApidAmalicious and abort;(f) compute ctB= ctfe® (e ■ ctfeey)ffizj4;(g) send (decrypt, pk, ctB) to TTAHE;Broadcast Round:(a) receive (decrypted, pk, ctB, ptB) from TTAHE:(b) set <7 = (ptB, e);(c) send (global-broadcast, sid, i, a) to ?giObai-broad i3. Output:* ApidA receives (global-broadcast, sid, i, <r) from ^FgiObai— broadcastsApidAverifies that a is a valid signature, else it aborts and considers B malicious; both parties output o .

28. The method of claim 1 , wherein each DN party has a respective voting power, the method further comprising changing the voting power of at least one DN party using a network reconfiguration routine.

29. The method of claim 28, wherein the network reconfiguration routine comprises a reconfiguration protocol with a varying threshold (“Reconfiguration Protocol Varying Threshold”), the Reconfiguration Protocol Varying Threshold parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme (PVSS), a computational security parameter K. a statistical security parameter a. an initial threshold t and a final threshold t', the Reconfiguration Protocol Varying Threshold interacting with a transferring quorum B = {BJiepi] and a receiving quorum B' =wherein the transferring quorum holds a t-out-of-n secret sharing [sk] j on a secret key of a TAHE (sk), wherein the transferring quorum and the receiving quorum hold a public key (pk) to the encryption scheme, verification keys of the transferring quorum {vkj}ie[7i], and an encryption of the secret key ctsfe= E nCpk(sk; rf), wherein the Reconfiguration Protocol Varying Threshold outputs a fresh t'-out-of-n' secret shares [sk]j, on the secret key (sk) held by B' and public verification keys {vk\,}£,e^T,j corresponding to the secret shares, wherein when the Reconfiguration Protocol Varying Threshold begins the parties already executed PVSS.Setup and PVSS.Gen successfully, and holds public keys for the new parties {pkj,}j,e[„,] .

30. The method of claim 19, wherein:

1. Bte B does as follows: Round 1:(a) Sample a mask(b) Calculate ctmlask=pi). In addition generate proof Hmask<_(d) Send ^broadcast, sid, ito ^broadcast-Broadcast Round:(a) Receive(broadcast, sid, jfrom broadcast-(b) Verify the proofs. If any of them fail consider j malicious. Else send(validate, sid,Round 3 :(a) Receive SBfrom E 4^5 and set(b) Set (ds;, 74 , vkj; [sk]f) and send ^broadcast, sid,Broadcast Round:(a) Upon receiving (broadcast, sid, j, (ds,-, verify that the proof nd}sis valid;if it fails consider j malicious.(b) Collect a subset SBle with validated proofs and calculate skmasked= TAHE.Recphk({ds,} .s, ).(c) Send( global-broadcast, sid, i,t0F “ global-broadca •2. B'i, e B does as follows:(a) Upon receiving(?,(b) Calculate(c) Calculate(d) Record31. The method of claim 28, wherein the network reconfiguration routine comprises a reconfiguration protocol with a constant threshold (“Reconfiguration Protocol Constant Threshold”), the Reconfiguration Protocol Constant Threshold parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme PVSS, a computational security parameter K. and a threshold t, the Reconfiguration Protocol Constant Threshold interacting with a transferring quorum B = {BJietn] and a receiving quorumwherein the transferring quorum holds a t-out-of-n secret sharing [sk], on a secret key of a TAHE sk, wherein the transferring quorum and the receiving quorum hold a public key (pk) to the encryption scheme, and verification keys of the transferring quorum {vkjjg^j. wherein the Reconfiguration Protocol Constant Threshold outputs a fresh t-out-of-n secret shares [sk]j, on the secret key sk held by B' and public verification keys {vk'j,}j,e^,j corresponding to the secret shares, wherein when the Reconfiguration Protocol Constant Threshold begins the parties already executed PVSS.Setup and PVSS.Gen successfully, and holds appropriate public keys for the new parties {pkj,}j,e[„,] .

32. The method of claim 31, wherein BtE B does as follows:Round 1:(a) Samples <- %K.•F broadcast ■Round 2:(c) Upon receiving t, sid, j , ({cts]fl^ld] , {c. J n’har ldY\U J7e[n] t ^7e[n] )from^{ct$hare,neiv} ’ {^’t'}pe[n]’77sl'lar,newj y(d) Verify the proofs and check the parameters of TisJhar oidand n:sJhare newcontain the same public commitment to the point at zero. If any of the checks fail consider j malicious, else send (validate, sid,pid)Round 3 :(e) Receive (authorized-subset, sid, SB,) . For every j E SBset r.t-Round 4:(c) Receive (broadcast, sid, j,(d) Verify the proofs ns]h'areand check that the commitment in the public parameters ofchecks failconsider j malicious, else send (validate, sid, t) topics ■Broadcast Round:(c) Receive (authorized-subset, sid, SB) from TACS. \='Fglobal-broadcas ■2. Bi E B does as follows:(i) For every j E SB, set rjt> = PVSS.DecShare (pp, pkf / , skf / , ctXre)•(j) Set(k) Set(1) Record33. The method of claim 1, wherein a plurality of clients and the threshold of parties of the decentralized network cooperate to generate the digital signature, the method further comprising transferring ownership of a resource from a sender client of the plurality of clients to a receiver client of the plurality of clients using an ownership transfer protocol of the one or more secure protocols.

34. The method of claim 33, wherein the ownership transfer protocol is parameterized with a group description (G, G, q), and interacts with parties Aold, Anewandwhere Aoldtransfers its secret key to Anewand {Bi}iESapproves the transfer, wherein all parties hold: a public key (pk) to the encryption scheme; a public key of Anew(pkj4new); a public share of Aoldof a signing key (^40id); a public verification key (X) as input, and wherein the parties agree on a fresh session identifier (sid).

35. The method of claim 34, wherein the parties further perform the following:

1. Aoiddoes as follows:(c) Sends (broadcast, sid,to broadcast -2. Bi e B does as follows:(a) Receives (broadcast, sid, pid^^, (jAiransfer> Utransfer)' ^ from T broadcast and verifies nLransj-er: if the proof fails consider Aoldmalicious; otherwise send (global-broadcast, sid, i, cttransfer') to ?global-broadcast-(b) Records (XAold, pid^J.

3. Anewdoes as follows:(a) Receives (global-broadcast, sid, ctfrcm5^er) from -Fgiobai— broadca -> sets x-newrecords (XAold, xnew^.

36. The method of any one of claims 1 to 35, wherein at least one secure protocol of the one or more secure protocols comprises an identifiable abort.

37. The method of any one of claims 1 to 35, wherein at least one secure protocol of the one or more secure protocols is publicly verifiable.

38. The method of any one of claims 1 to 35, wherein at least one secure protocol of the one or more secure protocols is performed over an asynchronous communication channel and comprises guaranteed output delivery.

39. The method of any one of claims 1 to 35, further comprising: performing a generic transformation to securely transform a plaintext space of the TAHE, to align the plaintext space with an ECDSA / Schnorr group of order q.

40. The method of claim 1, further comprising a secure function evaluation for the TAHE, allowing a user to evaluate a private affine function f homomorphically on a tuple of ciphertexts ctt= Enc(wi, ri) without revealing information on function f except for / (%i, ••• , xn). even given a secret key of the TAHE and randomizers and plaintexts xtfor the encryptions ct, .

41. The method of claim 1, wherein the TAHE is tied with elliptic curve group elements, such that corresponding witnesses thereof satisfy linear relations and have range constraints, using at least one generic zero-knowledge (zk) range proof.

42. The method of claim 1, wherein the parties of the decentralized network hold a single secret share, for an underlying TAHE scheme, and a network share of each secret signing key is stored publicly encrypted under a corresponding TAHE public key.

43. The method of any one of claims 10 to 18, wherein the presign protocol is configured to generate at least one presign offline in a common pool of presigns shared with all clients in the network, such that upon signing the clients could use the common pool of presigns to sign transactions.

44. The method of any one of claims 1 to 43, further comprising: performing at least one performance boosting procedure selected from the group consisting of:(i) batching zero knowledge proofs;(ii) redundant range proofs when using Class-Groups;(iii) amortized decryption; and(iv) synchronous decryption.

45. The method as in any one of claims 1 to 44, wherein the decentralized network is selected from the group consisting of: a blockchain system; a directed acrylic graphs DAG-based consensus platform; and a blockchain-DAG hybrid.

46. The method as in any one of claims 1 to 45, wherein the digital signature is used for at least one application selected the group consisting of: digital wallets; future transactions; bridging blockchains; wallet transfer; and decentralized autonomous organization (DAO).

47. The method of claim 46, wherein a public key of a digital wallet generated on a first blockchain is configured to be used as a digital wallet on a second blockchain.

48. The method of claim 47, wherein a policy is specified upon generation of the digital wallet on the first blockchain, and wherein the first blockchain enforces the policy when using the digital wallet for the second blockchain participating in signing requests only on transactions valid with the specified policy.

49. The method of claim 46, wherein a future transaction comprises a signed transaction of a client configured to be executed when a predetermined condition is met, wherein the blockchain is configured to delay execution of the transaction.

50. The method of claim 46, wherein a decentralized autonomous organization (DAO) comprises at least one child key derived from a parent key, wherein the child key comprises fewer permissions than the parent key.

51. A system for generating a digital signature, comprising: a decentralized network (DN) comprising a plurality of parties, configured to follow one or more secure protocols based on a threshold additively homomorphic encryption (TAHE) over a broadcast channel,wherein a threshold of the plurality of parties of the DN produces the digital signature by following a Universally Composable (UC)-secure protocol configured to output at least one of an Elliptic curve digital signature algorithm (ECD SA) signature or a Schnorr signature.

52. The system of claim 51, wherein at least one client and the threshold of parties of the decentralized network cooperate to generate the digital signature.

53. The system of claim 51, wherein the threshold of parties of the decentralized network cooperate to generate the digital signature without a client.

54. The system of claim 51, comprising a network distributed key generation (DKG) module, configured to generate a distributed key using a distributed key generation (DKG) protocol of the one or more secure protocols.

55. The system of claim 54, wherein the DKG protocol is a DKG protocol over a synchronous communication channel (“DKG Protocol Sync”), the DKG Protocol Sync being parameterized with a group description (G, G, q) and interacting with n + 1 parties including a client A, and DN parties B = {Bt}ie[„] , wherein all parties hold a public key (pk) as input and agree on a fresh session-identifier (sid) that uniquely identifies a session.

56. The system of claim 54, wherein DKG protocol is a DKG protocol over an asynchronous communication channel (“DKG Protocol Async”), the DKG Protocol Async being parameterized with a group description (G, G, q), an access structure rB, a unique session identifier sid, and an encryption key to a TAHE scheme pk, wherein the DKG Protocol Async interacts with a centralized party ApidAand a set of parties B = {BJiepip wherein the set of parties B can only send messages to parties in A through a functionality Bgiobai-broadcast-57. The system of claim 52, configured to distribute, by a client that holds a private signing key, the private signing key between the client and the decentralized network.

58. The system of claim 51, comprising a network ECDSA / Schnorr presign module, configured for pre -signing using a pre sign protocol of the one or more secure protocols.

59. The system of claim 58, wherein the presign protocol is a presign protocol using an ECDSA scheme over a synchronous communication channel (“Presign Protocol ECDSA / Sync”), the Presign Protocol ECDSA / Sync interacting with n + 1 parties including a client A, and DN parties B = {Bt}i6[n] , wherein all parties hold a public key (pk) and an encryption of a network share under TAHE (ctkey) as input, wherein all parties verify that a session-identifier sid has never been used before.

60. The system of claim 58, wherein the presign protocol is a presign protocol using a Schnorr scheme over a synchronous communication channel (“Presign Protocol Schnorr / Sync”), the Presign Protocol Schnorr / Sync interacting with n + 1 parties including a client^, and DN parties B = {Bi }je[„] , wherein all parties have an encryption of a network share under TAHE (ctkey) as input, wherein all parties verify that a session-identifier (sid) has never been used before.

61. The system of claim 58, wherein the presign protocol is a presign protocol using an ECDSA scheme over an asynchronous communication channel (“Presign Protocol ECDSA / Async”), the Presign Protocol ECDSA / Async parameterized with: a group description (G, G, q). an access structure rB, aunique session identifier sid, an encryption key to a TAHE scheme pk, an ECDSA verification key X, a centralized party share of the verification key XA, and an encryption of a share of a distributed party of a signing key ctkey, the Presign Protocol ECDSA / Async interacting with a centralized party ApidAand a set of parties B = {BjjepiE wherein the set of parties B can only send messages to parties in A through a functionality ? global- broadcast-62. The system of claim 58, wherein the presign protocol is a presign protocol using a Schnorr scheme over an asynchronous communication channel (“Presign Protocol Schnorr / Async”), the Presign Protocol Schnorr / Async parameterized with: a group description (G, G, q), an access structure rB, a unique session identifier sid, and an encryption key to a TAHE scheme pk, the Presign Protocol Schnorr / Async interacting with a centralized party ApidAand a set of parties B = {Bj}ie[n], wherein the set of parties B can only send messages to parties in A through a functionality ^Fglobal-broadcast-63. The system of claim 51, comprising a network ECDSA / Schnorr sign module, configured for signing a message using a sign protocol of the one or more secure protocols.

64. The system of claim 63, wherein the sign protocol is a sign protocol using an ECDSA scheme over a synchronous communication channel (“Sign Protocol ECDSA / Sync”), the Sign Protocol ECDSA / Sync interacting with n + 1 parties including a client A, and DN parties B = {Bjjeln] , wherein all parties hold a public key (pk), network public nonce shares (RB, RB)- and a commitment on Ts share of the nonce for signature (K^), as input, wherein all parties verify that a session-identifier (sid) has never been used before.

65. The system of claim 64, wherein the sign protocol is a sign protocol using a Schnorr scheme over a synchronous communication channel (“Sign Protocol Schnorr / Sync”), the Sign Protocol Schnorr / Sync interacting with n + 1 parties including a client A, and DN parties B = {Bjhepi] , wherein all parties have a public key (pk), network public nonce shares (RB, RB), a commitment on A’s share of the nonce for signature (K^), an encryption of a network share (ctkey) , and encryptions of nonces k0, kT(ctko, ctki) as input, wherein all parties verify that a sessionidentifier (sid) has never been used before.

66. The system of claim 64, wherein the sign protocol is a sign protocol using an ECDSA scheme over an asynchronous communication channel (“Sign Protocol ECDSA / Async”), the Sign Protocol ECDSA / Async parameterized with a group description (G, G, q), a public generator (H) used for Pedersen commitments, an access structure rB, a unique session identifier (sid), an encryption key to a TAHE scheme pk, an ECDSA verification key X, a centralized party share of the verification key XA, an encryption of a share of a distributed party of a signing key ctkey, an output of a uniquely determined previous presign protocol presX, sid =and a message to be signed (msg), the Sign Protocol ECDSA / Async interacting with a centralized party Ap[dAand a set of parties B = {B[ }i6[n], wherein the set of parties B can only send messages to parties in A through a functionality ^global-broadcasts wherein the parties output a valid ECDSA signature o = (r, s) with verification key X.

67. The system of claim 64, wherein the sign protocol is a sign protocol using a Schnorr scheme over an asynchronous communication channel (“Sign Protocol Schnorr / Async”), the Sign Protocol Schnorr / Async parameterized with: a group description (G, G, q), an access structure fB, a unique session identifier (sid), an encryption key to a TAHE scheme pk, a publicverification key X. an encryption of the share of the distributed party of the private signing key ctkey, an output of a unique presign presx= (KB O, KBI), and a message to be signed (msg), the Sign Protocol Schnorr / Async interacting with a centralized party ApidAand a set of parties B = {Bjjepib wherein the set of parties B can only send messages to parties in A through a functionality Fgiobai-broadcast, wherein each party Btoutputs a valid Schnorr signature (z, e) to the verification key X.

68. The system of claim 51, wherein each DN party has a respective voting power, the system comprising a network reconfiguration module, configured for changing the voting power of at least one DN party using a network reconfiguration routine.

69. The system of claim 68, wherein the network reconfiguration routine comprises a reconfiguration protocol with a varying threshold (“Reconfiguration Protocol Varying Threshold”), the Reconfiguration Protocol Varying Threshold parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme (PVSS), a computational security parameter K. a statistical security parameter a. an initial threshold t and a final threshold t', the Reconfiguration Protocol Varying Threshold interacting with a transferring quorum B = {BJiepi] and a receiving quorum B' =wherein the transferring quorum holds a t-out-of-n secret sharing [sk] j on a secret key of a TAHE (sk), wherein the transferring quorum and the receiving quorum hold a public key (pk) to the encryption scheme, verification keys of the transferring quorum {vkj}je[„], and an encryption of the secret key ctsfe= E nCpk(sk; rj), wherein the Reconfiguration Protocol Varying Threshold outputs a fresh t'-out-of-n' secret shares [sk]j, on the secret key (sk) held by B' and public verification keys {vk'j,}j,e[„,] corresponding to the secret shares, wherein when the Reconfiguration Protocol Varying Threshold begins the parties already executed PVSS.Setup and PVSS.Gen successfully, and holds public keys for the new parties {pkj,}j,e[„,] .

70. The system of claim 68, wherein the network reconfiguration routine comprises a reconfiguration protocol with a constant threshold (“Reconfiguration Protocol Constant Threshold”), the Reconfiguration Protocol Constant Threshold parameterized with a TAHE encryption scheme, a public verifiable secret sharing scheme PVSS, a computational security parameter K. and a threshold t, the Reconfiguration Protocol Constant Threshold interacting witha transferring quorum B = {BJiefn] and a receiving quorumwherein the transferring quorum holds a t-out-of-n secret sharing [sk], on a secret key of a TAHE sk, wherein the transferring quorum and the receiving quorum hold a public key (pk) to the encryption scheme, and verification keys of the transferring quorum {vkjjg^j. wherein the Reconfiguration Protocol Constant Threshold outputs a fresh t-out-of-n secret shares [sk]j, on the secret key sk held by B' and public verification keys {vk'j,}j,e[„,] corresponding to the secret shares, wherein when the Reconfiguration Protocol Constant Threshold begins the parties already executed PVSS.Setup and PVSS.Gen successfully, and holds appropriate public keys for the new parties {pkj,}j,e[„,] .

71. The system of claim 51, wherein a plurality of clients and the threshold of parties of the decentralized network cooperate to generate the digital signature, the system comprising an ownership transfer verification module, configured for transferring ownership of a resource from a sender client of the plurality of clients to a receiver client of the plurality of clients using an ownership transfer protocol of the one or more secure protocols.

72. The system of claim 71, wherein the ownership transfer protocol is parameterized with a group description (G, G, q), and interacts with parties AoW, Anewandwhere Aoidtransfers its secret key to Anewand {Bjjes approves the transfer, wherein all parties hold: a public key (pk) to the encryption scheme; a public key of Anew(pkj4new); a public share of Ao[dof a signing key (XioW); a public verification key (X) as input, and wherein the parties agree on a fresh session identifier (sid).

73. The system of any one of claims 51 to 72, wherein at least one secure protocol of the one or more secure protocols comprises an identifiable abort.

74. The system of any one of claims 51 to 72, wherein at least one secure protocol of the one or more secure protocols is publicly verifiable.

75. The system of any one of claims 51 to 72, where at least one secure protocol of the one or more secure protocols is performed over an asynchronous communication channel and comprises guaranteed output delivery.

76. The system of any one of claims 51 to 72, configured for performing a generic transformation to securely transform a plaintext space of the TAHE, to align the plaintext space with an ECDSA / Schnorr group of order q.

77. The system of claim 51, configured for performing a secure function evaluation for the TAHE, allowing a user to evaluate a private affine function f homomorphically on a tuple of ciphertexts ctj = Enc(Wi, ri) without revealing information on function f except for / (x^ ••• , x„). even given a secret key of the TAHE and randomizers and plaintexts for the encryptions ct, .

78. The system of claim 51, wherein the TAHE is tied with elliptic curve group elements, such that corresponding witnesses thereof satisfy linear relations and have range constraints, using at least one generic zero-knowledge (zk) range proof.

79. The system of claim 51, wherein the parties of the decentralized network hold a single secret share, for an underlying TAHE scheme, and a network share of each secret signing key is stored publicly encrypted under a corresponding TAHE public key.

80. The system of claim 58, wherein the presign protocol is configured to generate at least one presign offline in a common pool of presigns shared with all clients in the network, such that upon signing the clients could use the common pool of presigns to sign transactions.

81. The system of any one of claims 51 to 80, configured for performing at least one performance boosting procedure selected from the group consisting of:(i) batching zero knowledge proofs;(ii) redundant range proofs when using Class-Groups;(iii) amortized decryption; and(iv) synchronous decryption.

82. The system as in any one of claims 51 to 81, wherein the decentralized network is selected from the group consisting of: a blockchain system; a directed acrylic graphs DAG-based consensus platform; and a blockchain-DAG hybrid.

83. The system as in any one of claims 51 to 82, wherein the digital signature is used for at least one application selected the group consisting of: digital wallets; future transactions; bridging blockchains; wallet transfer; and decentralized autonomous organization (DAO).

84. The system of claim 83, wherein a public key of a digital wallet generated on a first blockchain is configured to be used as a digital wallet on a second blockchain.

85. The system of claim 84, wherein a policy is specified upon generation of the digital wallet on the first blockchain, and wherein the first blockchain enforces the policy when using the digital wallet for the second blockchain participating in signing requests only on transactions valid with the specified policy.

86. The system of claim 85, wherein a future transaction comprises a signed transaction of a client configured to be executed when a predetermined condition is met, wherein the blockchain is configured to delay execution of the transaction.

87. The system of claim 83, wherein a decentralized autonomous organization (DAO) comprises at least one child key derived from a parent key, wherein the child key comprises fewer permissions than the parent key.

Images