WO2025099552A1 - 2 pc-mpc : signature de seuil ecdsa basée sur un chiffrement homomorphique de seuil - Google Patents

2 pc-mpc : signature de seuil ecdsa basée sur un chiffrement homomorphique de seuil Download PDF

Info

Publication number
WO2025099552A1
WO2025099552A1 PCT/IB2024/060864 IB2024060864W WO2025099552A1 WO 2025099552 A1 WO2025099552 A1 WO 2025099552A1 IB 2024060864 W IB2024060864 W IB 2024060864W WO 2025099552 A1 WO2025099552 A1 WO 2025099552A1
Authority
WO
WIPO (PCT)
Prior art keywords
protocol
parties
sid
key
broadcast
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/IB2024/060864
Other languages
English (en)
Inventor
Offir FRIEDMAN
Avichai MARMOR
Dolev MUTZARI
Omer SADIKA
Yehonatan COHEN SCALY
Avishay Yanai
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dwallet Labs Ltd
Original Assignee
Dwallet Labs Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dwallet Labs Ltd filed Critical Dwallet Labs Ltd
Publication of WO2025099552A1 publication Critical patent/WO2025099552A1/fr
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3252—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem

Definitions

  • the present disclosure generally relates to the field of cryptography, and more particularly to public-key encryption schemes.
  • 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.
  • 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.
  • 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.
  • fully homomorphic encryption FHE
  • FHE fully homomorphic encryption
  • 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).
  • ECDSA Elliptic curve digital signature algorithm
  • 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.
  • the network 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.
  • 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.
  • TAHE threshold additively homomorphic encryption
  • DN decentralized network
  • UC Universally Composable
  • EDSA Elliptic curve digital signature algorithm
  • 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.
  • DKG distributed key generation
  • 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).
  • 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.
  • Presign Protocol ECDSA/Sync an ECDSA scheme over a synchronous communication channel
  • DN parties B (B t ⁇ j e [n] , where all parties hold a public key (pk) and an encryption of a network share under TAHE (ct key ) as input, where all parties verify that a session-identifier sid has never been used before.
  • Presign Protocol Schnorr/Sync a synchronous communication channel
  • DN parties B (B t ⁇ j e [n] , where all parties have an encryption of a network share under TAHE (ct key ) 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 an asynchronous communication channel (“Presign Protocol Schnorr
  • the method may further include signing a message using a sign protocol of the one or more secure protocols.
  • 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.
  • 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 protocol may be parameterized with a group description ( ⁇ , ⁇ , ⁇ ), and interacts with parties ⁇ , ⁇ and where ⁇ ⁇ 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 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.
  • 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.
  • UC Universally Composable
  • EDSA Elliptic curve digital signature algorithm
  • 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.
  • DKG Protocol Sync synchronous communication channel
  • 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.
  • Presign Protocol ECDSA/Sync an ECDSA scheme over a synchronous communication channel
  • DN parties B (Bt ⁇ ie [ n ] , where all parties hold a public key (pk) and an encryption of a network share under TAHE (ct key ) as input, where all parties verify that
  • 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).
  • 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 r B , a unique session identifier sid, and an encryption key to a TAHE scheme pk, the Presign Protocol Schnorr/As
  • Synchronorr/Sync a sign protocol using a Schnorr scheme over a synchronous communication channel
  • 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 A oid .
  • 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 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 may include at least one child key derived from a parent key, where the child key includes fewer permissions than the parent key.
  • 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
  • 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
  • FIG 3 is a schematic illustration of a client of the system of Figure 1, operative in accordance with an embodiment of the present disclosure
  • FIG. 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
  • FIG. 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
  • Figure 6 is a schematic illustration of a network reconfiguration process, operative in accordance with an embodiment of the present disclosure
  • FIG. 7 is a schematic illustration of an ECDSA/Schnorr distributed key generation DKG process, operative in accordance with an embodiment of the present disclosure
  • 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
  • Figure 9 is a schematic illustration of an ECDSA/Schnorr signing process, operative in accordance with an embodiment of the present disclosure
  • Figure 10 is a schematic illustration of an ownership transfer process, operative in accordance with an embodiment of the present disclosure.
  • 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;
  • 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.
  • 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(n 2 ) 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).
  • 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.
  • 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.
  • 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).
  • 2PC two-party
  • MPC multiparty computation
  • Protocols that use a broadcast channel naturally reduce the message complexity from Q(n 2 ) to 0(n). yet each party intuitively reads and processes a message from every other party, and so the computational overhead remains Q(n).
  • 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).
  • 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.
  • picking a different designated party for each ciphertext can reduce the amortized complexity to 0(1) exponentiations per party per ciphertext.
  • each operation by the parties may be accompanied by a zero-knowledge proof.
  • the parties separately verify a proof broadcasted by any other party before proceeding to the next protocol step.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the service provider may completely deny service from a client or censor specific transactions.
  • it leaves open the following attack vector.
  • 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.
  • 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.
  • the disclosed embodiments relate to Universally Composable (UC)-secure large-scale threshold ECDSA protocols and introduce the notion of 2PC-MPC.
  • the client and each network participant possess only one share.
  • 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.
  • 2PC single party only
  • MPC multiparty computation
  • 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.
  • 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.
  • this structure can be referred to as “one plus t out of n”.
  • 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.
  • the second differing aspect is round complexity vs computational complexity.
  • the disclosed protocols may be optimized to minimize either a number of rounds or computational complexity.
  • 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.
  • 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.
  • 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.
  • the present disclosure introduces the concept of a “2PC-MPC threshold” ECDSA/Schnorr.
  • ECDSA/Schnorr the concept of a “2PC-MPC threshold” ECDSA/Schnorr.
  • 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.
  • 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.
  • the communication complexity of the user is independent of n.
  • the computation time is independent of n.
  • 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.
  • PoS Proof of Stake
  • 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.
  • DAG directed acrylic graphs
  • 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.
  • 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.
  • 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.
  • the present disclosure may be used in various applications.
  • 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.
  • 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.
  • ECDSA Elliptic Curve Digital Signature Algorithm
  • EdDSA Edwards-curve Digital Signature Algorithm
  • a policy may be specified upon creation of a digital wallet on a first blockchain.
  • 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 x A bitcoin to fund F when and if bitcoin (BTC) is worth ⁇ t BTC dollars.
  • 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.
  • 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 x A BTC to liquidity pool P, and condition it on receiving at least y P Ether from the liquidity pool.
  • 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.
  • 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”.
  • wallet transfer 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.
  • NFTs non-fiingible tokens
  • DAO Decentralized Autonomous Organization
  • Child keys may have less permissions than their parent key.
  • 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.
  • 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.
  • 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).
  • 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.
  • DKG distributed key generation
  • 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.
  • DKG may be one-round for Schnorr and two-rounds for ECDSA, and sign may be a single round.
  • the disclosed embodiments may alleviate the need for zero-knowledge proofs toward the client.
  • 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.
  • 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.
  • 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.
  • 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).
  • AOMDL Algebraic One-More Discrete Log
  • ECDSA signing oracle may be proven secure in the Elliptic Curve Generic Group Model (EC-GGM).
  • disclosed protocols may circumvent the need to assume Enhanced-ECDSA unforgeability, which is proven in EC-GGM up to q 1 ⁇ 3 . which may not suffice when working over a 256-bit elliptic curves. Instead, the disclosed EC-GGM reduction may suggest security up to q 1 / 2 , which is on-par with security of standard assumptions over elliptic curves (e.g., discrete logs).
  • 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.
  • EdDSA Edwards-curve Digital Signature Algorithm
  • a threshold of parties or variations thereof as used herein may further encompass instances of “a threshold of voting power” of parties.
  • 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.
  • 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.
  • 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.
  • the disclosure relates to the ideal functionalities B broadcast , - ⁇ 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 .
  • the functionality interacts with a set of parties B and an adversary c/Z.
  • 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.
  • a homomorphic addition of two ciphertexts ct x and ct 2 is denoted by ct x ® ct 2
  • a multiplication of a ciphertext ct by a scalar a is denoted by a O ct.
  • AHE is correct if for every K, every t G poly(/c), every Z’-ary affine function f as above, and every plaintext pt 1; ••• , pt t G P pk .
  • Pr [Dec (sk, Eval(p/c, f, (ct 1; ••• , cG))) /(pt 1; ••• , pG)] > 1 — neg(/c), where (pk, sk) «- Gen(l K ) and ct; «- Enc(pk, pt;), and the probability is over the coins used by the algorithms Gen, Enc and Eval.
  • algorithm may not satisfy secure function evaluation.
  • 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 !P pk :
  • AHE has secure function evaluation if there exists a PPT algorithm £ Eval such that for every PPT adversary c/Z, every Gary affine function f as above, every (pk, sk) and every plaintext pt 2 , -" , pG G J’pfc, and randomness rp,
  • 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.
  • Enc(p/c, pt; p enc )- A deterministic algorithm that on input a public key pk, a plaintext pt G P pk , and randomness p enc G 3? pfe , outputs a ciphertext ct G C pk .
  • 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 pt 1; ••• , pt t G P pk ,
  • Pr [Rec (s, [TDec [[sk] it Eval(pk, f , (ct r , --- , ct f )))j ) /(pt 1; ••• , pt f )j > 1 — neg(/c) where (pk, ⁇ [skJihefn]) Gen(l K ) and ct; «- Enc(pk, ptj), and the probability is over the coins used by the algorithms Gen, Enc and Eval.
  • a TAHE functionality E TAHE is defined below.
  • B ⁇ B 1; • • • , B n ⁇ be a set of parties and U c B, where
  • the parties in B can generate a key and prove its validity to the certifiers.
  • the certifiers are the users (represent by client A) who engage with B.
  • any set of t + 1 honest parties can decrypt a ciphertext using a previously generated key, unless the adversary decides to abort.
  • E TAHE is 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.
  • 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.
  • 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.
  • the TAHE may also include a reconfiguration protocol: ReConf(l K , I" 7 , t, t' , n, n',pk,aux, [sk]j) , which is a probabilistic (possibly interactive) protocol that is given a security parameter 1 K , 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:
  • Key Generation Upon receiving (keygen, pid, sid) from a subset S keygen G Y keygen from a fresh sid, run (pk; sk) «- AHE.Gen(l K ), send pk to the adversary and receive the adversary response (continue, [/') .
  • 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 5 decrypt;Sid ct .
  • L [params] ⁇ S; s
  • 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.
  • P z R k implicitly 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:
  • ct is a vector then interpret the language as proving knowledge of plaintext for each element in the vector.
  • a Publicly Verifiable Secret Sharing 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.
  • a PVSS scheme consists of the following algorithms:
  • 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.
  • Distribution Verification 0/1 ⁇ - VerifySharing(pp, ⁇ pk ; , ctJ ieMi7rsftare ), a verification algorithm for n share .
  • System 100 includes a decentralized network (DN) 105 and a plurality of clients 210 (X 1; ••• A n ).
  • Decentralized network 105 includes a plurality of parties 110 (B 1 , ••• B n ). 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.
  • 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.
  • 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.
  • 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.
  • IC integrated circuit
  • 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.
  • 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.
  • 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.
  • 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.
  • a client key generation may be implemented by a client DKG module 240 executing in a cloud server using a cloud computing platform.
  • 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.
  • 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.
  • 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.
  • 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.
  • the protocols of the present disclosure may be based on threshold additively homomorphic encryption (TAHE).
  • TAHE may be a dynamic TAHE (DTAHE) to allow for changing voting powers of parties.
  • DTAHE dynamic TAHE
  • FIG 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.
  • 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 (ct sfe ) .
  • network DKG module 140 implements Gen(l K , i, t, n, aux) -> (pk, ski) described previously (where pk may include vk, evk, ct sk )
  • 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.
  • PoS Proof of Stake
  • 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.
  • FIG. 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.
  • 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.
  • Party 1 produces a secret key (sk 1 ) that is proportional to its voting power
  • the voting power of a party may be changed, when the protocols are based on a DTAHE.
  • the voting power of Party 1 is changed from VP 4 to 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 VP 2 to VP 2 ', where AVP 2 ⁇ 0, such that Party 2 decreases its voting power (i.e., VP 2 ' ⁇ VP 2 ).
  • the reconfiguration protocol uses an encryption of the secret key (ct sk ) parameter generated by the DTAHE-DKG protocol, and in another example the reconfiguration protocol does not use ct sk .
  • the first example also supports changing the threshold. This can potentially be used to adjust the resolution of the voting power distribution.
  • 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 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 .
  • 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 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 .
  • PVSS.Dist (pp, ⁇ pk y , ⁇ . feM ; n).
  • the DKG protocol may apply for both an Elliptic Curve Digital Signature Algorithm (ECDSA) and a Schnorr algorithm.
  • ECDSA Elliptic Curve Digital Signature Algorithm
  • Schnorr Schnorr algorithm
  • FIG 7 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 (x A ), and outputs a public key (X).
  • pid party identifier
  • policy policy
  • x A private key share
  • Parties 110 and client 210 may access information from a shared database 190, which may include: an encryption of network share under the TAHE (ct key ), a public key share (X A ), 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).
  • the ECDSA/Schnorr DKG operation is performed on a synchronous communication channel.
  • DKG Protocol - Sync is parameterized with the group description (G, G, q) .
  • the protocol interacts with n + 1 parties A, B lt ••• , B n , 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:
  • Each B t sends (prove, sid, pid t , X t , ctp, xp, p ⁇ to
  • Each B t receives (proof, sid, X B , ct key ) from if not - it receives and outputs the set of corrupted parties and aborts.
  • Each B t receives (decom-proof, pid A , X A ) from ?com-zk’ if not - it aborts.
  • the ECDSA/Schnorr DKG operation is performed on an asynchronous communication channel.
  • DKG Protocol Async is parameterized with the group description (G, G, q) along with an access structure r B , a unique session identifier sid, and an encryption key to a TAHE scheme pk.
  • 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:
  • the distributed party B also records ct feey an encryption of the secret share held by the distributed party B;
  • Each B t does as follows:
  • 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.
  • 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.
  • Figures 8A and 8B are schematic illustrations 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.
  • 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 (R B 0 , R B ,i), and a group of ciphertexts (ct y ), (ct y.feey ), (ct y.feo ), (ct y.fel ) to be used by the client during the online-signing phase for homomorphically evaluating the signature, a public key (X), and a certificate.
  • a shared database 190 may include: two network public nonce shares (R B 0 , R B ,i), and a group of ciphertexts (ct y ), (ct y.fey ), (ct y.feo ), (ct y.fel ) to be used by the client during the online-signing phase for homomorphically evaluating the signature, a public key (X), and a certificate.
  • the presign routine is performed using an ECDSA signature scheme on a synchronous communication channel.
  • Presign Protocol ECDSA/Sync (Presigning n pres : Presign(G, G, qf sid)
  • Presign Protocol ECDSA/Sync interacts with n + 1 parties A, B 1 , --- , B n , where all have pk and ct key as input. Before proceeding, all parties verify that session identifier sid has never been used before, then do as follows:
  • Bi receives (proof, sid, pid A , K ⁇ ) from P ⁇ f Com . if not, it aborts.
  • Bi sends (prove, sid
  • Bi receives (prove, sid
  • Bi records presign, sid, R B , K A , ct 4 , ct 2 , ct 4 ), where ct 4 encrypts y ⁇ k B mod q.
  • the presign routine is performed using a Schnorr signature scheme on a synchronous communication channel.
  • Presign Protocol Schnorr/Sync (Presign n pres : Presign(G, G, q), sid) Presign Protocol Schnorr/Sync interacts with n + 1 parties A, B 1 , ••• , B n . where all parties hold pk and B 1 , --- , B n have ct key as input. Before proceeding, all parties verify that session identifier sid has never been used before, then do as follows:
  • A sends (prove, sid, pid A , K A ; k A , p) to T z L f Com .
  • Bi receives (proof, sid, pid A , K ⁇ ) from E zl f Cmn . if not, it aborts.
  • Bi sends (prove, sid, pidi, Rf; kf) and (prove, sid, pidi. Rf kf) to
  • A receives (proof , sid, R ⁇ ) and (proof , sid, R ⁇ ) from not, it aborts.
  • the presign routine is performed using an ECDSA signature scheme on an asynchronous communication channel.
  • Presign Protocol ECDSA/Async (Presign n pres : Presign ⁇ G, G, q, sid, pk, X, X A , ct key y)
  • Presign Protocol ECDSA/Async is parameterized with the group description (G, G, q) along with an access structure r B , 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 X A , and an encryption of the share of the distributed party of the signing key ct key .
  • a pidA verifies that R B.O , R B ,I 6 (G ⁇ ⁇ 0 ⁇ and ct y , ct y.feey , ct y.feo , ct y.fei e C pk , else it aborts and considers B malicious.
  • Each party B records (sid, X, ct Y , cty. key , ct y.feo , ct y.fei , R B 0 ,
  • the presign routine is performed using a Schnorr signature scheme on an asynchronous communication channel.
  • Presign Protocol Schnorr/Async (Presign n pres : SchPresign(G, G, q, r B , sid, pk))
  • Presign Protocol Schnorr/Async is parameterized with a group description (G, G, q) along with an access structure r B , a unique session identifier sid, and an encryption key to a TAHE scheme pk.
  • the set of parties B can only send messages to parties in A through the functionality B gioba i- broadcaS L-
  • Each party B t outputs:
  • K B O , K B 1 points on the curve equal to k 0 ⁇ G, and k 1 ⁇ G, respectively.
  • the distributed parties also output ct feo , ct fei : encryptions of k Q . k r , respectively
  • 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.
  • Figure 9 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 (x A ), 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.
  • the signing routine is performed using an ECDSA signature scheme on a synchronous communication channel.
  • Sign Protocol ECDSA/Sync interacts with n + 1 parties A, B lt ••• , B n . where all have pk, K ⁇ , R B and R B as input. B 1 , --- , B n has in addition ct key . ct ko , and ct ki as input. A has in addition k A , p, and msg as input.
  • all parties verify that session identifier sid has never been used before, retrieve a corresponding presign output if needed, then do as follows:
  • Bi receives msg and the following proofs, otherwise it aborts: o (proof, sid
  • (c) Bi sends (decrypt, pk, ct A ) and (decrypt, pk, ct 4 ) to ? TAHE and waits for its response.
  • the sign routine is performed using a Schnorr signature scheme on a synchronous communication channel.
  • A calls the random oracle J-C (msg, R A , R B , R B ) and receives p.
  • B t receives msg and z from A, and (proof, sid, pid A , K A , R A ) from Otherwise, it aborts.
  • Bi calls the random oracle SC (msg) and receives m.
  • Bi calls the random oracle SC(m, R A , R B , R B ) and receives p.
  • Bi calls the random oracle SC(R, X, m) and receives e.
  • B t sends (decrypt, pk, ct B ) to ⁇ TAHE and receives (decrypted, pk, ct B , pt B , SIA). Otherwise, it records the malicious parties and aborts.
  • the sign routine is performed using an ECDSA signature scheme on an asynchronous communication channel.
  • 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 r B , 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 X A , an encryption of the share of the distributed party of the private signing key ct key .
  • a pidA does as follows:
  • a pidA receives (global-broadcast, sid, i, (r, s)) from
  • a pidA verifies that (r, s) is a valid ECDSA signature, if the verification fails it aborts and considers B malicious. • Both A pidA and B output (r, s).
  • the sign routine is performed using a Schnorr signature scheme on an asynchronous communication channel.
  • 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.
  • a p id A does as follows:
  • Broadcast Round (a) Receive (decrypted, pk, ct B , pt B ) from E TAHE .
  • ApidA receives (global-broadcast, sld, i, ⁇ J) from global— broadcas •
  • 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.
  • a user may transfer ownership of a resource, such as a digital wallet, to another user.
  • a resource such as a digital wallet
  • FIG 10 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.
  • Sender client 210 receives as input a sender party identifier (pid s ). a receiver party identifier (pid r f a receiver public key (X), and a private key share (x A ). Receiver client 210 receives as input a receiver secret decryption key share (sk r ). and outputs a private key share (x A ). Parties 110 and client 210 may access information from a shared database 190 for a share (Enc pidr (x A y) . Sender client 210 encrypts its private key share (x A ) 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 (Enc pidr (x A )) from database 190 (after verifying the certificate), decrypts the share using its private decryption key, and derives and outputs the sender private key share.
  • pid s sender
  • Transfer Protocol (Transfer Tlrransfer- Transfer ⁇ , G, q, sid, pk, pk Anew ct key )
  • the Transfer Protocol is parameterized with the group description (G, G, q) .
  • the Transfer Protocol interacts with the parties where A old transfers its secret key to A new and ⁇ Bjjes approves this transfer. All parties hold pk, pk ⁇ new , X Aold , X as input, where pk is a public key to the encryption scheme; pk ⁇ new is a public key of A new (which may be accessed from a shared database by querying pid j4new ; X Aold is a public share of A old of a signing key (used to prove to B and to A new that 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: A oid does as follows:
  • the present disclosure may support additive key derivation for ECDSA signatures.
  • At least one of the disclosed protocols discussed herein may include an identifiable abort, where malicious parties causing failure of protocol are identifiable.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • PC personal computer
  • PDA Personal Digital Assistant
  • STB set-top box
  • WPA Personal Digital Assistant
  • 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.
  • main memory 304 e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.
  • DRAM dynamic random access memory
  • SDRAM synchronous DRAM
  • static memory e.g., flash memory, static random access memory (SRAM), etc.
  • secondary memory e.g., a data storage device 328
  • 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.
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • DSP digital signal processor
  • 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).
  • 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
  • signal generation device 320 e.g., a speaker
  • 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.
  • FIG. 12 is a flow diagram of a general method for generating a digital signature, operative in accordance with an embodiment of the present disclosure.
  • AHE DKG is performed.
  • ECDSA/Schnorr presign pool is provided.
  • background processes are performed.
  • ECDSA/Schnorr DKG is performed.
  • ECDSA/Schnorr presign is performed.
  • ECDSA/Schnorr child keys are provided.
  • ECDSA/Schnorr sign is performed.
  • wallet transfer or sharing is performed.
  • a step 419 network reconfiguration is performed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé et système de génération de signature numérique suivant un ou plusieurs protocoles sécurisés sur la base d'un chiffrement homomorphe additif de seuil (TAHE) sur un canal de diffusion, un seuil de parties d'un réseau décentralisé produisant une signature numérique en suivant un protocole sécurisé universellement composable configuré pour délivrer une signature d'algorithme de signature numérique de courbe elliptique (ECDSA) ou une signature de Schnorr. Au moins un client peut coopérer avec le seuil de parties pour générer une signature numérique, ou un seuil de parties peut coopérer pour générer une signature numérique sans client. Le procédé peut consister à générer une clé distribuée (DKG) de chiffrement homomorphique additif (AHE), à présigner ECDSA/Schnorr DKG, ECDSA/Schnorr, à fournir des clés enfants ECDSA/Schnorr, à signer ECDSA/Schnorr, à transférer un portefeuille et/ou à reconfigurer un réseau.
PCT/IB2024/060864 2023-11-08 2024-11-04 2 pc-mpc : signature de seuil ecdsa basée sur un chiffrement homomorphique de seuil Pending WO2025099552A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202363547714P 2023-11-08 2023-11-08
US63/547,714 2023-11-08
US202463700778P 2024-09-30 2024-09-30
US63/700,778 2024-09-30

Publications (1)

Publication Number Publication Date
WO2025099552A1 true WO2025099552A1 (fr) 2025-05-15

Family

ID=95695082

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2024/060864 Pending WO2025099552A1 (fr) 2023-11-08 2024-11-04 2 pc-mpc : signature de seuil ecdsa basée sur un chiffrement homomorphique de seuil

Country Status (1)

Country Link
WO (1) WO2025099552A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120896700A (zh) * 2025-09-25 2025-11-04 山东大学 一种两轮门限ecdsa签名方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180359097A1 (en) * 2017-06-07 2018-12-13 Bar-Ilan University Digital signing by utilizing multiple distinct signing keys, distributed between two parties
WO2020136319A1 (fr) * 2018-12-24 2020-07-02 Orange Procédé et système de vote électronique
US20210067345A1 (en) * 2019-09-04 2021-03-04 Puzzzle Cybersecurity Ltd. Systems and methods for signing of a message

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180359097A1 (en) * 2017-06-07 2018-12-13 Bar-Ilan University Digital signing by utilizing multiple distinct signing keys, distributed between two parties
WO2020136319A1 (fr) * 2018-12-24 2020-07-02 Orange Procédé et système de vote électronique
US20210067345A1 (en) * 2019-09-04 2021-03-04 Puzzzle Cybersecurity Ltd. Systems and methods for signing of a message

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN120896700A (zh) * 2025-09-25 2025-11-04 山东大学 一种两轮门限ecdsa签名方法及系统

Similar Documents

Publication Publication Date Title
CN114586313B (zh) 用于签署一信息的系统及方法
Liu et al. An efficient privacy-preserving outsourced calculation toolkit with multiple keys
Miao et al. Secure multi-server-aided data deduplication in cloud computing
Hassan et al. An efficient outsourced privacy preserving machine learning scheme with public verifiability
CN107342859B (zh) 一种匿名认证方法及其应用
Xie et al. Verifiable federated learning with privacy-preserving data aggregation for consumer electronics
CN110637441A (zh) 应用于数据重复数据删除的加密密钥生成
CN117714065A (zh) 基于群签名和Bulletproofs的高效联盟链隐私保护方法及系统
CN112787796A (zh) 一种边缘计算中检测虚假数据注入的聚合方法及装置
Wu et al. Quantum-resistant blockchain and performance analysis
Behnia et al. Efficient secure aggregation for privacy-preserving federated machine learning
CN115694822A (zh) 基于零知识证明的验证方法、装置和系统、设备及介质
Schulze Darup Encrypted polynomial control based on tailored two‐party computation
CN115336224A (zh) 自适应抗攻击分布式对称加密
CN112436938A (zh) 数字签名的生成方法、装置和服务器
CN112417489B (zh) 数字签名的生成方法、装置和服务器
Sohail et al. Optimizing industrial IoT data security through blockchain-enabled incentive-driven game theoretic approach for data sharing
CN120602083A (zh) 一种基于零知识证明的自随机跨链动态协同监管方法
Wu et al. Identity‐based proxy signature over NTRU lattice
WO2025099552A1 (fr) 2 pc-mpc : signature de seuil ecdsa basée sur un chiffrement homomorphique de seuil
CN113888163A (zh) 基于完全同态加密的智能合约账单记录与处理方法
WO2022116175A1 (fr) Procédé et appareil pour générer une signature numérique et serveur
Zhao et al. SuperFL: Privacy-preserving federated learning with efficiency and robustness
CN119892452B (zh) 一种基于密文策略属性基加密的电力数据隐私安全保护系统、方法和应用
CN121030772A (zh) 一种基于区块链的电力数据管理方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24888164

Country of ref document: EP

Kind code of ref document: A1