Secret sharing redistribution

Abstract

In an embodiment of a first aspect of the present invention, there is provided a computer-implemented method for redistributing (n,t) secret shares of a secret s from a set of dealers to a set of recipients. The (n,t) secret shares comprise n shared secrets, where a threshold t≦n of the shared secrets is sufficient to reconstruct the secret. The method includes a step in which at least a threshold t of dealers each create an (n′,t′) secret share for their respective shared secret, where the (n′,t′) secret share includes n partial shared secrets for their respective shared secrets, where the threshold t′≦n′ of the partial shared secrets is sufficient to reconstruct the recipient's shared secret. The method further includes a step in which at least a threshold t of dealers each create a set of ciphertexts, where the set of ciphertexts includes, for each recipient, an encrypted partial share for one of the n partial shared secrets for their respective shared secret, and the encrypted partial shared secrets are encrypted for each recipient's public encryption key. The public encryption key is a key in a public key encryption scheme. The method further comprises the steps of each of at least a threshold number t of dealers jointly generating a non-interactive zero-knowledge proof in which a set of ciphertexts includes a redistribution of their shared secret, and distributing the dealing to an unspecified set of recipients, the dealing including the set of ciphertexts and corresponding non-interactive zero-knowledge proofs for the set of recipients.

Description

[Technical field]

[0001] The present invention relates to a computer-implemented method for redistribution of an existing secret share from a set of dealers to a set of recipients.

[0002] Further aspects relate to a distributed network encoded on a non-transitory medium, nodes of the distributed network, corresponding computer program products, and software architectures. [Background technology]

[0003] In a distributed network, multiple nodes are distributed. In distributed network computing, software and data are distributed across multiple nodes. The nodes constitute the computing resources, and the distributed network may use distributed computing (Link) techniques.

[0004] An example of a distributed network is a blockchain network, which is a consensus-based electronic ledger based on blocks. Each block contains multiple transactions and other information. Additionally, each block contains a hash of the previous block, such that blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain. Transactions may include, for example, small programs known as smart contracts.

[0005] In order for a transaction to be written to the blockchain, it must be "verified" by the network. In other words, the network nodes must reach a consensus on the block that will be written to the blockchain. Such consensus can be achieved by various consensus protocols.

[0006] One form of consensus protocol is the proof-of-work consensus protocol, which generally requires work from multiple parties participating in the consensus protocol, which typically corresponds to computational time.

[0007] Proof-of-work based cryptocurrency systems like Bitcoin® verify transactions and create new blocks by solving computationally intensive puzzles.

[0008] Another form of consensus protocol is the Proof of Stake protocol. Such a Proof of Stake protocol has the advantage of not requiring time-consuming, energy-intensive calculations. In a Proof of Stake based blockchain network, for example, the creator of the next block is selected through a combination of random selection, as well as the stake of each node in the network.

[0009] Beyond cryptocurrencies, decentralized networks can be used in a variety of other applications, in particular, they can be used to provide decentralized and distributed computing power and services.

[0010] One of the problems in a distributed network is providing an efficient and secure method of key management for the nodes of the network.

[0011] The decentralized network uses public key cryptography to, among other things, encrypt and decrypt messages and / or issue and verify digital signatures.

[0012] When changing the network configuration, it is also desirable for security reasons to re-share or re-distribute the keying material associated with the encryption and decryption schemes used, in particular the secrets of the keying material. Summary of the Invention [Problem to be solved by the invention]

[0013] One objective of an embodiment of the present invention is to provide an improved method for redistribution of existing secret shares, particularly in terms of efficiency and / or security. [Means for solving the problem]

[0014] In one embodiment of the first aspect of the present invention, there is provided a computer-implemented method for redistribution of (n,t) secret shares of a secret s from a set of dealers to a set of recipients. The (n,t) secret shares comprise n shared secrets, and a threshold t≦n of the shared secrets is sufficient to reconstruct the secret. The method comprises performing a step of creating (n′,t′) secret shares for each of at least a threshold t number of dealers for their respective shared secrets, the (n′,t′) secret shares comprise n′ partial shared secrets for each of their respective shared secrets, and a threshold t′≦n′ of the partial shared secrets is sufficient to reconstruct the shared secret. The method further comprises a step of creating a set of ciphertexts for each of at least a threshold t number of dealers, the set of ciphertexts comprising, for each recipient, one encrypted partial share of the n partial shared secrets for each shared secret, and the encrypted partial shared secrets are encrypted for each recipient's public encryption key. The public encryption key is a key of a public key encryption scheme. The method further comprises the steps of each of at least a threshold number t of dealers jointly generating a non-interactive zero-knowledge proof in which a set of ciphertexts includes a redistribution of their shared secret, and distributing the dealing to an unspecified set of recipients, the dealing including the set of ciphertexts and corresponding non-interactive zero-knowledge proofs for the set of recipients.

[0015] Some embodiments of the method allow for re-sharing or redistribution of existing secret shares from a set of dealers to a set of recipients. Thus, methods according to some embodiments of the present invention provide a way to redistribute secret shares from multiple dealers to multiple recipients.

[0016] In such an embodied method, the redistribution of secret shares may be performed in an efficient and secure manner. More specifically, the encrypted partial shares and corresponding zero-knowledge proofs are distributed to an unspecified number of parties to facilitate efficient communication between a set of dealers and a set of recipients. In particular, the redistribution may be performed in a non-interactive manner, i.e., each of the dealers generates only a single dealing and distributes this single dealing to an unspecified set of recipients that read the distributed dealing.

[0017] No further interaction is required between a set of dealers and a set of recipients apart from the general distribution, including no bilateral communication between dealers and recipients and no mutual dissatisfaction.

[0018] In particular, no interaction between recipients is required: recipients can verify the distributed dealings independently of each other, without the need to interact with anyone.

[0019] The non-interactive nature of the embodied method, in particular the property that the receivers do not need to interact with anyone, is facilitated by, among other things, providing a separate non-interactive zero-knowledge proof for each single dealing by each respective dealer. A non-interactive zero-knowledge proof guarantees that each receiver can decrypt and obtain its correct share. Thus, a set of receivers can verify the correctness of the secret sharing in an independent manner.

[0020] In some embodiments, a non-interactive zero-knowledge proof is defined as a zero-knowledge proof that is constructed such that a set of recipients does not need to interact with anyone, i.e., the prover, and does not need to interact with other recipients in order to verify the proof.

[0021] A zero-knowledge proof provides evidence that the set of ciphertexts jointly contains a redistribution of each of the dealers' shared secret. In other words, a zero-knowledge proof provides evidence that the set of ciphertexts generated by each dealer contains a share of the dealers' shared secret, i.e., that the set of ciphertexts is a valid encryption of the correct shared secret.

[0022] In one embodiment, the method further includes a step in which a set of predefined parties, in particular a set of recipients, checks the non-interactive zero-knowledge proofs of the dealing. If a sufficient number of proofs are successfully checked, or if a sufficient number of recipients are successfully checked, each of the recipients may decrypt the encrypted partial shares across the dealing. In other words, each recipient may receive and decrypt one partial share from each of the dealings that the set of dealers distributed to an unspecified number of parties. Each of the recipients may then combine the decrypted partial shares into a secret new shared secret.

[0023] In other embodiments, each of the zero-knowledge proofs is constructed in a non-interactive manner such that each of the dealers can create its zero-knowledge proof without interacting with any of the other dealers.

[0024] Thus, in one such embodiment, a non-interactive zero-knowledge proof is a proof that is constructed such that neither the receiver nor the dealer need to interact with each other, and need not interact with the receiver except to create an output that is subsequently distributed to an unspecified number of receivers.

[0025] This further increases efficiency.

[0026] In a further embodiment, the zero-knowledge proof is a publicly verifiable zero-knowledge proof. A publicly verifiable zero-knowledge proof may be defined as a proof that can be verified by anyone, in particular any interested party. Thus, once a deal is completed and distributed to the general public, anyone can verify the proof that the deal is correct and that all recipients were able to get their correct share from the deal.

[0027] In one embodiment, the secret sharing is linear secret sharing, specifically Shamir secret sharing.

[0028] In one embodiment, the method includes the steps of each dealer creating relevant public key material of its secret share and its shared secret of said shared secret, and adding the relevant public key material to the dealing.

[0029] In general, relevant public key material can be defined as material that has secret sharing capabilities.

[0030] The associated public key material may, in some embodiments, include public group elements associated with or corresponding to the secret shares created by each dealer.

[0031] The associated public key material may, in an embodiment, include public group elements that relate to or are associated with the respective dealer's shared secret.

[0032] In one embodiment, the secret to which the dealer has a secret share is the private key that corresponds to the public verification key in a public key signature scheme.

[0033] In one embodiment, the method further includes the step of any participant or party, and in particular the recipient, creating from the set of dealer-created associated public key material related to the recipient's new secret share and the recipient's new shared secret.

[0034] In some embodiments, the new associated public key material may be calculated by Lagrangian interpolation.

[0035] In one embodiment, creating the new associated public key material includes deriving the new associated public key material from associated public key material created by a set of dealers.

[0036] In some embodiments, the new associated public key material may include a public shared verification key associated with the recipient's new shared secret.

[0037] In some embodiments, the new associated public key material may include a public verification key associated with the private key.

[0038] In some embodiments, the new associated public key material may include the recipient's public shared verification key and / or elements from which the public verification key can be derived.

[0039] In a public-key signature scheme, a public verification key can be used to verify signatures, particularly threshold signatures, that have been jointly generated by a set of recipients with a new shared secret.

[0040] The public shared verification key can then be used to verify each individual signature generated by each recipient using the new shared secret.

[0041] In one embodiment, the method further comprises using a public key encryption scheme with selected ciphertext attack security to encrypt the recipient's partial shared secret.

[0042] This further increases the security of the method.

[0043] In one embodiment, the method further comprises using a public key cryptography scheme with forward secrecy to encrypt the partial shared secret for the recipient.

[0044] In such encryption schemes with forward secrecy, time is divided into periods and messages or partial shares are encrypted in specific periods. In a corresponding redistribution scheme of secret sharing, a set of recipients can update their decryption keys to match the current period, and recipients can delete decryption keys for previous periods. Such a scheme ensures that even if a recipient is compromised, it will not be able to decrypt old ciphertexts that contain partial shares of the secret for past periods.

[0045] This increases the security of the method.

[0046] In some embodiments, the forward secrecy encryption scheme may be implemented as a binary tree encryption scheme. Such a binary tree encryption scheme takes a plaintext as input and encrypts it into the leaves of a binary tree of height λ. A decryption key may be associated with each leaf, whose holder may recover the plaintext. There are also decryption keys associated with the internal nodes. The decryption key of an internal node may be used to derive decryption keys for all children of that node. That is, if you have the root decryption key, you can derive the decryption keys for all leaves. However, if you do not have the root decryption key, you may only decrypt the ciphertext associated with the leaves of the subtree of the decryption key you hold.

[0047] In a further embodiment, the method includes performing decryption of the encrypted partial share on the virtual hardware security module or on the hardware security module, in particular on a separate process.

[0048] Being provided with such a hardware security module may prevent an adversary from learning the decryption key. In one such embodiment, the decryption process, including storage of the decryption key, is performed within a hardened, tamper-resistant environment. In some embodiments, the hardware security module includes one or more secure cryptographic processors.

[0049] In some embodiments, the combination of such a hardware security module and a public key encryption scheme with CCA security provides an encryption scheme with proactive security.

[0050] In some embodiments, the public key encryption scheme is a multi-recipient encryption scheme configured to encrypt the dealer's partial share into a set of recipients' public encryption keys.

[0051] In some embodiments, the multi-recipient encryption scheme uses shared randomness to encrypt partial shares of each of a set of dealers into the public encryption keys of a set of recipients, which is particularly efficient.

[0052] In some embodiments, the encryption scheme is configured to perform chunk encryption of multiple partial shares, each of which is split into multiple plaintexts, particularly small plaintexts, in other words plaintexts of moderate size each representing a chunk.

[0053] In one embodiment, the method includes the pair of dealers generating a further non-interactive zero-knowledge proof, the further zero-knowledge proof configured to prove the correctness of the chunk encryption. The further zero-knowledge proof may also be represented as a second zero-knowledge proof. The proof that the pair of ciphertexts jointly include a redistribution of a shared secret may be represented as a first zero-knowledge proof. In an embodiment, the first zero-knowledge proof and the second zero-knowledge proof may also be combined into one common proof.

[0054] In one embodiment, the step of broadcasting the deal to the general public includes placing the deal on a bulletin board, i.e., a permanent digital record readable by the recipients, in some embodiments such a bulletin board can be implemented, for example, via a blockchain or distributed ledger.

[0055] In some embodiments, the message board is configured so that deals placed on the message board cannot be deleted.

[0056] In some embodiments, the bulletin board is configured so that dealing authenticates senders.

[0057] In some embodiments, the bulletin board is configured to allow for a defined order of deals to be placed on the bulletin board.

[0058] In one embodiment of another aspect, a distributed network is provided that includes a plurality of nodes configured to execute a computer-implemented method for redistribution of (n,t) secret shares of a secret from a set of dealers to any of the embodiments described above.

[0059] In one embodiment of another aspect of the present invention, a node of a distributed network is provided.

[0060] In one embodiment of another aspect of the present invention, there is provided a computer program product for operating a distributed network, the computer program product comprising a computer readable storage medium having program instructions embodied therein, the program instructions being executable by one or more of a plurality of nodes of the distributed network, causing one or more of the plurality of nodes to perform steps of a method aspect of the present invention.

[0061] In one embodiment of another aspect of the present invention, a computer program product for operating a node of a distributed network is provided.

[0062] In one embodiment of another aspect of the invention, there is provided a software architecture encoded on a non-transitory computer readable medium, the software architecture configured to operate on one or more nodes of a distributed network, the encoded software architecture comprising program instructions executable by one or more of the plurality of nodes to perform a method comprising steps of the method aspect of the invention.

[0063] Features and advantages of one aspect of the invention may be applied to other aspects of the invention, where appropriate.

[0064] Further advantageous embodiments are recited in the dependent claims and in the following description.

[0065] For a better understanding of the invention, and further objects thereof as will become apparent from the following detailed description, reference should be made to the accompanying drawings, in which: [Brief description of the drawings]

[0066] [Figure 1] FIG. 1 is an exemplary block diagram of a distributed network in accordance with one embodiment of the present invention. [Diagram 2]FIG. 2 is a diagram showing changes in a subnetwork over time. [Diagram 3] FIG. 3 is a table showing the correspondence between a subnet secret or set of secret keys and the evolution of a set of recipient decryption keys. [Figure 4] FIG. 4 shows in more detail the computational units running on the nodes of the network. [Diagram 5] FIG. 5 illustrates the creation and general distribution of a deal of a method for redistributing a shared secret. [Figure 6] FIG. 6 is a diagram showing the procedure and possible combinations for the recipient of the dealing in FIG. 5 to verify and decrypt the new shares from the dealing distributed to an unspecified number of people. [Figure 7] FIG. 7 illustrates the creation and public distribution of a dealing method for redistribution of a shared secret using multi-recipient encryption. [Figure 8] FIG. 8 is a diagram showing the procedure for the recipient of the dealing in FIG. 7 to verify and decrypt the new shares from the dealing distributed to an unspecified number of people, and possible combinations. [Figure 9] FIG. 9 is a flow chart illustrating method steps of a method according to one embodiment of the present invention. [Figure 10] FIG. 10 is a flow chart illustrating further method steps of a method according to an embodiment of the present invention. [Figure 11] FIG. 11 illustrates an embodiment of a verification key and its corresponding shared secret key that may be used in accordance with some embodiments of the present invention. [Figure 12] FIG. 12 is a more detailed block diagram of a network node according to some embodiments of the invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0067] First, some general aspects and terminology of embodiments of the present invention are introduced.

[0068] In some embodiments, a distributed network includes multiple nodes arranged in a distributed manner. In such distributed network computing, software and data are distributed across multiple nodes. The nodes constitute the computing resources, and the distributed network may use distributed computing (Link) techniques, among others.

[0069] In some embodiments, the distributed network may be specifically embodied as a blockchain network. The term "blockchain" is intended to include all forms of electronic, computer-based, distributed ledgers. In some embodiments, the blockchain network may be embodied as a proof-of-work blockchain network. In other embodiments, the blockchain network may be embodied as a proof-of-stake blockchain network.

[0070] Participants: Implemented as pieces of software on separate physical machines and assumed to have network access to communicate with each other.

[0071] Dealer: A pair of participants.

[0072] Receiver: Another set of participants, who may or may not overlap with the set of dealers.

[0073] Linear secret sharing: A secret sharing scheme in which shares can be computed using matrix operations on a matrix M applied to a secret s and some random group elements r, i.e., (s1, ..., sn) = (s, r1, ..., r-1)M.

[0074] Shamir secret sharing: A type of threshold secret sharing scheme. Shamir secret sharing is linear.

[0075] The verification key is a bit string of the public key signature scheme that is intended to be publicly available. The verification key may also be referred to as a public key and may be used, for example, to verify the digital signature of the public key signature scheme.

[0076] A public encryption key is a string of bits used in public key cryptography.

[0077] A public key signature scheme according to some embodiments of the present invention may include, for example, keys of a public key signature and encryption scheme such as RSA, or keys of a public key signature scheme such as Schnorr or DSA.

[0078] Private Key (sk): A string of bits associated with a public key, especially a verification or encryption key, that enables some cryptographic operations to be performed, especially to digitally sign a message and / or decrypt ciphertext.

[0079] Distributed Key Generation (DKG): A protocol that allows a set of dealers to generate public keys, specifically verification keys, and provide a set of recipients with a shared secret or shared private key for the corresponding private keys.

[0080] Secret redistribution protocol: The secret redistribution protocol may also be referred to as the secret redistribution protocol. This protocol updates a shared secret of a secret key, or more generally, a shared secret of a secret. In some embodiments, the protocol may provide a new or updated secret share to a previous holder of the secret share. In some other embodiments, the protocol may provide a new or updated secret share to a new, and in particular, different, set of recipients.

[0081] (n,t) threshold key or threshold private key: Such a threshold key has a threshold t and some number of shared private keys s1,...,sn such that any of the t shared private keys allows reconstruction of the private key, but the (t-1) shared private keys are insufficient to determine the private key. In a threshold public key signature scheme, any of the t shared private keys allows valid signatures to be made under the threshold public key or verification key, but the (t-1) shares are insufficient to make a valid signature.

[0082] (n,t) secret share of a secret: A share that contains n shared secrets, where a threshold t≦n of the shared secrets is sufficient to reconstruct the secret, while t−1 shares are insufficient to determine the secret.

[0083] Verifiable Secret Sharing (VSS): A protocol that allows a single dealer to generate a random secret s, threshold secret shares s1,…,sn for a set of recipients, and proofs that each recipient can use to verify the validity of each shared secret si.

[0084] Proactive Security: A security concept that captures a multi-party system that tolerates the compromise of t-1 parties at any time. Time is divided into periods, and in each period, at most t-1 parties are compromised, but the attacker is fluid in that the set of compromised parties may differ from period to period.

[0085] A distributed key management system with proactive security can be created by dividing time into periods and using a new threshold secret share of the private key in each period.

[0086] Public-key encryption with forward secrecy: A public-key encryption scheme in which time is divided into periods and the private decryption key changes with time, so that even if it is compromised, it cannot help decrypt ciphertext from previous periods.

[0087] Bulletin Board: A system that distributes incoming messages to all interested parties. Bulletin boards can be implemented, for example, via a blockchain or distributed ledger. Bulletin boards can also be referred to as ledgers. In some embodiments, messages placed on a bulletin board cannot be deleted, they have authenticated senders, and have a well-defined order.

[0088] Non-Interactive Zero-Knowledge (NIZK) Proof: A proof or proof system in which a single party (the prover) generates a cryptographic proof of a claim (statement) that allows at least one set of recipients (the verifiers) to verify that the claim is true, but without learning anything (zero knowledge) about why it is true (the witnesses). Furthermore, the set of recipients does not need to interact with anyone, i.e., the prover or any other recipients, to verify the proof.

[0089] Binary tree encryption method: This method takes plaintext as input and encrypts it into the leaves of a binary tree of height λ.

[0090] Such a binary tree encryption scheme is described, for example, in Ran Canetti, Shai Halevi, Jonathan Katz: A Forward-Secure Public-Key Encryption Scheme. J. Cryptology (2007) 20, 265-294.

[0091] Multi-recipient encryption scheme: A scheme in which there is a set of n recipients 1,...,n. Each of the i recipients holds a private decryption key and a public key pair, denoted (dki,pki). The sender then obtains a ciphertext C by encrypting a set of messages M1,...,Mn, Mi, destined for recipient i, using pk1,...,pkn. When recipient i receives the ciphertext C, it obtains the message Mi by decrypting it using its decryption key dki.

[0092] FIG. 1 illustrates an exemplary block diagram of a distributed network 100 in accordance with one embodiment of the present invention.

[0093] The distributed network 100 comprises a number of nodes 10, which may also be denoted as network nodes 10. The nodes 10 are distributed across a number of subnetworks 11, which may also be referred to as subnets. In the example of Figure 1, four subnetworks 11 are provided, denoted SNA, SNB, SNC, and SND.

[0094] Each of the multiple subnets 11 is configured to execute a set of computational units on each node 10 of the respective subnet 11. In some embodiments, a computational unit may be understood as a piece of software, and in particular, a piece of software that includes or maintains its own unit state. The unit state may also be referred to as an execution state.

[0095] Network 100 comprises communication links 12 for intra-subnet communication within each subnet 11, in particular the exchange of intra-subnet inter-unit messages between computing units assigned to the same subnet.

[0096] Furthermore, network 100 comprises a communication link 13 for implementing inter-subnet communication between different ones of subnets 11, in particular inter-subnet inter-unit messages exchanged between computing units assigned to the different subnets.

[0097] Thus, communication link 12 may also be denoted as an intra-subnet or peer-to-peer (P2P) communication link, and communication link 13 may also be denoted as an inter-subnet or subnet-to-subnet (SN2SN) communication link.

[0098] Network 100 is configured to exchange inter-unit messages between the computing units of the network through a messaging protocol in accordance with subnet assignments.

[0099] In some embodiments, the distributed network may be configured to exchange inter-subnet messages 16 between the subnets SNA, SNB, SNC, and SND, in particular through a messaging protocol. The inter-subnet messages 16 may be embodied as inter-subnet inter-unit messages 16a exchanged between computing units assigned to different subnets according to subnet assignments, in particular. For example, the network 100 may be configured to exchange unit-to-unit messages 16a between a computing unit CUA1 as a sending computing unit operating on the subnet SNA and a computing unit CUB2 as a receiving computing unit operating on the subnet SNB (see FIG. 4). Furthermore, the inter-subnet messages 16 may be embodied as signaling messages 16b. The signaling messages 16b may include an acknowledgment message (ACK) adapted to acknowledge the acceptance or receipt of the unit-to-unit message, or a non-acknowledgement message (NACK) adapted to not acknowledge the acceptance (corresponding to a rejection) of the unit-to-unit message, for example to indicate a transmission failure.

[0100] In some embodiments, the unit state or execution state may be understood as all data or information that the computing unit uses, in particular the data that the computing unit stores in variables, but also the data that the computing unit obtains from remote calls. The unit state may represent, in particular, storage locations in the respective memory locations of the respective nodes.

[0101] In some embodiments of the present invention, subnets 11 are configured to replicate a set of computing units across each subnet 11. More specifically, subnets 11 are configured to replicate the unit state or execution state of the computing units across each subnet 11.

[0102] Network 100 may include multiple interfaces 101 that may be used to exchange information with users U of the distributed network. As an example, users U may send read requests to the distributed network through interfaces 101 and receive read responses, e.g., execution status information including computation results. In some preferred embodiments, users do not need to know the internal structure of distributed network 100. In particular, users preferably do not need to be aware of the subnetwork configuration or the individual subnets that are processing the user's read requests.

[0103] Subnet 11 may be reconfigured over time. More specifically, the number of nodes in subnet 11 may change over time. As an example, nodes may be added to subnet 11 and / or nodes may be removed from subnet 11. Thus, subnet 11 includes a changeable set of nodes.

[0104] Each of the subnets 11 holds an individual, or in other words separate, static verification key of the public key signature scheme. In this embodiment, the subnet SNA holds a static verification key pkA, the subnet SNB holds a static verification key pkB, the subnet SNC holds a static verification key pkC, and the subnet SND holds a static verification key pkD. The static verification keys may be generally referred to as pkX, below, where X denotes the corresponding subnet. In the embodiment, the static verification key pkX is constant, in other words fixed for the entire lifetime of the respective subnet 11.

[0105] A static verification key pkX and the corresponding shared secret may first be generated via a distributed key generation protocol.

[0106] Although the static verification key pkX of the network 100 does not change over time, the corresponding shared secret key si may change over time.

[0107] Such changes in the shared secret key may be performed when the set of nodes in each subnet changes, or may be performed without changing the nodes in the subnet, the latter of which may be used when providing proactive security.

[0108] Changing or updating the shared secret key can be performed by secret sharing, in other words by a secret redistribution protocol.

[0109] The distributed key generation protocol may in particular be a threshold key generation protocol. The secret redistribution protocol may in particular be a threshold secret redistribution protocol.

[0110] The distributed key generation protocol may generate corresponding first shared secret sets s1, s2, sn, i.e., corresponding to the respective static verification keys pkX and secrets. The first set of shared secret keys may be assigned to a first set of nodes in each subnet. The first set of shared secrets may be used when issuing signatures that can be verified using the static verification keys. The first set of nodes may be the nodes in each subnet at time t0 or at time period e0. The time may be, for example, the creation time of each of the subnets. The verification keys pkX are verification keys of the public key signature scheme. Thus, the verification keys pkX may be used when verifying joint signatures created by the respective nodes holding the shared secrets s1, s2, ..., sn.

[0111] When changing the shared secret key, the distributed network 100 executes a secret redistribution protocol. As mentioned above, the secret redistribution protocol may be a threshold protocol, among others, and may be generally embodied as a method for redistributing (n,t) secret shares of a secret s from a set of dealers to a set of recipients. The set of dealers and the set of recipients may be nodes of a distributed network, among others. Thus, the secret redistribution protocol may redistribute a first set of shared secrets of the nodes of each subnet to a second set of nodes of each subnet. This creates a second set of shared secrets corresponding to the same static verification key of each subnet. As a result, each node or subset of the second set of nodes holds one of the second set of shared secrets to share.

[0112] Nodes of the decentralized network 100 may, in some embodiments, use threshold signatures to certify results produced by the decentralized network 100.

[0113] Nodes in the distributed network 100 may use long-term public encryption keys to minimize interactions.

[0114] This is explained in more detail with reference to Figures 2 and 3. Figure 2 shows the evolution of a subnet SNA over time. The table in Figure 3 shows a corresponding table containing the corresponding evolution of the set of secret keys of the subnet SNA.

[0115] Referring to FIG. 2, the subnet SNA initially has a subnet configuration 201 at time t0, for example, at its creation. Each subnet configuration is valid for a corresponding period e0. In the subnet configuration 201, the subnet SNA comprises four nodes N1, N2, N3, N4. The subnet SNA has a static verification key pkA of a public key signature scheme. The nodes N1, N2, N3, and N4 constitute a set of first nodes, or in other words, a set of initial nodes. Each node of the distributed network 100 registers a public encryption key with the distributed network 100. Other nodes or users of the distributed network 100 may use this public encryption key to encrypt messages to the node throughout the node's lifetime.

[0116] Therefore, nodes N1, N2, N3, and N4 have registered public encryption keys pkN1, pkN2, pkN3, and pkN4, respectively. In addition, nodes N5, N6, and N7 in the future network configuration have registered public encryption keys pkN5, pkN6, and pkN7. These public encryption keys are also used for a long time, so they can be called static encryption keys.

[0117] While the static verification key pkA, the static verification keys pkN1, pkN2, pkN3, pkN4, pkN5, pkN6, and pkN7 are used for a long period of time, the shared secret key si and the decryption keys dkN1, dkN2, dkN3, dkN4, dkN5, dkN6, and dkN corresponding to the static verification keys pkN1, pkN2, pkN3, pkN4, pkN5, pkN6, and pkN may change over time. More specifically, in some embodiments, time is divided into multiple periods, and the decryption keys and the shared secret keys are changed periodically and are used or valid only for a certain period of time. In the following, the shared secret key si is indicated simply as the shared secret is si.

[0118] 3, the left column 301 contains a corresponding number of nodes of the subnet SNA, more specifically, nodes N1, N2, N3, N4, N5, N6, and N7. Columns 302, 303, 304, 305, and 306 contain the respective shared secrets of the corresponding nodes at different times. More specifically, column 302 corresponds to a period e0 extending from time t0 to time t1, column 303 corresponds to a period e1 extending from time t1 to time t2, column 304 corresponds to a period e2 extending from time t2 to time t3, column 305 corresponds to a period e3, and column 306 corresponds to a period e4. Lines 311, 312, 313, 314, 315, 316, and 317 contain the shared secrets of nodes N1, N2, N3, N4, N5, N6, and N7, respectively, and the composite keys of each node.

[0119] As mentioned above, the subnet SNA's public verification key pkA and the corresponding secret s, which may also be denoted as the private signing key sk, remain constant.

[0120] During time period e0, nodes N1, N2, N3, and N4 of subnet SNA hold shared secrets s1,0, s2,0, s3,0, and s4,0, respectively. In this notation, the first number in the subscript denotes the respective node, and the second number in the subscript denotes the respective time period. Shared secrets s1,0, s2,0, s3,0, and s4,0 can be thought of as initial shares generated, for example, using a distributed key generation protocol.

[0121] In the subsequent time period e1, the subnet SNA still has the same set of nodes, but the distributed network has nevertheless redistributed the shared secrets s1,0, s2,0, s3,0 and s4,0 to a second set of nodes, in this example formed by the same set of nodes N1, N2, N3 and N4.

[0122] The redistribution creates or generates a second set of shared secrets s1,1, s2,1, s3,1, and s4,1 that are different from the first set. The second set of shared secrets corresponds to the same static verification key pkA of the subnet SNA and to the same secret s that corresponds to the static verification key pkA.

[0123] The secret redistribution protocol for redistributing shared secrets s1,0, s2,0, s3,0, and s4,0 to s1,1, s2,1, s3,1, and s4,1 is described in more detail with reference to FIGS.

[0124] As mentioned above, in general, shares are redistributed from a set of dealers to a set of receivers. In this example, the set of dealers is the same as the set of receivers and is formed by nodes N1, N2, N3, and N4, respectively. In the following, when nodes N1, N2, N3, and N4 act as dealers, we denote them as D1, D2, D3, and D4. Similarly, when they act as receivers, we denote them as R1, R2, R3, and R4.

[0125] Thus, dealers D1, D2, D3, and D4 aim to redistribute their shared secrets of period e0 to receivers R1, R2, R3, and R4 for the next period e1.

[0126] Assuming that the secret sharing threshold t is 3, at least three of the n dealers D1, D2, D3, and D4 perform the following steps. In Figures 5 and 6, it is assumed that all dealers D1, D2, D3, and D4 perform these steps.

[0127] First, dealers D1, D2, D3, and D4 create a (3,4) secret share for each shared secret, or typically an (n',t') secret share that contains n' partial shared secrets for each shared secret. In general, a threshold of secret partial shares t'≦n' is assumed to be a number sufficient to reconstruct the shared secret, and in this example, three of the four partial shares are assumed to be a number sufficient to reconstruct the shared secret.

[0128] For example, dealer D1 (node ​​N1) creates four partial shares ss1,0,1, ss1,0,2, ss1,0,3, and ss1,0,4 of share s1,0. In this notation, the final subscript indicates the respective recipient of the partial share.

[0129] The four partial shares are each encrypted to a different one of the recipients R1, R2, R3, and R4. More specifically, the dealer D1 creates a set of ciphertexts that comprises, for each recipient, a partial share encrypted for the shared secret s1,0. (It is now clear that the four people receive separate partial shares in an encrypted format.)

[0130] In one embodiment, the dealer uses an encryption scheme with forward secrecy. That is, the dealer encrypts the partial share for a specific period τ. Therefore, it is mandatory for the node acting as the receiver to update the decryption key to match the current period and delete the decryption key for the old period. In this way, even if a node is compromised, it cannot decrypt old ciphertexts for past periods. This reduces the information that an attacker can learn.

[0131] In the example of Fig. 5, partial share ss1,0,1 is encrypted with public encryption key pkR1,1 for the next period e1 such that the corresponding decryption key dkR1,1 of recipient R1 is only valid for the next period e1. The first subscript of the encryption and decryption keys indicates the respective recipient and the second subscript indicates the period. Partial share ss1,0,2 is encrypted in a corresponding procedure with public encryption key pkR2,1 for the next period e1 such that the corresponding decryption key dkR2,1 of recipient R2 is only valid for period e1. Partial shares ss1,0,3 and ss1,0,4 are encrypted with public encryption key pkR2,1 for the next period e1 such that the corresponding decryption key dkR3,1 of recipient R3 and the corresponding decryption key dkR4,1 of recipient R4 are only valid for period e1. This allows dealer D1 to create four ciphertexts, (ss1,0,1)pkR1,1, (ss1,0,2)pkR2,1, (ss1,0,3)pkR3,1, and (ss1,0,4)pkR4,1, which make up a set of ciphertexts 501. The subscripts of the terms in parentheses indicate the public encryption key used and the time period covered by the decryption.

[0132] For example, the ciphertext (ss1,0,1)pkR1,1 is encrypted with the encryption key pkR1,1 of the receiver R1 (corresponding to the node N1) for the period e1, and can therefore be decrypted by the receiver R1 using the decryption key for the period e1, and the ciphertext (ss1,0,2)pkR2,1 can be decrypted by the receiver R2 using the decryption key for the period e1.

[0133] In a corresponding procedure, the other nodes N2, N3, and N4, in their capacity as dealers, also create four partial shares for each share of period e0 and encrypt each of these four partial shares to one of the recipients R1, R2, R3, and R4. As a result, dealers D2, D3, and D4 have created a set of ciphertexts 502, 503, and 504.

[0134] Additionally, each of the dealers D1, D2, D3, and D4 jointly generate a zero-knowledge proof in which a set of ciphertexts contains a redistribution of the shared secret. Zero-knowledge proofs may be non-interactive zero-knowledge proofs (NIZK), which are specifically embodied as proofs that do not require any interaction between the recipient and any other person; that is, they can be verified independently by each of the recipients. Non-interactive zero-knowledge proofs may be publicly verifiable, such that anyone, recipient or non-recipient, can verify them.

[0135] For example, dealer D1 creates a non-interactive zero-knowledge proof NIZKD1 that contains the four encrypted partial shares (ss1,0,1)pkR1,1, (ss1,0,2)pkR2,1, (ss1,0,3)pkR3,1, and (ss1,0,4)pkR4,1 along with a redistribution of share s1,0. Correspondingly, the other dealers D2, D3, and D4 create non-interactive zero-knowledge proofs 512, 513, and 514.

[0136] Additionally, each of dealers D1, D2, D3, and D4 may generate several associated public key material APKMD1 521, APKMD2 522, APKMD3 523, and APKMD4 524.

[0137] Dealers D1, D2, D4, and D5 then each distribute a deal to an unspecified number of recipients R1, R2, R3, and R4, each of which includes a set of ciphertexts for a set of recipients, corresponding zero-knowledge proofs, and associated public key material.

[0138] Referring to FIG. 5, dealer D1 distributes to an unspecified number of parties a dealing DL1, 531, which contains four encrypted partial shared secrets (ss1,0,1)pkR1,1, (ss1,0,2)pkR2,1, (ss1,0,3)pkR3,1, and (ss1,0,4)pkR4,1, a non-interactive zero-knowledge proof NIZKD1, and associated public key material APKMD1.

[0139] Similarly, dealer D2 distributes to the public a dealing DL2, 532 that contains the four encrypted partial shared secrets (ss2,0,1)pkR2,1, (ss2,0,2)pkR2,1, (ss2,0,3)pkR3,1, and (ss2,0,4)pkR4,1, the non-interactive zero-knowledge proof NIZKD2, and the associated public key material APKMD2. Dealer D3 and dealer D4 distribute to the public a dealing DL3, 533 and dealing DL4, 534, respectively.

[0140] General distribution may be accomplished by placing the dealings DL1, DL2, DL3, and DL4 of four dealers D1, D2, D3, and D4, respectively, on a bulletin board 50. The bulletin board 50 may be accessed by at least one set of recipients, in this example, recipients R1, R2, R3, and R4. In some embodiments, the bulletin board may be publicly available. In some embodiments, the bulletin board may be implemented as a distributed ledger.

[0141] FIG. 6 shows a procedure in which receivers R1, R2, R3, and R4 reconstruct new shares from information posted on bulletin board 50 that has been distributed to an unspecified number of people.

[0142] First, receivers R1, R2, R3, and R4 inspect or verify the non-interactive zero-knowledge proofs NIZKD1, NIZKD2, NIZKD3, and NIZKD4 of dealings DL1, DL2, DL3, and DL4, respectively. In some embodiments, each of the receivers may inspect or verify the proofs. In other embodiments, an assigned set of receivers, or more generally, an assigned set of parties, may inspect the proofs and provide verification confirmation of the proofs to the set of receivers.

[0143] Once a sufficient number of proofs have been successfully checked or verified, receivers R1, R2, R3, and R4 may begin reconstructing their new shares. In the example of Figures 5 and 6, only three of the four proofs need to be successfully checked or verified. This is indicated by the cross-out symbol on each fourth share.

[0144] Each of the four receivers R1, R2, R3, and R4 may then decrypt the set of ciphertexts across dealings DL1, DL2, DL3, and DL4. For example, receiver R1 may receive ciphertexts (ss1,0,1)pkR1,1, (ss2,0,1)pkR1,1, and (ss3,0,1)pkR1,1 from dealings DL1, DL2, and DL3, respectively, and decrypt these ciphertexts with decryption key dkR1,1, i.e., receiver R1's decryption key for period e1.

[0145] Similarly, the receiver R2 can obtain the ciphertexts (ss1,0,2)pkR2,1, (ss2,0,2)pkR2,1, (ss3,0,2)pkR2,1 from the deals DL1, DL2 and DL3, respectively, and decrypt these ciphertexts with the decryption key dkR2,1, i.e., the decryption key of the receiver R2 for the period e1.

[0146] After decrypting three of the four partial shares, each of the receivers R1, R2, R3, and R4 may combine their decrypted ciphertexts into a secret new shared secret. For example, receiver R1 may combine the decrypted partial shares ss1,0,1, ss2,0,1, and ss3,0,1 into a new shared secret s1,1 for the next (new) period e1. Similarly, receiver R2 may combine the decrypted partial shares ss1,0,2, ss2,0,2, and ss3,0,2 into a new shared secret ss2,1 for the new period e1.

[0147] Next, a secret sharing redistribution according to another embodiment of the present invention will be described with reference to Figures 7 and 8. Similar to the example of Figures 5 and 6, a redistribution protocol is executed to redistribute shared secrets s1,0, s2,0, s3,0, and s4,0 of duration e0 into shared secrets s1,1, s2,1, s3,1, and s4,1 of duration e1.

[0148] However, instead of creating separate ciphertexts for each recipient, the embodiment of Figures 7 and 8 uses multi-recipient encryption (MRE). With such multi-recipient encryption, the entire set of partial shares for each dealer is encrypted together. For example, the set of partial shares ss1,0,1, ss1,0,2, ss1,0,3, and ss1,0,4 of the first dealer D1 are encrypted in general with the multi-recipient encryption MRE1, with the subscripts indicating the term of the multi-recipient encryption or multi-recipient decryption scheme. Similarly, the partial shares ss2,0,1, ss2,0,2, ss2,0,3, and ss2,0,4 of the second dealer D2 are encrypted in general with the multi-recipient encryption MRE1, with the subscripts indicating the term of the multi-recipient encryption or multi-recipient decryption scheme. As a result, four commonly encrypted ciphertexts 711, 712, 713, 714 are created and placed on the bulletin board 50.

[0149] 5 and 6, each of the dealers D1, D2, D3, and D4 jointly generates a non-interactive zero-knowledge proof in which a set of ciphertexts includes a redistribution of the shared secret. Additionally, each of the dealers D1, D2, D3, and D4 may generate some associated public key material.

[0150] FIG. 8 shows a procedure in which receivers R1, R2, R3, and R4 reconstruct a new share from information posted on bulletin board 50 that has been distributed to an unspecified number of people.

[0151] First, as shown in Figures 5 and 6, receivers R1, R2, R3, and R4 verify or verify the non-interactive zero-knowledge proofs of NIZKD1, NIZKD2, NIZKD3, and NIZKD4 of internal dealings DL1, DL2, DL3, and DL4, respectively.

[0152] Once a sufficient number of proofs have been successfully inspected or verified, receivers R1, R2, R3, and R4 may begin reconstructing their new shares from the commonly encrypted ciphertexts 711-714. Each of the four receivers R1, R2, R3, and R4 may decrypt the set of ciphertexts across dealings DL1, DL2, DL3, and DL4. For example, receiver R1 decrypts at least three of the commonly encrypted partial shares ss1,0,1, ss2,0,1, ss3,0,1, and ss4,0,1 from each of dealings DL1, DL2, DL3, and DL4 with decryption key dkR1,1 of multi-receiver encryption scheme MRE1, i.e., receiver R1's decryption key dkR1,1 of the multi-receiver encryption scheme for period e1.

[0153] Similarly, receiver R2 decrypts at least three of the partial shares ss1,0,2, ss2,0,2, ss3,0,2, and ss4,0,2 from dealings DL1, DL2, DL3, and DL4, respectively, with decryption key dkR2,1 of multi-receiver encryption scheme MRE1 of duration e1.

[0154] After decrypting at least three of the four partial shares, each of the receivers R1, R2, R3, and R4 may combine their decrypted ciphertexts into a private new shared secret.

[0155] 2, there is shown a second subnet configuration 202 of the subnet SNA comprising additional nodes N5 and N6 in addition to the former nodes N1, N2, N3, and N4. This subnet configuration 202 is seen to be valid for periods e2 and e3.

[0156] Referring to FIG. 3, column 304 shows the new node's shared secret key set for period e2.

[0157] The decentralized network executes a secret redistribution protocol to redistribute the shared secret keys s1,0, s2,0, s3,0, and s4,0 to another set of nodes, which in this example is formed by the extended set of nodes N1, N2, N3, N4, N5, and N6.

[0158] The redistribution of the secret shares creates or generates a set of shared secrets s1,2, s2,2, s3,2, s4,2, s5,2, and s6,2 that are different from the second set, and in particular contain six shared keys instead of the previous four shared keys. These sets of shared keys also correspond to the same static verification key pkA of the subnet SNA.

[0159] In the subsequent period e3, the subnet SNA still has the same set of nodes N1, N2, N3, N4, N5, and N6. The distributed network executes a secret redistribution protocol to redistribute the shared secrets s1,2, s2,2, s3,2, s4,2, s5,2, and s6,2. Therefore, the secret redistribution protocol creates or generates another new set of shared secrets s1,3, s2,3, s3,3, s4,3, s5,3, and s6,3 that are different from the previous set. The new set of key shares also corresponds to the same static verification key pkA of the subnet SNA.

[0160] 2, it can be seen that a third subnet configuration 203 of the subnet SNA is shown, which comprises an additional node N7 and the previous node N3 has been deleted. This subnet configuration 203 is valid for a period e4.

[0161] Referring again to FIG. 3, column 306 shows the shared secret key of the new set of nodes established at time t4.

[0162] The decentralized network executes a secret redistribution protocol to redistribute the shared secrets s1,3, s2,3, s3,3, s4,3, s5,3, and s6,3 to a new set of nodes N1, N2, N4, N5, N6, and N7.

[0163] Therefore, the secret redistribution protocol has created or generated another new set of shared secrets s1,4, s2,4, s4,4, s5,4, s6,4, and s7,4, which are also different from the previous set but correspond to the same static verification key pkA of the subnet SNA.

[0164] 4 shows in more detail the computing units 15 operating on the nodes 10 of the network 100. The network 100 is configured to assign each of the computing units operating on the network 100 to one of a number of subnets, in this example one of the subnets SNA, SNB, SNC, or SND, according to a subnet assignment. The subnet assignment of the distributed network 100 creates an assigned subset of the entire set of computing units for each of the subnets SNA, SNB, SNC, and SND.

[0165] More specifically, the left side 401 of Figure 4 illustrates a node 10 of the subnet SNA of Figure 1. The subnet assignment of the distributed network 100 assigns a subset of five computing units 15 to the subnet SNA, more specifically, the subset of computing units CUA1, CUA2, CUA3, CUA4, and CUA5. The assigned subset of computing units CUA1, CUA2, CUA3, CUA4, and CUA5 execute on respective nodes 10 of the subnet SNA. Furthermore, the assigned subset of computing units CUA1, CUA2, CUA3, CUA4, and CUA5 are replicated across the subnet SNA such that each of the computing units CUA1, CUA2, CUA3, CUA4, and CUA5 traverses the same unit states or execution states. This can be implemented in particular by performing active replication on each of the nodes 10 of the subnet SNA in the space of the unit states of the computing units CUA1, CUA2, CUA3, CUA4 and CUA5.

[0166] Furthermore, the right side 402 of Fig. 4 shows four computing units 15, more particularly the nodes 10 of the subnet SNB of Fig. 1, on which a set of computing units CUB1, CUB2, CUB3 and CUB4 are executed. The set of computing units CUB1, CUB2, CUB3 and CUB4 are executed on each node 10 of the subnet SNB. Furthermore, the set of computing units CUB1, CUB2, CUB3 and CUB4 are replicated throughout the subnet SNB such that each of the computing units CUB1, CUB2, CUB3 and CUB4 has the same unit state, for example by performing active replication in the space of unit states as described above.

[0167] 9 shows a flow chart of method steps of a method according to an embodiment of the present invention. The method performs a redistribution of (n,t) secret shares of a secret s from a set of dealers to a set of recipients. The (n,t) secret shares comprise n shared secrets, where a shared secret threshold t≦n is sufficient to reconstruct the secret, and n and t are integers. Each of the n shared secrets is held by one of the dealers.

[0168] The method executes a processing loop 910 multiple times in order of increasing index N, where N is an increasing integer, i.e., 0, 1, 2, 3, . . . , N, for example.

[0169] The processing loop 910 includes a first loop step 911 , a second loop step 912 , a third loop step 913 , a fourth loop step 914 , a fifth loop step 915 , and a sixth loop step 916 .

[0170] The loop steps 911 to 916 are executed by each of at least the threshold value t of dealers.

[0171] In loop step 911, each dealer, e.g., a node in the decentralized network, creates an (n',t') secret share for its respective shared secret, where n' and t' are integers, and the (n',t') secret share includes n' partial shared secrets for its respective shared secret. A threshold of partial shared secrets t'≦n' is sufficient to reconstruct the dealer's shared secret.

[0172] In loop step 912, each dealer creates a set of ciphertexts by encrypting a partial share of the n partial shared secret for each recipient. The encrypted partial shared secret is encrypted against the respective recipient's public encryption key. The recipient's public encryption key is preferably a long-term public encryption key that has been activated, for example, for communication between nodes of the decentralized network.

[0173] In some embodiments, a public key encryption scheme with forward secrecy may be used in loop step 912. In some embodiments, the encryption scheme with forward secrecy is a binary tree encryption scheme. In further embodiments, the public key encryption scheme is a multi-recipient encryption scheme.

[0174] In some embodiments, a multi-recipient encryption scheme may perform chunk encryption of partial shares, where each plaintext of the partial shares represents one chunk.

[0175] In loop step 913, each dealer generates associated public key material for its shared secret. The associated public key material may typically include multiple public group elements associated with the shared secret and one public group element associated with the secret. As noted above, the secret may be, among other things, a private key corresponding to a public verification key of a public key signature scheme. In such an embodiment, the associated public key material may include multiple public shared verification keys associated with the shared secret and one public verification key associated with the secret.

[0176] In loop step 914, each of the dealers generates a non-interactive zero-knowledge proof in which the set of ciphertexts they jointly created includes a redistribution of their shared secret. In the case of chunk encryption described above, each of the dealers generates a further non-interactive zero-knowledge proof, in other words a second non-interactive zero-knowledge proof, to prove the correctness of the chunk encryption.

[0177] Detailed embodiments of non-interactive zero-knowledge (NIZK) proofs with correct secret sharing that may be used in some embodiments of the present invention are further presented in Chapter 3.3 of the Annex.

[0178] Detailed embodiments of Non-Interactive Zero-Knowledge (NIZK) proofs for correct chunking that may be used in some embodiments of the present invention are further presented in Chapter 3.4 of the Annex.

[0179] However, in some embodiments, other non-interactive zero-knowledge proofs with correct secret sharing and correct chunking may also be used.

[0180] An example of a non-interactive zero-knowledge proof is described in, for example, De Santis, Di Crescenzo, Ostrovsky, Persiano, Sahai: Robust Non-interactive Zero Knowledge: Crypto 2001: 566-598. or Groth, Maller: Snarky Signatures: Minimal Signatures of Knowledge from Simulation-Extractable SNARKs. Crypto 2017: 581-612.

[0181] Then, in loop step 915, each dealer distributes a deal to a set of unspecified recipients. Each deal comprises encrypted partial shares forming a set of ciphertexts, one or more corresponding non-interactive zero-knowledge proofs, and associated public key material.

[0182] Then, in loop step 916, the period may be incremented by one and the steps from loop 910 repeated for the new period.

[0183] 10 shows a flow chart of further method steps of a method according to an embodiment of the present invention. More specifically, it shows how a set of recipients can reconstruct new shares from a distributed deal.

[0184] The method executes a processing loop 1010 multiple times in order of increasing index N, where N is an increasing integer, i.e., 0, 1, 2, 3, . . . , N, for example.

[0185] The processing loop 1010 includes a first loop step 1011 , a second loop step 1012 , a third loop step 1013 , and a fourth loop step 1014 .

[0186] In loop step 1011, a set of receivers check the non-interactive zero-knowledge proofs of the dealing. Once a sufficient number of proofs corresponding to a new secret sharing threshold have been successfully checked, each of the receivers may, in loop step 1012, decrypt its encrypted partial shares across the dealing, more specifically at least the threshold number of partial shares.

[0187] Then, in loop step 1013, each of the recipients combines the decrypted partial shares into a secret new shared secret.

[0188] Then, in loop step 1014, the period is incremented by one and the loop 1010 performs the above steps again for the new period.

[0189] Figure 11 illustrates an embodiment of a verification key and its corresponding shared secret key that may be used in some embodiments of the present invention. Figure 11 shows an embodiment of a set of keys 1110 generated by a distributed key generation protocol according to an embodiment of the present invention. The distributed key generation protocol is embodied as a distributed threshold key generation protocol.

[0190] In this example, we assume that N nodes participate in the distributed key generation protocol. The nodes may be the nodes of any subnet, in particular the nodes of the governance subnet, that are typically assigned for the initial generation of the static validation keys for the subnet and the initial subset of the corresponding shared secret keys.

[0191] Each of the N nodes has a shared secret key s k , for i=1,...,N. The N nodes jointly generate a common static verification key (public key) p kX for each subnet X. To generate a threshold signature σ pkX, a predefined threshold, e.g., at least two-thirds or one-third of the nodes, are required to agree on the static verification key and jointly sign the new static verification key.

[0192] FIG. 12, for example, illustrates a more detailed block diagram of a network node 10 of the network 100 of FIG. 1 according to some embodiments of the present invention. The network node 10 constitutes a computing node capable of performing computational functions and may generally be embodied as a computing system or computer. The network node 10 may be, for example, a server computer. The network node 10 may be configured to execute or engage computer-implemented methods according to some embodiments of the present invention. The network node 10 may operate in a variety of other general purpose or special purpose computing system environments or configurations.

[0193] The network node 10 may be described in the general context of computer system executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The network node 10 is shown in the form of a general-purpose computing device. Components of the network node 10 may include, but are not limited to, one or more processors or processing units 1215, a system memory 1220, and a bus 1216 that couples various system components, including the system memory 1220, to the processor 1215.

[0194] Bus 1216 represents one or more of any of several forms of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures, including, by way of example and without limitation, Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VeSA) local bus, and Peripheral Component Interconnect (PCI).

[0195] Network node 10 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by network node 10 and includes both volatile and nonvolatile media, removable and non-removable media.

[0196] The system memory 1220 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1221 and / or cache memory 1222. The network node 1210 may further include other removable or non-removable, volatile or non-volatile computer system storage media. By way of example only, the storage system 1223 may be provided to read from and write to a non-removable, non-volatile magnetic medium (not shown, commonly referred to as a "hard drive"). As further illustrated and described below, the memory 1220 may include at least one computer program product having a set (e.g., at least one) program module configured to perform the functions of embodiments of the present invention.

[0197] The programs or utilities 1230 have a set (at least one) program module 1231, which may be stored in the memory 1220, by way of example and not limitation, and may store an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may implement a networking environment. The program module 1231 generally performs the functions and / or methods of the embodiments of the invention described herein. The program module 1231 may, in particular, perform one or more steps of a computer-implemented method for performing inter-subnet communication including a consensus protocol in a distributed network, such as one or more steps of the method described above.

[0198] The network node 10 may also communicate with one or more external devices 1217, such as a keyboard or pointing device, as well as a display 1218. Such communication may occur through an input / output (I / O) interface 1219. Additionally, the network node 10 may communicate with one or more networks 40, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), through a network adapter 1241. In some embodiments, the network 1240 may be a distributed network, particularly comprising multiple network nodes 10, e.g., the network 100 as shown in FIG. 1. As shown, the network adapter 1241 communicates with other components of the network node 10 through a bus 1216.

[0199] Some aspects of the invention may be embodied as a system, particularly a distributed network with multiple subnets, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium (or media) carrying computer-readable program instructions for causing a processor to perform some aspects of the invention.

[0200] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of such devices. As used herein, a computer-readable storage medium should not be construed as being a transitory signal in itself, such as an electric wave or other freely propagating electromagnetic wave.

[0201] The computer readable program instructions described herein may be downloaded to a respective computing or processing device from a computer readable storage medium, or from a network, such as, for example, the Internet, a local area network, a wide area network and / or a wireless network, to an external computer or external storage device.

[0202] The computer readable program instructions for carrying out various operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages.

[0203] Certain aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, networks, apparatus (systems) and computer program products according to certain embodiments of the invention.

[0204] Computer-readable program instructions according to some embodiments of the present invention may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, and may generate a machine such that the instructions executed through the processor of the computer or other programmable data processing apparatus create means for implementing the functions / operations specified in the flowchart and / or block diagram blocks or blocks. These computer-readable program instructions may also be stored on a computer-readable storage medium that may direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein includes a product including instructions that implement aspects of the functions or operations specified in the flowchart and / or block diagram blocks or blocks.

[0205] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to perform a set of operational steps such that the instructions, which execute on the computer, other programmable apparatus, or other device, implement the functions / acts specified in the flowchart and / or block diagram blocks, to generate a computer-implemented process.

[0206] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of networks, systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in the reverse order, depending on the functionality involved.

[0207] While presently preferred embodiments of the invention have been shown and described above and in the accompanying Annex, it is to be clearly understood that the invention is not limited thereto and may be variously embodied and carried out in other ways within the scope of the following claims. [Annex] JPEG0007664655000001.jpg231170JPEG0007664655000002.jpg231170JPEG0007664655000003.jpg231170JPEG0007664655000004.jpg231170JPEG0007664655000005.jpg231170JPEG0007664655000006.jpg231170JPEG0007664655000007.jpg231170JPEG0007664655000008.jpg231170JPEG0007664655000009.jpg231170JPEG0007664655000010.jpg231170JPEG0007664655000011.jpg231170JPEG0007664655000012.jpg231170JPEG0007664655000013.jpg231170JPEG0007664655000014.jpg231170JPEG0007664655000015.jpg231170JPEG0007664655000016.jpg231170JPEG0007664655000017.jpg231170JPEG0007664655000018.jpg231170JPEG0007664655000019.jpg231170JPEG0007664655000020.jpg231170JPEG0007664655000021.jpg231170JPEG0007664655000022.jpg231170JPEG0007664655000023.jpg231170JPEG0007664655000024.jpg231170JPEG0007664655000025.jpg231170JPEG0007664655000026.jpg231170JPEG0007664655000027.jpg231170JPEG0007664655000028.jpg231170

Claims

1. 1. A computer-implemented method for redistribution of (n,t) secret shares of a secret from a set of dealers to a set of recipients, the (n,t) secret shares comprising n shared secrets, a threshold t≦n of the shared secrets being sufficient to reconstruct the secrets, the set of dealers and the set of recipients being implemented as part of the software of their respective computers and having network access to communicate with each other; The method includes having at least the threshold number t of dealers each: creating an (n', t') secret share for each of the shared secrets, the (n', t') secret share including n' partial shared secrets for each of the shared secrets, a partial shared secret threshold t' < n' sufficient to reconstruct the shared secret; creating a set of ciphertexts, the set of ciphertexts comprising, for each of the recipients, an encrypted partial share for one of the n' partial shared secrets for its respective shared secret, the encrypted partial shared secrets being encrypted against a public encryption key of a public key encryption scheme of each of the recipients; generating a non-interactive zero-knowledge proof where the set of ciphertexts jointly comprises a redistribution of the shared secret; distributing a dealing of the set of recipients to an unspecified number of recipients, the dealing including the set of ciphertexts and the corresponding non-interactive zero-knowledge proofs to the set of recipients; using public key cryptography with forward secrecy to encrypt the partial shared secret for the recipient.

2. a set of predetermined parties, in particular a set of recipients, verifying said non-interactive zero-knowledge proof of said dealing; Once a sufficient number t of proofs have been successfully checked, each of said recipients decrypting its encrypted partial shares across said dealings; each of the recipients combining the decrypted partial shares into a new shared secret of the secret; The computer-implemented method of claim 1 , further comprising:

3. 3. The computer-implemented method of claim 1 or 2, wherein the non-interactive zero-knowledge proofs are publicly verifiable zero-knowledge proofs that any party can verify.

4. The computer-implemented method according to claim 1 , wherein the secret sharing is a linear secret sharing, in particular a Shamir secret sharing.

5. A computer-implemented method as described in any one of claims 1 to 4, further comprising the steps of each of the set of dealers creating associated public key material related to its shared secret and its own private share of the shared secret, and adding the associated public key material to the dealing.

6. 6. The computer-implemented method of claim 5, wherein the associated public key material includes one public group element associated with the shared secret of each of the dealers and / or multiple public group elements associated with the secret shares generated by each of the dealers.

7. The computer-implemented method of claim 1 , wherein the secret is a private key that corresponds to a public verification key of a public key signature scheme.

8. A computer-implemented method according to any one of claims 5, 6 and claim 7 which cites claim 5 or 6, further comprising the step of any party, in particular a recipient, generating new relevant public key material associated with a new secret sharing and a new shared secret for the set of recipients from the relevant public key material generated by the set of dealers.

9. 9. A computer-implemented method as claimed in claim 7 or claim 8 which cites claim 7, wherein the generation of the new associated public key material comprises deriving the new associated public key material from the associated public key material generated by the set of dealers, the new associated public key material having a plurality of public shared verification keys associated with the new shared secret of the recipient, a public verification key associated with the private key, and / or a plurality of elements from which the public shared verification key and / or the public verification key of the recipient can be derived.

10. 10. The computer-implemented method of claim 1, further comprising the step of using a public key encryption scheme with selected ciphertext attack security to encrypt the partial shared secret for the set of recipients.

11. 2. The computer-implemented method of claim 1, wherein the public key encryption scheme with forward secrecy is a binary tree encryption scheme.

12. 12. The computer-implemented method of claim 1, wherein the public key encryption scheme is a multi-recipient encryption scheme configured to encrypt the dealer's multiple partial shares into the public encryption keys of the set of recipients.

13. 13. The computer-implemented method of claim 1, wherein the encryption scheme is configured to perform chunk encryption of the plurality of partial shares, each of the partial shares being split into a plurality of plaintexts, each of the plaintexts representing a chunk.

14. 14. The computer-implemented method of claim 13, further comprising the set of dealers generating an additional non-interactive zero-knowledge proof, the additional zero-knowledge proof configured to prove that the chunk encryption is correct.

15. 15. The computer-implemented method of claim 2, further comprising the step of performing decryption of the encrypted multiple partial shares in a separate process on a virtual hardware security module or a hardware security module.

16. 16. The computer-implemented method of claim 1, wherein the step of broadcasting the dealing to an unspecified number of people includes posting the dealing on a message board.

17. A distributed network comprising a plurality of nodes, the distributed network configured to execute a computer-implemented method for (n,t) secret sharing of a secret from a set of dealers to a set of recipients, the (n,t) secret sharing comprising n shared secrets, a threshold t≦n of the shared secrets being sufficient to reconstruct the secret, the set of dealers and the set of recipients being implemented as part of the software of their respective computers and having network access to communicate with each other; The method includes having at least the threshold number t of dealers each: creating an (n', t') secret share for each of the shared secrets, the (n', t') secret share including n' partial shared secrets for each of the shared secrets, a threshold t' < n' of partial shared secrets sufficient to reconstruct the shared secret; creating a set of ciphertexts, the set of ciphertexts comprising, for each of the recipients, an encrypted partial share for one of the n' partial shared secrets for its respective shared secret, the encrypted partial shared secrets being encrypted against a public encryption key of a public key encryption scheme of each of the recipients; generating a non-interactive zero-knowledge proof where the set of ciphertexts jointly comprises a redistribution of the shared secret; distributing a dealing of the set of recipients to an unspecified number of recipients, the dealing including the set of ciphertexts and the corresponding non-interactive zero-knowledge proofs to the set of recipients; using public key cryptography with forward secrecy to encrypt the partial shared secret for the recipient.

18. 1. A computer program product for redistribution of (n,t) secret shares of a secret from a set of dealers to a set of recipients, the (n,t) secret shares comprising n shared secrets, a threshold t≦n of the shared secrets being sufficient to reconstruct the secrets, the set of dealers and the set of recipients being implemented as part of the computer program product on respective computers and having network access to communicate with each other, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions being executable on one or more nodes of a distributed network, the method being performed on one or more nodes comprising: Each of at least the threshold number t of dealers creating an (n', t') secret share for each of the shared secrets, the (n', t') secret share including n' partial shared secrets for each of the shared secrets, a threshold t' < n' of partial shared secrets sufficient to reconstruct the shared secret; creating a set of ciphertexts, the set of ciphertexts comprising, for each of the recipients, an encrypted partial share for one of the n' partial shared secrets for its respective shared secret, the encrypted partial shared secrets being encrypted against a public encryption key of a public key encryption scheme of each of the recipients; generating a non-interactive zero-knowledge proof where the set of ciphertexts jointly comprises a redistribution of the shared secret; distributing a dealing of the set of recipients to an unspecified number of recipients, the dealing including the set of ciphertexts and the corresponding non-interactive zero-knowledge proofs to the set of recipients; using a public key cryptography scheme with forward secrecy to encrypt the partial shared secret for the recipient.

Images