Improved robust distributed key generation

Abstract

A method for distributed generation of private key shares for a plurality of cryptographic devices is disclosed, allowing a number of cryptographic devices to be corrupt. The method may use a preprocessing phase that includes sharing symmetric keys among subsets of cryptographic devices. The subsets derive a private key from the symmetric key and broadcast a hash of a corresponding public key. A subset is excluded if some device fails to broadcast the correct hash. A private key share may now be derived from the private keys for non-excluded subsets.

Description

[0001]IMPROVED ROBUST DISTRIBUTED KEY GENERATION TECHNICAL FIELD The presently disclosed subject matter relates to a method for distributed generation of private key shares for a plurality of cryptographic devices, a cryptographic device, a cryptographic system, a computer storage medium. BACKGROUND In a (^ + 1)-out-of-^ threshold cryptosystem, a secret key is shared among ^ parties such that any collection of ^ + 1 honest parties can jointly perform some cryptographic operation, while an adversary compromising up to ^ parties cannot. The past few years have seen a significant interest in threshold signing, in particular, motivated by its application to the protection of cryptocurrency wallets as well as other applications such as threshold access control, random beacons, and distributed- protocol design. Research on threshold signatures has developed threshold protocols for the ECDSA, Schnorr, and BLS signature schemes, as well as protocols for distributed key generation (DKG) in the discrete-logarithm setting that underlies those schemes. SUMMARY A method for distributed generation of private key shares for a plurality of cryptographic devices, a cryptographic device, a cryptographic system, and a computer storage medium are described in the accompanying claims. Specific embodiments of the invention are set forth in the dependent claims. In an embodiment of the method for distributed generation of private key shares for a plurality of cryptographic devices, the method may use a preprocessing phase that includes sharing symmetric keys among subsets of cryptographic devices. The subsets derive a private key from the symmetric key and broadcast a hash of a corresponding public key. A subset is excluded if some device fails to broadcast the correct hash. A private key share may now be derived from the private keys for non-excluded subsets. In an embodiment, a method for distributed generation of private key shares for a plurality of cryptographic devices is provided. The method may comprise for a particular cryptographic device, one or more of: a preprocessing phase, a first round, and a second round. The preprocessing phase may comprise obtaining for each subset of the plurality that has n-t cryptographic devices and that includes the particular cryptographic device , a symmetric key shared with the other cryptographic devices in the subset. The first round may comprise - for each of the subsets that include the particular cryptographic device - deriving a private key for the subset from the symmetric key, the public key corresponding to the private key, and a hash of the public key, and - broadcasting the hash to the plurality, and The second round may comprise - receiving hashes broadcasted by other cryptographic devices in the plurality, - for each of the subsets, - determining if all cryptographic devices in the subset broadcasted the same hash for the subset, and if not, excluding the subset, and - if the subset is not excluded and includes the particular device, broadcasting the corresponding public key derived for the subset, - an output determination comprising - deriving a private key share for the particular cryptographic device from the derived private keys for non-excluded subsets that include the particular cryptographic device. A public key may be derived from the broadcasted public keys for each non-excluded subset. Interestingly, in the first round, a nonce may be obtained known to the plurality of cryptographic devices before deriving the private keys, wherein the private key is further derived from the nonce. This allows repeating the first round and the second round for multiple different nonces, while the preprocessing phase is performed once. Cryptographic devices are electronic devices; for example, a mobile electronic device, a mobile phone, a set-top box, a computer, a server, and the like. The method of claim 1 described herein may be applied in a wide range of practical applications. Such practical applications include asymmetric encryption, and digital signatures. Furthermore, embodiments may be used for securely performing computations on encrypted data by distributing key shares among multiple parties, ensuring that no single party can reconstruct the key and access the underlying data; strengthening the security of digital identity verification processes by distributing key shares across multiple identity providers, ensuring that no single entity has complete control over the private key; protecting communication channels by distributing encryption key shares among multiple devices or users, ensuring that a minimum number of participants are required to decrypt messages; securing cloud-based services by distributing key shares among multiple cloud providers, ensuring that no single provider can access the full encryption key and thus the sensitive data; and enhancing the security and resilience of private key management in decentralized systems, such as cryptocurrency networks, by distributing key shares among multiple nodes, thereby reducing the risk of single-point failures. An embodiment of a method for distributed generation of private key shares for a plurality of cryptographic devices may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both. Executable code for an embodiment of the method may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product comprises non-transitory program code stored on a computer readable medium for performing an embodiment of the method when said program product is executed on a computer. In an embodiment, the computer program comprises computer program code adapted to perform all or part of the steps of an embodiment of the method when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium. Another aspect of the presently disclosed subject matter is a method of making the computer program available for downloading. For example, a method according to the embodiment may comprise uploading the computer program to a server, enabling the computer program to be downloaded from this server, and facilitating the download of the computer program from the server. BRIEF DESCRIPTION OF DRAWINGS Further details, aspects, and embodiments will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. In the figures, elements which correspond to elements already described may have the same reference numerals. In the drawings, Figure 1a schematically shows an example of an embodiment of a cryptographic device, Figure 1b schematically shows an example of an embodiment of a further cryptographic device, Figure 1c schematically shows an example of an embodiment of a cryptographic system, Figure 1d schematically shows an example of an embodiment of a cryptographic system, Figure 1e schematically shows an example of an embodiment of a cryptographic system, Figure 2a schematically shows a computer readable medium having a writable part comprising a computer program according to an embodiment, Figure 2b schematically shows a representation of a processor system according to an embodiment, Figure 3 schematically shows an example of an embodiment of a method for distributed generation of private key shares for a plurality of cryptographic devices. Reference signs list The following list of references and abbreviations corresponds to the figures, and is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims. 100 a cryptographic system 101 a cryptographic system 110 a cryptographic device 120 a further cryptographic device 130 a client device 111, 121 a processor system 112, 122 storage 113, 123 communication interface 172 a computer network 1000, 1001 a computer readable medium 1010 a writable part 1020 a computer program 1110 integrated circuit(s) 1120 a processing unit 1122 a memory 1124 a dedicated integrated circuit 1126 a communication element 1130 an interconnect 1140 a processor system DESCRIPTION OF EMBODIMENTS While the presently disclosed subject matter is susceptible of embodiment in many different forms, there are shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the presently disclosed subject matter and not intended to limit it to the specific embodiments shown and described. In the following, for the sake of understanding, elements of embodiments are described in operation. However, it will be apparent that the respective elements are arranged to perform the functions being described as performed by them. Further, the subject matter that is presently disclosed is not limited to the embodiments only, but also includes every other combination of features described herein or recited in mutually different dependent claims. Figure 1a schematically shows an example of an embodiment of cryptographic device 110. Figure 1b schematically shows an example of an embodiment of a further cryptographic device 120. Cryptographic device 110 may be part of a cryptographic system 100 and / or 101. Cryptographic device 110 is part of a plurality of cryptographic devices that are all similar in functionality. Together the plurality of cryptographic devices generate, in a distributed fashion, a private key share for each device and a corresponding public key. An embodiment of cryptographic device 110 is configured for a preprocessing phase comprising obtaining for each subset (^) of the plurality that has ^ − ^ cryptographic devices and that includes the particular cryptographic device (^^), a symmetric key (^^,^) shared with the other cryptographic devices in the subset. The preprocessing phase may be performed by the plurality of cryptographic devices only, or may instead be performed using a further cryptographic device 120. Further cryptographic device 120 is also referred to as a trusted dealer, or trusted third party. Further cryptographic device 120 is typically not part of the plurality of cryptographic devices, but it could be. In the latter case, further cryptographic device 120 distributes symmetric keys during preprocessing and participates in the two round protocol later as well. Further cryptographic device 120 may be configured to generate for each subset (^) of the plurality that has ^ − ^ cryptographic devices a symmetric key and to share that key with the cryptographic devices in the subset. For example, the cryptographic system 100 may be used for distributed signing of messages, where the private key shares are used to sign in a distributed fashion. The corresponding public key may be used to verify such a signature. Cryptographic device 110 may comprise a processor system 111, a storage 112, and a communication interface 113. Further cryptographic device 120 may comprise a processor system 121, a storage 122, and a communication interface 123. In the various embodiments of communication interfaces 113 and / or 123, the communication interfaces may be selected from various alternatives. For example, the interface may be a network interface to a local or wide area network, e.g., the Internet, a storage interface to an internal or external data storage, an application interface (API), etc. Storage 112 and 122 may be, e.g., electronic storage, magnetic storage, etc. The storage may comprise local storage, e.g., a local hard drive or electronic memory. Storage 112 and 122 may comprise non-local storage, e.g., cloud storage. In the latter case, storage 112 and 122 may comprise a storage interface to the non-local storage. Storage may comprise multiple discrete sub-storages together making up storage 112 and 122. Storage 112 and / or 122 may be non-transitory storage. For example, storage 112 and / or 122 may store data in the presence of power such as a volatile memory device, e.g., a Random Access Memory (RAM). For example, storage 112 and / or 122 may store data in the presence of power as well as outside the presence of power such as a non-volatile memory device, e.g., Flash memory. Storage may comprise a volatile writable part, say a RAM, a non-volatile writable part, e.g., Flash. Storage may comprise a non-volatile non-writable part, e.g., ROM. The devices 110 and 120 may communicate internally, with each other, with other devices, external storage, input devices, output devices, and / or one or more sensors over a computer network. The computer network may be an internet, an intranet, a LAN, a WAN, etc. The computer network may be the Internet. The devices 110 and 120 may comprise a connection interface which is arranged to communicate within cryptographic system 100 or outside of cryptographic system 100 as needed. For example, the connection interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, an optical connector, etc., or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna. The communication interface 113 may be used to send or receive digital data, e.g., symmetric keys, a hash of derived public keys, and derived public keys. The communication interface 123 may be used to send or receive digital data, e.g., symmetric keys. Cryptographic device 110 and further cryptographic device 120 may have a user interface, which may include well-known elements such as one or more buttons, a keyboard, display, touch screen, etc. The user interface may be arranged for accommodating user interaction for performing a distributed generation of private key shares, etc. The execution of devices 110 and 120 may be implemented in a processor system. The devices 110 and 120 may comprise functional units to implement aspects of embodiments. The functional units may be part of the processor system. For example, functional units shown herein may be wholly or partially implemented in computer instructions that are stored in a storage of the device and executable by the processor system. The processor system may comprise one or more processor circuits, e.g., microprocessors, CPUs, GPUs, etc. Devices 110 and 120 may comprise multiple processors. A processor circuit may be implemented in a distributed fashion, e.g., as multiple sub-processor circuits. For example, devices 110 and 120 may use cloud computing. Typically, the cryptographic device 110 and / or further cryptographic device 120 each comprise one or more microprocessors which execute appropriate software stored at the device; for example, that software may have been downloaded and / or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash. Instead of using software to implement a function, the devices 110 and 120 may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA). The devices may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), e.g., an integrated circuit (IC) customized for their particular use. For example, the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDL, etc. In particular, devices 110 and 120 may comprise circuits, e.g., for cryptographic processing, and / or arithmetic processing. In hybrid embodiments, functional units are implemented partially in hardware, e.g., as coprocessors or cryptographic coprocessors, and partially in software stored and executed on the device. Figure 1c schematically shows an example of an embodiment of cryptographic system 100. System 100 may comprise a plurality of cryptographic devices; shown are cryptographic devices 110.1, 110.2, and 11.03. System 100 does not comprise further cryptographic device 120. Instead, symmetric keys are generated by the plurality of cryptographic devices themselves. The number of participating device is a parameter of the system that is typically denoted as ^. The system is robust against some of the devices being corrupt. The number of corrupt devices that can be allowed is a parameter denoted as ^. The devices are connected through a computer network 172, e.g., the Internet. The cryptographic devices 110.1-110.3 may be according to an embodiment. Figure 1d schematically shows an example of an embodiment of cryptographic system 101. System 101 may comprise the plurality of cryptographic devices as in system 100. In addition, system 101 comprises further cryptographic device 120 to generate symmetric keys. Further cryptographic device 120 may be according to an embodiment. Figure 1e schematically shows an example of an embodiment of cryptographic system 102. System 102 is similar system 100, although system 101 could also have been used. System 102 further shows a client device 130. Client device 130 is not part of the plurality but may be configured to make use of the plurality after it has been provided with private key shares. For example, device 130 may request a signature on a message to be generated by the plurality using their private key shares. For example, device 130 may receive a signature and verify it using the public key. Here we show an efficient protocol for robust distributed key generation in the discrete- logarithm setting. After a preprocessing phase, which may be run by the parties themselves, parties can generate an unbounded number of keys using a two-round protocol. In a (^ + 1)-out-of-^ threshold cryptosystem, a secret key is shared among ^ parties such that any collection of ^ + 1 honest parties can jointly perform some cryptographic operation, while an adversary compromising up to ^ parties cannot. The past few years have seen a significant interest in threshold signing, in particular, motivated by its application to the protection of cryptocurrency wallets as well as other applications such as threshold access control, random beacons, and distributed- protocol design. Research on threshold signatures has developed threshold protocols for the ECDSA, Schnorr, and BLS signature schemes, as well as protocols for distributed key generation (DKG) in the discrete-logarithm setting that underlies those schemes. DKG protocols have been studied in both the synchronous and asynchronous settings. Although the asynchronous model may be more appropriate for large-scale protocols with globally distributed parties, the synchronous model is what is assumed in practice for small-scale protocols running in a local network. In embodiments, we consider the synchronous setting. An important property that is often overlooked in the context of synchronous threshold protocols is robustness—aka guaranteed output delivery—namely, the requirement that a protocol should produce correct output (e.g., a valid signature) whenever it is executed, even in the presence of malicious behavior. Robustness in the presence of t corrupted or faulty parties requires 2^ + 1 parties to participate in the protocol. While it is often possible to add robustness to existing, non-robust protocols by running the protocol multiple times, doing so is inefficient and sometimes leads to subtle security flaws (e.g., an attacker may be able to bias the output or learn multiple outputs). If robustness is required, it should be incorporated directly. In this work, we focus on robust DKG protocols in the discrete-logarithm setting. Roughly speaking, the goal in this context is for ^ parties to distributively generate a public key ^ = ^^(where ^ is a generator of a cyclic group ^) such that the parties hold (^ + 1)-out-of-^ Shamir secret shares {^^} of the private exponent ^. Robustness means that a public key ^ is always generated, and honest parties always hold correct shares of the corresponding ^. In some embodiments, the parties also compute public “commitments” {^^^} to each others’ shares, as is often required by threshold protocols. The protocol described herein can be proven secure in a simulation-based framework, where this corresponding ideal functionality (in particular) ensures guaranteed output delivery. Since robustness is impossible in the dishonest-majority setting, we assume an honest majority, e.g., we assume throughout that the parameter t is strictly less than half the number n of participating cryptographic devices. In that setting, we show a protocol that requires no prior setup and achieves the following properties: After one round of preprocessing (run by the parties themselves), the parties can generate an unbounded number of keys via repeated invocations of a 2-round protocol. The protocol is quite efficient for small values of ^ typical in practice. The protocol is thus an appropriate choice for many real-world applications of threshold DKG. Preliminaries Notation. We let ^ denote a cyclic group of prime order ^ and let ^ ∈ ^ be a fixed generator. We let ℤ^= {0, … , ^ − 1} (viewed as a field), and [^] = {1, … , ^}. We write “←” for probabilistic assignment and “: =” for deterministic assignment. In particular, if $ is a randomized algorithm then ^ ← $(^) means that we run $ input ^ and a uniform random tape to obtain ^, ^: = $(^; &) means that we (deterministically) run $ on input ^ and random tape & to obtain ^. System and communication model. We assume ^ parties ^', … , ^(, with ^ < ^ / 2 a bound on the number of corrupted parties. We work in the standard synchronous communication model where parties are connected by pairwise private and authenticated channels in addition to a public broadcast channel. Cryptographic Building Blocks Shamir secret sharing. We use the standard notion of Shamir secret sharing. To share a secret ^ ∈ ℤ^in a (^ + 1)-out-of-^ fashion, a dealer chooses uniform coefficients +', … , +,∈ ℤ^and forms the polynomial +(-): = ^ + ∑,^ / '+^⋅ -^; it then defines shares {^^}(^ / 'by setting ^^: (1), and distributes ^^to ^^via a private channel. It is to also define ^2: = +(0) = ^ (though note that ^2is not a share that is sent to any party), and we {^^}(^ / 2← ^^,(^) to denote the process by which these values are generated. No information about ^ is revealed by the shares of any ^ parties, but ^ = ^2can be reconstructed from the shares of any ^ + 1 parties. More generally, it is possible to reconstruct the value of + at any point from its values at any ^ + 1 points using Lagrange interpolation. This means that for any (^ + 1)-size set ^ ⊂ ℤ^and any ^ ∈ ℤ^it is possible to (publicly) compute coefficients {4^^,5}^∈^such that +(^) = ∑^∈^4^^,5⋅ +(1). We denote the interpolation of the value of +(^) from the values {+(1)}^∈^by 1^^6789:;^6(^, ^, {+(1)}^∈^). In particular, when ^ ⊂ [^] we have ^ = 1^^6789:;^6(0, ^, {^^}^∈^). that interpolation can also be done “in the exponent,” e.g., given any (^ + 1)-size set ^ ⊂ ℤ , the values {^)} , and ^ ∈ ℤ ,<(5) <(^) @B <(^^,A^ ^∈^ ^it is possible to compute ^ =∏^∈^>^ ? . Overloading slightly, denote this by 1^^6789:;^6(^, ^, {^<(^)}^∈^). An embodiment of the distributed key-generation protocol generates a uniform private key ^ ∈ ℤ^and gives each party ^^the corresponding public key ^ = ^^along with ^^’s share ^^in a (^ + 1)- out-of-^ sharing of ^. If desired, for a subsequent threshold cryptosystems, the parties also obtain a vector of commitments C = (^^D, … , ^^E) to the shares of the other parties. Such commitments may be used by parties to prove correctness of their actions in a subsequent protocol using the generated key. Advantageously, the protocol ensures robustness so long the number of corrupt parties is at most ^. Instead of the group ℤ^other finite groups may be used to perform the computations in, e.g., elliptic or hyperelliptic groups. A Two-Round Protocol Using Preprocessing Here we show a robust DKG protocol that does not require any setup. It may use one round of preprocessing run by the parties themselves, following which it is possible for the parties to generate an unbounded number of keys via a 2-round protocol. Alternately, one may view our result as a 2-round DKG protocol assuming a trusted dealer. The protocol is parameterized by two values ^ and ^. The value ^ determines the number of cryptographic devices in the cryptographic system executing the protocol. The value ^ determines a bound on the number of corrupted or faulty devices that can be tolerated. It is required that ^ be strictly less than half of ^. Let F(G,,(denote the collection of all subsets of [^] of size ^ − ^. Here [^] refers to the set of integers from 1 to ^. Each integer 1 identifies a party ^^. At a high level, the idea is as follows. During a preprocessing phase, a designated party in each ^ ∈ F(G,,((the designated party could be, e.g., the lowest-indexed party in ^) chooses a uniform key ^^and sends it over a private channel to each party in ^. Let ^^,^be the key that ^^receives from the designated party ^^for set ^. Note, if ^^is corrupted, that party may choose ^^improperly, but this will not affect security. First of all, ^^would learn ^^anyway regardless of how it was chosen. A more serious problem is that ^^might send different keys to different (honest) parties in ^; however the protocol deals with this. At least one set ^ℋ∈ F(G,,(contains only honest parties; the key ^^ℋfor that set will be uniform, unknown to the correctly among all parties in ^ℋ. In an initialization phase a trusted dealer does the following: for every subset ^ ∈ F(G,,(it chooses a uniform key ^^∈ {0,1}I, and gives ^^.to each party ^^, 1 ∈ ^. The key-generation protocol has a two-round structure. Let J: {0,1}I× {0,1}(→ ℤ^be a pseudorandom function. For example, the function J may comprise block cipher, e.g., the Advanced Encryption Standard (AES), or a modification thereof. The function takes as input a symmetric key and a nonce M ∈ {0,1}(. The nonce does not need to be random, only non-repeating. It could be a counter, or a session id, or derived in some other agreed-upon fashion by the parties. In an embodiment, it is possible to omit the nonce if only a single key will be generated. In the first round, each party ^^computes ^N^,^: = ^OA^,B(P)for each set ^ of which they are a member, and broadcasts ℎ^,^: = R(^N^,^), where R is a cryptographic hash function. For each set ^ ∈ F(G,,(there are now two all parties in ^ broadcasted the same value, which we may call ℎ^, or parties in ^ broadcast different values. In the latter case all parties exclude the set ^ from further consideration. Let ℐ ⊆ F(G,,,be the collection of non-excluded (or “qualified”) sets. In the second round, each party ^^broadcasts {^N^,^} for each ^ ∈ ℐ of which they are a member. Each party then sets ^N^(for ^ ∈ ℐ) equal to any valid preimage of ℎ^that was broadcast. Such a value will always exist if the number of corrupted or faulty parties is at most t. Parties compute their output by summing only over sets in ℐ. For every subset ^ ∈ F(G,,(, let U^∈ ℤ^[-] be the polynomial of degree at most ^ satisfying U^(0) = 1 and U^(1) = 0 for 1 ∈ [^]\^. Note that U^is publicly known. Party ^^computes its share as ^^: = ∑^∈ℐ∶ ^∈^J5^,B(M) ⋅ U^(1), and all parties may compute the public key ^: =∏^∈ℐ^N^and the commitments ^Y: = ∏^∈ℐ∶ Y∈^^NZB(Y) ^ for all [ ∈ [^]. To see that the shares form a correct (^ + 1)-out-of-^ Shamir secret sharing, let +Pbe the polynomial \]< +P(-) = ∑^∈FE^_,EJ5B(M) ⋅ U^(-) (2) of degree at most ^. Then BE^_,E∶ ^∈^JB(M) U^(1) = ^^. The value ^ being shared is \]< ^P= +P(0) =∑^∈FE^_,EJ5B(M) ⋅ U^(0) =∑^∈FE^_,EJ5B(M). (3) about ^[(]\a, this means that ^ is a^given of the in a. Let {^N^}^∈ℐbe the values used by parties to compute the public key and the commitments, \]< and let ^^= loge^N^. Then loge^Y= ∑^∈ℐ∶ Y∈^^^⋅ U^([) so the exponents of the {^Y}Y∈[(]do indeed lie on the degree-^ polynomial +P(-) = ∑^∈ℐ^^⋅ U^(-) (compare to (2)). Moreover, the exponent of the public key ^ is loge^ = ∑^∈ℐ^^= +(0) (4) as required. As for the shares computed by the (honest) parties, note that for ∈ ℐ all honest parties in ^ must have broadcast the same value ℎ^in round 1; collision-resistance of R thus implies that every honest party ^^in ^ holds the same value of J5^,B(M) = loge^N^= ^^. Thus, honest parties’ shares are consistent with the publicly computed information. As for security, one important property of the protocol is that the public key ^ is fully determined at the end of the first round (regardless of the actions of the corrupted parties in the second round), even though it cannot yet be computed by the corrupted parties. Roughly, this holds because for each set ^ ∈ F(G,,(containing a corrupted party there are two possibilities: either there is agreement in the {ℎ^,^}^∈^ In the latter case, the effect is to exclude ^ from ℐ. In the former case, collision- resistance of R ensures that the common value ℎ^cannot be “opened” to conflicting values ^N^,^≠ ^NY,^; moreover, the attacker cannot choose to prevent a preimage of ℎ^from being revealed since ^ contains at least one honest party. This shows that the attacker cannot bias the key or prevent it from being computed, and the protocol is thus robust. Secrecy of the private key holds since ^ℋis always in ℐ, and hence the pseudorandom contribution of the key ^^ℋused by the set of honest parties is always included in the computation of the private key (cf. (4)). The pseudocode ghi,jdescribed below is a protocol for robust generation of a distributed key among ^ parties, e.g., parties ^', ^k, … , ^(. Besides the parameters ^, a parameter ^ indicates the number of parties that may be corrupt. A corrupt party may not adhere to the protocol agreed among the parties. For example, a corrupt party may send a wrong message, e.g., a wrong symmetric key, public key, hash or the like. A corrupt party may fail to send a message at all, e.g., as indicated by a time-out. Apart from a single round preprocessing, the protocol requires only two round to generate the key shares, public key, and optionally, key share commitments. The preprocessing round may be done once, while the first and second round may be repeated as many times as necessary. gi,j h Let R: ^ → {0,1}Ibe a cryptographic hash function. Preprocessing: For each ^ ∈ F(G,,(, a designated party in ^ chooses a uniform key ^^∈ ℤ^and sends it (over a private channel) to each party 1 ∈ ^. Each party ^^sets ^^,^to the value received. This step could also be executed by a trusted dealer as explained previously. If ^^does not receive ^^for some set ^ ∈ F(G,,(with 1 ∈ ^, it sets ^^,^: = 0. Key generation: To generate a key corresponding to nonce M, each party ^^does: Round 1: For all ^ ∈ F(G,,(with 1 ∈ ^, compute ^N^,^: = ^OA^,B(P)and ℎ^,^: = R(^N^,^). Then broadcast {ℎ^,^}^∈FE^_,E∶ ^∈^. If for some ^ ∈ F(G,,(and [ ∈ ^, party ^Yfails to broadcast ℎY,^, set ℎY,^: =⊥. Round 2: Initialize ℐ: = ∅. Then for each ^ ∈ F(G,,(, do: If there is a value ℎ^with ℎY,^= ℎ^for all [ ∈ ^, then add ^ to ℐ. Broadcast {^N^,^}^∈ℐ∶ ^∈^. Output determination: Each party ^^does: 1. For each ^ ∈ ℐ, if some party ^Ywith [ ∈ ^ broadcasted ^NY,^with R(^NY,^) = ℎ^then set ^N^: = ^NY,^. 2. Set ^: = ∑ J Z ( ^,B(M) ⋅ U (1), and fo ∏Y∈^NBY) ^^∈ℐ∶ ^∈^ 5 ^r [ ∈ [^] set ^Y: =^∈ℐ∶^^. 3. Set ^: 4. Output The DKG protocol, parameterized by ^, ^. The following can be mathematically proven. Let J be a pseudorandom function, and model R as a random oracle. Then for ^ < ^ / 2, protocol nk,,(securely realizes an ideal functionality for robust key generation, in the presence of up to t corrupted or faulty parties. round 2 may be modified a follows: Before broadcasting its round-2 message, each party ^^updates its collection of keys by setting ^^,^: = R(^^,^) for each ^ for which 1 ∈ ^. It is preferable that all parties update all their symmetric keys, but this is not necessary; for example, the parties may agree to update one or more of the symmetric keys, but not all. For example, a single key may be updated until after a number of rounds all keys have been updated. This saves on computation effort. Computations may be performed in any finite group in which the discrete log problem is difficult. For example, the integers modulo a prime may be used. The size of the prime may be choses in dependence on the desired security level, e.g., the desired difficulty of the discrete log problem. As an example, the prime may have at least 1024 bits. The symmetric keys may have at least 80 bits. The function J5^,B(M) may be constructed from a hash function; for example, the inputs may be concatenated and hashed. The function J may be derived from any suitable pseudorandom function. The hash may be SHA-256. Other choices for these functions are possible. Parameters may be larger for increased security or smaller to reduce resources. The number of devices in the plurality in an embodiment may be 3, 4, or 5, or more. The number of corrupted devices may be 1, 2 or more. For example, the following combinations of (^, ^) have been considered:(3, 1),(4, 1),(5, 1),(5, 2), etc. The following clauses have been considered as advantageous embodiments. In these clauses, references in parentheses refer to reference signs in drawings of exemplifying embodiments or to formulas of embodiments, thus increasing the intelligibility of the clause. These references shall not be construed as limiting the clause. Clause 1. A method for distributed generation of private key shares for a plurality of cryptographic devices, wherein the plurality has a number ^ of cryptographic devices, a threshold ^ being defined as the number of cryptographic devices that can be tolerated to be corrupt, the method comprising for a particular cryptographic device in the plurality, - a preprocessing phase comprising - obtaining for each subset of the plurality that has ^ − ^ cryptographic devices and that includes the particular cryptographic device , a symmetric key shared with the other cryptographic devices in the subset, - a first round comprising - for each of the subsets that include the particular cryptographic device - deriving a private key for the subset from the symmetric key, the public key corresponding to the private key, and a hash of the public key, and - broadcasting the hash to the plurality, and - a second round comprising - receiving hashes broadcasted by other cryptographic devices in the plurality, - for each of the subsets, - determining if all cryptographic devices in the subset broadcasted the same hash for the subset, and if not, excluding the subset, and - if the subset is not excluded and includes the particular device, broadcasting the corresponding public key derived for the subset, - an output determination comprising - deriving a private key share for the particular cryptographic device from the derived private keys for non-excluded subsets that include the particular cryptographic device. Clause 2. A method as in Clause 1, further generating a public key corresponding to the plurality of private key shares of the plurality of cryptographic devices, wherein the output determination further comprises - deriving a public key from the broadcasted public keys for each non-excluded subset. Clause 3. A method as in Clause 1, comprising for the particular cryptographic device in the plurality, - in the first round, obtaining a nonce known to the plurality of cryptographic devices before deriving the private keys, wherein the private key is further derived from the nonce. Clause 4. A method as in Clause 3, wherein the first round and the second round are repeated for multiple different nonces, but the preprocessing phase is performed once. Clause 5. A method as in Clause 1, comprising, after deriving the private key for each of the subsets, updating the symmetric key for one or more subsets, the updating comprising applying a hash function to the symmetric key. Clause 6. A method as in Clause 1, comprising deriving a commitment by the particular cryptographic device for a further cryptographic device in the plurality, from the public keys for each non-excluded subset that include the further cryptographic device. Clause 7. A method as in Clause 1, - using the discrete-logarithm setting, wherein deriving the corresponding public key for a private key comprises modular exponentiation of a common generator with the private key. Clause 8. A method as in Clause 1, - using elliptic curve cryptography, wherein deriving the corresponding public key for a private key comprises multiplying a common generator point on a common elliptic curve with the private key. Clause 9. A method as in Clause 1, wherein - the symmetric key for a subset is obtained in the preprocessing phase from a designated cryptographic device in the subset that generates the symmetric key , and / or - the symmetric key for a subset is obtained in the preprocessing phase from a trusted cryptographic device, preferably, the trusted cryptographic device not being part of the plurality of cryptographic devices. Clause 10. A method as in Clause 1 for generating a signature in the plurality of cryptographic devices, comprising obtaining a message, and generating a signature for the message using a threshold signature scheme using the private key shares. Clause 11. A method for distributed generation of private key shares for a plurality of cryptographic devices and a corresponding public key, wherein the plurality has a number ^ of cryptographic devices, and a threshold ^ being defined as the number of cryptographic devices that can be tolerated to be corrupt, wherein at least ^ − ^ cryptographic devices perform a method according to clause 1. Clause 12. A cryptographic device comprising: one or more processors; and one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations according to clause 1. Clause 13. A cryptographic system comprising a plurality of cryptographic devices, wherein the plurality has a number ^ of cryptographic devices, a threshold ^ being defined as the number of cryptographic devices that can be tolerated to be corrupt, wherein at least ^ − ^ cryptographic devices perform a method according to clause 1. Clause 14. A transitory and / or non-transitory computer storage medium encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform a method according to clause 1. Figure 3 schematically shows an example of an embodiment of a method 300 for distributed generation of private key shares for a plurality of cryptographic devices. The plurality has a number n of cryptographic devices, a threshold t being defined as the number of cryptographic devices that can be tolerated to be corrupt. The method comprises for a particular cryptographic device (^^) in the plurality, - a preprocessing phase (310) comprising - obtaining (311) for each subset (^) of the plurality that has ^ − ^ cryptographic devices and that includes the particular cryptographic device (^^), a symmetric key (^^,^) shared with the other cryptographic devices in the subset, - a first round (320) comprising - for each of the subsets (^) that include the particular cryptographic device (^^) - deriving (321) a private key (J5^,B(M)) for the subset from the symmetric key (^^,^), the public key (^N^,^: = ^OA^,B(P)) corresponding to the private key, and a hash of the public key (ℎ^,^: = R(^N^,^)), and - (322) the hash to the plurality, and - a second round (330) comprising - receiving (331) hashes broadcasted by other cryptographic devices in the plurality, - for each of the subsets (^), - determining (332) if all cryptographic devices in the subset (^) broadcasted the same hash for the subset, and if not, excluding the subset, and - if the subset is not excluded and includes the particular device, broadcasting (333) the corresponding public key (^N^,^: = ^OA^,B(P)) derived for the subset, - an output determination comprising - deriving (334) a private key share (^^: = ∑^∈ℐ∶ ^∈^J5^,B(M) ⋅ U^(1)) for the particular cryptographic device from the derived private keys for non-excluded subsets that include the particular cryptographic device. It will be appreciated that the presently disclosed subject matter also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the presently disclosed subject matter into practice. The program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method. An embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and / or be stored in one or more files that may be linked statically or dynamically. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the devices, units and / or parts of at least one of the systems and / or products set forth. Figure 2a shows a computer readable medium 1000 having a writable part 1010, and a computer readable medium 1001 also having a writable part.Computer readable medium 1000 is shown in the form of an optically readable medium. Computer readable medium 1001 is shown in the form of an electronic memory, in this case a memory card. Computer readable medium 1000 and 1001 may store data 1020 wherein the data may indicate instructions, which when executed by a processor system, cause a processor system to perform an embodiment of a method for distributed generation of private key shares, according to an embodiment. The computer program 1020 may be embodied on the computer readable medium 1000 as physical marks or by magnetization of the computer readable medium 1000. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium 1000 is shown here as an optical disc, the computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 comprises instructions for causing a processor system to perform an embodiment of a method for distributed generation of private key shares. Figure 2b shows in a schematic representation of a processor system 1140 according to an embodiment of a cryptographic device and / or a further cryptographic device. The processor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in Figure 2b. Circuit 1110 comprises a processing unit 1120, e.g., a CPU, for running computer program components to execute a method according to an embodiment and / or implement its modules or units. Circuit 1110 comprises a memory 1122 for storing programming code, data, etc. Part of memory 1122 may be read-only. Circuit 1110 may comprise a communication element 1126, e.g., an antenna, connectors or both, and the like. Circuit 1110 may comprise a dedicated integrated circuit 1124 for performing part or all of the processing defined in the method. Processor 1120, memory 1122, dedicated IC 1124 and communication element 1126 may be connected to each other via an interconnect 1130, say a bus. The processor system 1110 may be arranged for contact and / or contact-less communication, using an antenna and / or connectors, respectively. For example, in an embodiment, processor system 1140, e.g., the cryptographic device may comprise a processor circuit and a memory circuit, the processor being arranged to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core i7 processor, ARM Cortex-R8, etc. The memory circuit may be an ROM circuit, or a non-volatile memory, e.g., a flash memory. The memory circuit may be a volatile memory, e.g., an SRAM memory. In the latter case, the device may comprise a non-volatile software interface, e.g., a hard drive, a network interface, etc., arranged for providing the software. While system 1140 is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, the processing unit 1120 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform elements or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where the system 1140 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor 1120 may include a first processor in a first server and a second processor in a second server. It should be noted that the above-mentioned embodiments illustrate rather than limit the presently disclosed subject matter, and that those skilled in the art will be able to design many alternative embodiments. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb ‘comprise’ and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article ‘a’ or ‘an’ preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of” when preceding a list of elements represent a selection of all or of any subset of elements from the list. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The presently disclosed subject matter may be implemented by hardware comprising several distinct elements, and by a suitably programmed computer. In the device claim enumerating several parts, several of these parts may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. In the claims, references in parentheses refer to reference signs in drawings of exemplifying embodiments or to formulas of embodiments, thus increasing the intelligibility of the claim. These references shall not be construed as limiting the claim.

Claims

CLAIMS Claim 1. A method (300) for distributed generation of private key shares for a plurality of cryptographic devices, wherein the plurality has a number ^ of cryptographic devices, a threshold ^ being defined as the number of cryptographic devices that can be tolerated to be corrupt, the method comprising for a particular cryptographic device (^^) in the plurality, - a preprocessing phase (310) comprising - obtaining (311) for each subset (^) of the plurality that has ^ − ^ cryptographic devices and that includes the particular cryptographic device (^^), a symmetric key (^^,^) shared with the other cryptographic devices in the subset, - a first round (320) comprising - for each of the subsets (^) that include the particular cryptographic device (^^) - deriving (321) a private key (J5^,B(M)) for the subset from the symmetric key (^^,^), the public key (^N^,^: = ^OA^,B(P)) corresponding to the private key, and a hash of the public key (ℎ^,^: = R(^N^,^)), and - broadcasting (322) the hash to the plurality, and- comprising - receiving (331) hashes broadcasted by other cryptographic devices in the plurality, - for each of the subsets (^), - determining (332) if all cryptographic devices in the subset (^) broadcasted the same hash for the subset, and if not, excluding the subset, and - if the subset is not excluded and includes the particular device, broadcasting (333) the corresponding public key (^N^,^: = ^OA^,B(P)) derived for the subset, - an output determination comprising - deriving (334) a private key share (^^: = ∑^∈ℐ∶ ^∈^J5^,B(M) ⋅ U^(1)) for the particular cryptographic device from the derived private keys for non-excluded subsets that include the particular cryptographic device. Claim 2. A method as in Claim 1, further generating a public key corresponding to the plurality of private key shares of the plurality of cryptographic devices, wherein the output determination further comprises - deriving a public key (^: =∏^∈ℐ^N^) from the broadcasted public keys (^N^,^: = ^OA^,B(P)) for each non-excluded subset. Claim 3. A method as in any of the previous claims, comprising for the particular cryptographic device (^^) in the plurality,- in the first round, obtaining a nonce (M) known to the plurality of cryptographic devices before deriving the private keys, wherein the private key (J5^,B(M)) is further derived from the nonce. Claim 4. A method as in Claim 3, wherein the first round and the second round are repeated for multiple different nonces, but the preprocessing phase is performed once. Claim 5. A method as in any of the preceding claims, comprising - after deriving the private key (J5^,B(M)) for each of the subsets (^), updating the symmetric key (^^,^) for one or more subsets, the updating comprising applying a hash function to the symmetric key (^^,^). Claim 6. A method as in any of the preceding claims, comprising deriving a commitment (^Y: = ∏^∈ℐ∶ Y∈^^NZB(Y) ^ ) by the particular cryptographic device (^^) for a further cryptographic device (^Y) in the plurality, from the public keys for each non-excluded subset that include the further cryptographic device (^Y).

7. A method as in any of the preceding claims, - using the discrete-logarithm setting, wherein deriving the corresponding public key for a private key comprises modular exponentiation of a common generator (^) with the private key. Claim 8. A method as in any of the preceding claims, - using elliptic curve cryptography (ECC), wherein deriving the corresponding public key for a private key comprises multiplying a common generator point on a common elliptic curve with the private key. Claim 9. A method as in any of the preceding claims, wherein - the symmetric key (^^,^) for a subset is obtained in the preprocessing phase from a designated cryptographic device in the subset that generates the symmetric key (^^,^), and / or - the symmetric key (^^,^) for a subset is obtained in the preprocessing phase from a trusted cryptographic device, preferably, the trusted cryptographic device not being part of the plurality of cryptographic devices. Claim 10. A method as in any of the preceding claims for generating a signature in the plurality of cryptographic devices, comprising obtaining a message (r), and generating a signature for the message using a threshold signature scheme using the private key shares. Claim 11. A method as in any of the preceding claims, wherein the signature is applied in a multi- signature wallet setup, where transactions or access requests require the signatures or approval from ^ + 1 or more parties.Claim 12. A method as in any of the preceding claims, wherein data encrypted with the public key can be decrypted using a threshold decryption scheme by the parties using their respective private key shares. Claim 13. A method as in any of the previous claims, further comprising the application of a threshold multi-party computation algorithm using the private key shares, and / or private key share commitments. Claim 14. A method for distributed generation of private key shares for a plurality of cryptographic devices and a corresponding public key, wherein the plurality has a number ^ of cryptographic devices, and a threshold ^ being defined as the number of cryptographic devices that can be tolerated to be corrupt, wherein at least ^ − ^ cryptographic devices perform a method according to any of the claims 1-13. Claim 15. A cryptographic device comprising: one or more processors; and one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations for any of the claims 1-13. Claim 16. A cryptographic system comprising a plurality of cryptographic devices, wherein the plurality has a number ^ of cryptographic devices, a threshold ^ being defined as the number of cryptographic devices that can be tolerated to be corrupt, wherein at least ^ − ^ cryptographic devices perform a method according to any of the claims 1-13. Claim 17. A transitory and / or non-transitory computer storage medium encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform a method according to any of claims 1-13.

Images