Asynchronous distributed key generation method and system supporting periodic updating

Abstract

The invention discloses an asynchronous distributed key generation method and system supporting periodic updating. The method comprises the following steps: sharing a first secret sharing value in a high-threshold asynchronous integrity secret sharing instance corresponding to a first server; according to the received first secret sharing value, proposing to the asynchronous Byzantine negotiation instance which can be re-voted and corresponds to the second server; generating a current private key and a current public key of the first server according to the decision of the asynchronous Byzantine negotiation instance which can be re-voted and corresponds to the second server; and obtaining a private key updating part of the first server by taking 0 as a second secret sharing value of high-threshold asynchronous integrity secret sharing at intervals of a preset period, taking a superposition value of the private key updating part and the current private key as a current private key updated by the first server, and updating the current public key at the same time. The method is low in time complexity, can support a private key serving as a domain element and a high threshold, and can support periodically updating public and private keys to be globally unchanged.

Description

Technical Field

[0001] The present invention relates to the field of distributed computing technology, and in particular, to an asynchronous distributed key generation method and system supporting periodic update. Background Art

[0002] This section aims to provide background or context for the embodiments of the present invention stated in the claims. The description herein is not admitted to be prior art merely because it is included in this section.

[0003] To ensure the security of a distributed system, private keys must be better managed. In practice, private keys should be generated in a decentralized manner and updated regularly; otherwise, single-point errors and collusion attacks will occur. Such a service is called a Distributed Key Management Service (DKMS), which aims to manage the life cycle of encryption keys without any trusted third party.

[0004] DKMS has two core building blocks: 1) An Asynchronous Distributed Key Generation module (ADKG) supporting periodic update: Servers jointly generate public-private key pairs, enabling each server to obtain corresponding public-private key shares; 2) Asynchronous Distributed Key Refresh (ADKR), which allows servers to refresh private keys (to prevent an adversary from stealing private keys by compromising more than the threshold number of servers over the system running time).

[0005] However, existing ADKG and ADKR only solve key management in a synchronous environment and cannot achieve asynchronous key management in an asynchronous environment. Among them, existing ADKG cannot achieve a time complexity of O(1) and does not support domain elements as private keys and high thresholds; while existing ADKR cannot guarantee the global invariance of public and private keys, which results in the unavailability of signatures and ciphertexts saved in previous distributed systems.

[0006] Currently, there is a lack of an asynchronous distributed key generation scheme supporting periodic update to solve the above problems. Summary of the Invention

[0007] Embodiments of the present invention provide an asynchronous distributed key generation method supporting periodic update, which can implement asynchronous distributed key generation in an asynchronous environment, has a low time complexity, can support domain elements as private keys and high thresholds, and can support the global invariance of public and private keys during periodic update. The method is applied to a first server in an asynchronous distributed system, and the first server is any server in the asynchronous distributed system, and includes:

[0008] Share a first secret sharing value in a high-threshold asynchronous integrity secret sharing instance corresponding to the first server;

[0009] Propose to the re-votable asynchronous Byzantine agreement instance corresponding to the second server according to the first secret share value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server, where the second server is other servers in the asynchronous distributed system except the first server;

[0010] Generate the private key and public key of the first server according to the decision of the re-votable asynchronous Byzantine agreement instance corresponding to the second server, and use them as the current private key and current public key of the first server;

[0011] Every preset period, obtain the private key update part of the first server by using 0 as the second secret share value shared by the high-threshold asynchronous integrity secret sharing, and use the superposition value of the private key update part and the current private key as the updated current private key of the first server, and update the current public key of the first server at the same time.

[0012] An embodiment of the present invention provides an asynchronous distributed key generation system supporting periodic update, which can implement asynchronous distributed key generation in an asynchronous environment, has a low time complexity, can support domain elements as private keys and high thresholds, and can support periodic update of public and private keys with global invariance. The system is applied to the first server in the asynchronous distributed system, where the first server is any server in the asynchronous distributed system. The system includes:

[0013] An asynchronous distributed key generation module, configured to share a first secret share value in the high-threshold asynchronous integrity secret sharing instance corresponding to the first server; propose to the re-votable asynchronous Byzantine agreement instance corresponding to the second server according to the first secret share value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server, where the second server is other servers in the asynchronous distributed system except the first server; generate the private key and public key of the first server according to the decision of the re-votable asynchronous Byzantine agreement instance corresponding to the second server, and use them as the current private key and current public key of the first server; an asynchronous distributed key update module, configured to obtain the private key update part of the first server by using 0 as the second secret share value shared by the high-threshold asynchronous integrity secret sharing every preset period, and use the superposition value of the private key update part and the current private key as the updated current private key of the first server, and update the current public key of the first server at the same time.

[0014] An embodiment of the invention also provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the above-mentioned asynchronous distributed key generation method supporting periodic update is implemented.

[0015] An embodiment of the present invention further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned asynchronous distributed key generation method supporting periodic update is implemented.

[0016] An embodiment of the present invention further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the above-mentioned asynchronous distributed key generation method supporting periodic update is implemented.

[0017] In an embodiment of the present invention, a first secret sharing value is shared in a high-threshold asynchronous integrity secret sharing instance corresponding to a first server; according to the first secret sharing value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server, a proposal is made to a re-votable asynchronous Byzantine consensus instance corresponding to the second server, where the second server is other servers in the asynchronous distributed system except the first server; according to the decision of the re-votable asynchronous Byzantine consensus instance corresponding to the second server, a private key and a public key of the first server are generated as the current private key and the current public key of the first server; every preset period, by using 0 as the second secret sharing value shared by the high-threshold asynchronous integrity secret sharing, a private key update part of the first server is obtained, and the superposition value of the private key update part and the current private key is used as the updated current private key of the first server, and at the same time, the current public key of the first server is updated. Through the above process, the time complexity can be O(1) during the generation process of the private key and the public key. Since the high-threshold asynchronous complete secret sharing instance adopted in the embodiment of the present invention shares secrets with domain elements itself and uses commitments as proofs provided to other servers, in the final reconstruction process, the final domain elements are used as private keys and group elements are used as public keys, so the solution proposed in the embodiment of the present invention supports domain elements as private keys; in addition, since the high-threshold asynchronous complete secret sharing instance is constructed by a random matrix extraction method, the conversion from low-threshold asynchronous complete secret sharing to high-threshold asynchronous distributed key generation can be realized, so that the solution proposed in the embodiment of the present invention supports high thresholds. In addition, in the embodiment of the present invention, the private key and the public key are updated every preset period. When updating, by using 0 as the second secret sharing value shared by the high-threshold asynchronous integrity secret sharing, the set formed by the shares of 0 obtained for the private key update part can be 0, and the superposition value of the share of 0 and the current private key can make the updated private key still equal to the old private key after recovery. Description of the Drawings

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings. In the drawings:

[0019] Figure 1 It is a flowchart of an asynchronous distributed key generation method supporting periodic update in an embodiment of the present invention;

[0020] Figure 2 It is a flowchart of asynchronous distributed key update in an embodiment of the present invention;

[0021] Figure 3 It is a schematic diagram of an asynchronous distributed key generation system supporting periodic update in an embodiment of the present invention;

[0022] Figure 4 It is an example of an asynchronous distributed key generation system supporting periodic update in an embodiment of the present invention;

[0023] Figure 5 It is a schematic diagram of the delay comparison between three implementations of asynchronous distributed key generation in an embodiment of the present invention and existing protocols;

[0024] Figure 6 It is a schematic diagram of a computer device in an embodiment of the present invention. Detailed implementation manners

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following further elaborates on the embodiments of the present invention with reference to the drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but not to limit the present invention.

[0026] Figure 1 It is a flowchart of an asynchronous distributed key generation method supporting periodic update in an embodiment of the present invention. The method is applied to a first server in an asynchronous distributed system, and the first server is any server in the asynchronous distributed system. The method includes:

[0027] Step 101: Share a first secret sharing value in a high-threshold asynchronous integrity secret sharing instance corresponding to the first server;

[0028] Step 102: Propose to a re-votable asynchronous Byzantine consensus instance corresponding to the second server according to the first secret sharing value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server. The second server is other servers in the asynchronous distributed system except the first server;

[0029] Step 103: Generate the private key and public key of the first server according to the decision of the asynchronous Byzantine negotiation instance with re-votable property corresponding to the second server, and use them as the current private key and current public key of the first server.

[0030] Step 104: Every preset period, obtain the updated part of the private key of the first server by using 0 as the second secret sharing value of the high-threshold asynchronous integrity secret sharing, and use the superposition value of the updated part of the private key and the current private key as the updated current private key of the first server, and update the current public key of the first server at the same time.

[0031] The following introduces each step in detail. Through the above process, the time complexity can be O(1) during the generation process of the private key and public key. Since the high-threshold asynchronous complete secret sharing instance adopted in the embodiment of the present invention itself performs secret sharing with domain elements and uses commitments as proofs provided to other servers, in the final reconstruction process, the final domain elements are used as the private key and the group elements are used as the public key. Therefore, the solution proposed in the embodiment of the present invention supports domain elements as the private key; in addition, since the high-threshold asynchronous complete secret sharing instance is constructed by the random matrix extraction method, the conversion from the low-threshold asynchronous complete secret sharing to the high-threshold asynchronous distributed key generation can be realized, so that the solution proposed in the embodiment of the present invention supports high thresholds. In addition, in the embodiment of the present invention, the private key and public key are updated every preset period. When updating, by using 0 as the second secret sharing value of the high-threshold asynchronous integrity secret sharing, the set formed by the shares of 0 obtained for the updated part of the private key can be 0, and the superposition value of the share of 0 and the current private key can make the updated private key still equal to the old private key after recovery.

[0032] In the embodiment of the present invention, the asynchronous distributed key generation supporting periodic update includes two stages: asynchronous distributed key generation (Steps 101 - 103) and asynchronous distributed key update (Step 104).

[0033] Asynchronous Distributed Key Generation (ADKG) is used to securely distribute keys in an asynchronous environment. In this process, each correct server finally has a part of the private key (or the private key of the server) and the global public key, and at the same time ensures that the generated set of private keys can be used to interpolate and recover the global private key.

[0034] During Asynchronous Distributed Key Update (ADKR), it is assumed that in an asynchronous environment, each server holds the share of the private key as its private key and sets the global public key. At the end of the ADKR process, each server refreshes its private key to a new one, and the recovered updated private key is still equal to the old private key.

[0035] Steps 101 - 103 are the first implementation of asynchronous distributed key generation, which can be called ADKG - V1.

[0036] ADKG - V1 uses high - threshold asynchronous integrity secret sharing (HACSS) instances and re - votable asynchronous Byzantine agreement (RABA) instances. Generally speaking, to reach a consensus, it follows the PACE paradigm. The consensus protocol uses the HACSS.share primitive of HACSS, that is, sharing, and the expressions of propose, respond, and decide of RABA.

[0037] In the embodiments of the present invention, the solution involves n parallel HACSS instances and n parallel RABA instances, where n is the number of servers in the asynchronous distributed system.

[0038] In step 101, a first secret sharing value is shared in the high - threshold asynchronous integrity secret sharing instance corresponding to the first server.

[0039] Specifically, each server Pi shares a first secret value s in the i - th HACSS instance through HACSS.share i .

[0040] In step 102, according to the first secret sharing value received from the high - threshold asynchronous integrity secret sharing instance corresponding to the second server, a proposal is made to the re - votable asynchronous Byzantine agreement instance corresponding to the second server, where the second server is other servers in the asynchronous distributed system except the first server.

[0041] In one embodiment, step 102 includes:

[0042] After receiving a first secret sharing value from the high - threshold asynchronous integrity secret sharing instance HACSSj corresponding to the second server Pj a proposal of 1 is made to the re - votable asynchronous Byzantine agreement instance RABAj corresponding to the second server Pj;

[0043] After receiving the first quantity n - f of high - threshold asynchronous integrity secret sharing instances, a proposal of 0 is made to all the re - votable asynchronous Byzantine agreement instances that have not started yet.

[0044] Among them, f is the number of faulty servers. Specifically, after receiving the first quantity n - f of high - threshold asynchronous integrity secret sharing instances, instead of waiting for n - f RABA instances to terminate, Pi proposes 0 to all the RABA instances that have not started yet.

[0045] In step 103, according to the decision of the asynchronous Byzantine agreement instance with re-votable property corresponding to the second server, generate the private key and public key of the first server as the current private key and current public key of the first server;

[0046] In one embodiment, step 103 includes:

[0047] If a first secret sharing value is received from the high-threshold asynchronous integrity secret sharing instance corresponding to the second server, and a proposal 1 has been made for the asynchronous Byzantine agreement instance with re-votable property corresponding to the second server, and the asynchronous Byzantine agreement instance with re-votable property corresponding to the second server has not terminated, respond 1 to the asynchronous Byzantine agreement instance with re-votable property corresponding to the second server, and the asynchronous Byzantine agreement instance with re-votable property determines the output decision according to the response;

[0048] Obtain the decision output by the asynchronous Byzantine agreement instance with re-votable property;

[0049] Add the identifiers of the second servers corresponding to all the asynchronous Byzantine agreement instances with re-votable property whose decisions are 1 to the first set;

[0050] When all the asynchronous Byzantine agreement instances with re-votable property have terminated, and all the high-threshold asynchronous integrity secret sharing instances corresponding to the first set have been received, obtain the first shared set corresponding to the first set, and the first shared set is the set formed by the sharing of the first secret sharing value;

[0051] Take the first shared set as the private key of the first server, and generate the public key of the first server according to the private key of the first server.

[0052] Specifically, if Pi later receives a secret sharing value from some DACSS j and it has made a proposal 1 for RABA j and has not terminated RABA j , then it responds 1 to RABA j . Let cS represent the set of identifiers of the second servers whose decisions for RABA j are 1. When all the RABA instances have terminated, and all the DACSS i (i ∈ cs) instances have been received, Pi outputs the set K corresponding to cs on the local server. K is the first shared set and contains the sharing of the first secret sharing value. For this specific scheme, the private key of the i-th server is 's sharing.

[0053] Here, the embodiment of the present invention uses a RABA instance that does not depend on any initial settings. At the same time, since HACSS also does not require initial settings, the above-mentioned asynchronous distributed key generation ADKG-V1 does not require any trusted settings.

[0054] The embodiment of the present invention also proposes two ADKG implementations: ADKG-V2 & ADKG-V3. Among them, ADKG-V1 and ADKG-V2 do not depend on the PKI assumption and random cycle, and support domain elements as private keys and high thresholds.

[0055] In ADKG-V2, the HACSS and RABA instances described in ADKG-V1 are implemented. The optimization lies in that ADKG-V2 implements a faster curve25519 written in assembly language. Based on the Go implementation of ed25519, the curve25519 implementation is extended by adding additional interfaces for domain operations (such as sampling random scalars, calculating inverses, division, etc.).

[0056] In ADKG-V3, the embodiment of the present invention uses a random extraction technique based on a reversible matrix. Different from ADKG-V1, ADKG-V3 does not use the described HACSS instance, but uses low-threshold ACSS, RABA, and random extraction to construct a high-threshold asynchronous integrity secret sharing instance. Like the DXKR protocol, ADKG-V3 also has four stages: sharing, consensus, randomness extraction, and key derivation stages, which will not be elaborated here. Refer to the DXKR protocol.

[0057] The asynchronous distributed key update has three implementations like ADKG. Step 104 can be called ADKR-V1, corresponding to ADKG-V1. In addition, ADKR-V2 corresponds to ADKG-V2, and ADKR-V3 corresponds to ADKG-V3. Only ADKR-V1 is introduced here.

[0058] In step 104, every preset period, by using 0 as the second secret sharing value shared by the high-threshold asynchronous integrity secret sharing, the private key update part of the first server is obtained, and the superposition value of the private key update part and the current private key is used as the current private key updated by the first server. At the same time, the current public key of the first server is updated.

[0059] Figure 2 This is the flowchart of the asynchronous distributed key update in the embodiment of the present invention. Key update requires each server to hold a corresponding private key and public key. When the key is updated, each server uses the GenZeroPoly protocol to generate a new key pair.

[0060] In one embodiment, by using the second secret sharing value shared by asynchronous integrity secret sharing with 0 as the high threshold, it can be achieved that the updated private key remains equal to the old private key after recovery, including:

[0061] Step 201, share a second secret sharing value in the high-threshold asynchronous integrity secret sharing instance corresponding to the first server, and the second secret sharing value is 0;

[0062] Step 202, verify the second secret sharing value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server;

[0063] Specifically, in the HACSS stage, each server Pi shares a second secret sharing value in the i-th HACSS instance through HACSS.share. In this application, the second secret sharing value is 0. If server Pi receives a second secret sharing value from the i-th HACSS instance, server Pi verifies the second secret sharing value. When verifying, it is necessary to determine whether G j = g c holds, where, when each server is initially set up, G i ← g e , and e is the second secret sharing value, that is, 0. If it holds, it is determined that the verification passes.

[0064] Step 203, according to the verification result, propose to the re-votable asynchronous Byzantine agreement instance corresponding to the second server;

[0065] In one embodiment, according to the verification result, proposing to the re-votable asynchronous Byzantine agreement instance corresponding to the second server includes:

[0066] When the verification result is that the verification passes, propose 1 to the re-votable asynchronous Byzantine agreement instance corresponding to the second server, otherwise propose 0;

[0067] After receiving the first quantity n - f of high-threshold asynchronous integrity secret sharing instances, propose 0 to all the re-votable asynchronous Byzantine agreement instances that have not started yet.

[0068] Specifically, if the verification passes, server Pi proposes 1 in RABA j ; if the verification fails, propose 0. When Pi receives n - f HACSS instances, instead of waiting for n - f RABA instances to terminate, Pi proposes 0 to all the RABA instances that have not started yet.

[0069] Step 204, generate the private key update part of the first server according to the decision of the re-votable asynchronous Byzantine agreement instance corresponding to the second server.

[0070] In one embodiment, a private key update part of the first server is generated according to a decision of a re-votable asynchronous Byzantine consensus instance corresponding to the second server, including:

[0071] If a second secret sharing value is received from a high-threshold asynchronous integrity secret sharing instance corresponding to the second server, and a proposal 1 has been made for the re-votable asynchronous Byzantine consensus instance corresponding to the second server, and the re-votable asynchronous Byzantine consensus instance corresponding to the second server has not terminated, respond 1 to the re-votable asynchronous Byzantine consensus instance corresponding to the second server, and the re-votable asynchronous Byzantine consensus instance determines an output decision according to the response;

[0072] Obtain the decision output by the re-votable asynchronous Byzantine consensus instance;

[0073] Add the identifiers of the second servers corresponding to all the re-votable asynchronous Byzantine consensus instances with a decision of 1 to the second set;

[0074] When all the re-votable asynchronous Byzantine consensus instances have terminated, and all the high-threshold asynchronous integrity secret sharing instances corresponding to the first set have been received, obtain a second shared set corresponding to the second set, where the second shared set is a set formed by the sharing of the second secret sharing value;

[0075] Use the second shared set as the private key update part of the first server.

[0076] Specifically, if Pi later receives a second secret sharing value from some HACSS j and has proposed 1 for RABA j and has not terminated RABA j , then it responds 1 to RABA j .

[0077] Let ds represent the set of identifiers of the second servers with a decision of 1 for RABA in this update phase. When all the RABA instances have terminated, and all the DACSS j (i∈cs) instances have been received, Pi outputs the set M corresponding to ds on the local server. M is the second shared set and contains the sharing of the second secret sharing value. i (i∈cs) instances have been received, Pi outputs the set M corresponding to ds on the local server. M is the second shared set and contains the sharing of the second secret sharing value.

[0078] An embodiment of the present invention also proposes an asynchronous distributed key generation system supporting periodic updates, the principle of which is similar to the asynchronous distributed key generation method supporting periodic updates, and will not be elaborated here.

[0079] Figure 3Schematic diagram of an asynchronous distributed key generation system supporting periodic updates in an embodiment of the present invention, including: a first server applied to an asynchronous distributed system, including:

[0080] An asynchronous distributed key generation module 301, configured to share a first secret sharing value in a high-threshold asynchronous integrity secret sharing instance corresponding to the first server; propose to a re-votable asynchronous Byzantine consensus instance corresponding to the second server according to the first secret sharing value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server, where the second server is other servers in the asynchronous distributed system except the first server; generate a private key and a public key of the first server according to the decision of the re-votable asynchronous Byzantine consensus instance corresponding to the second server, as the current private key and the current public key of the first server;

[0081] An asynchronous distributed key update module 302, configured to obtain a private key update part of the first server by using 0 as the second secret sharing value shared by the high-threshold asynchronous integrity secret sharing every preset period, and use the superposition value of the private key update part and the current private key as the updated current private key of the first server, and update the current public key of the first server at the same time.

[0082] In one embodiment, the asynchronous distributed key generation module 301 is configured to:

[0083] After receiving a first secret sharing value from the high-threshold asynchronous integrity secret sharing instance corresponding to the second server, propose 1 to the re-votable asynchronous Byzantine consensus instance corresponding to the second server;

[0084] After receiving the first number of high-threshold asynchronous integrity secret sharing instances, propose 0 to all the re-votable asynchronous Byzantine consensus instances that have not started.

[0085] In one embodiment, the asynchronous distributed key generation module 301 is configured to:

[0086] If a first secret sharing value is received from the high-threshold asynchronous integrity secret sharing instance corresponding to the second server, and 1 has been proposed to the re-votable asynchronous Byzantine consensus instance corresponding to the second server, and the re-votable asynchronous Byzantine consensus instance corresponding to the second server has not been terminated, respond 1 to the re-votable asynchronous Byzantine consensus instance corresponding to the second server, and the re-votable asynchronous Byzantine consensus instance determines the output decision according to the response;

[0087] Obtain the decision output by the re-votable asynchronous Byzantine consensus instance;

[0088] Add the identifiers of the second servers corresponding to all the re-votable asynchronous Byzantine consensus instances with a decision of 1 to the first set;

[0089] When all re - votable asynchronous Byzantine agreement instances terminate, and all high - threshold asynchronous integrity secret sharing instances corresponding to the first set are received, a first shared set corresponding to the first set is obtained, where the first shared set is a set formed by sharing of first secret sharing values;

[0090] Take the first shared set as the private key of the first server, and generate the public key of the first server according to the private key of the first server.

[0091] In one embodiment, the asynchronous distributed key update module is used for:

[0092] Share a second secret sharing value in the high - threshold asynchronous integrity secret sharing instance corresponding to the first server, where the second secret sharing value is 0;

[0093] Verify the second secret sharing value of the high - threshold asynchronous integrity secret sharing instance corresponding to the received second server;

[0094] According to the verification result, propose to the re - votable asynchronous Byzantine agreement instance corresponding to the second server, where the second server is other servers in the asynchronous distributed system except the first server;

[0095] Generate a private key update part of the first server according to the decision of the re - votable asynchronous Byzantine agreement instance corresponding to the second server.

[0096] In one embodiment, the asynchronous distributed key update module is used for:

[0097] When the verification result is passed, propose 1 to the re - votable asynchronous Byzantine agreement instance corresponding to the second server, otherwise propose 0;

[0098] After receiving the first quantity n - f of high - threshold asynchronous integrity secret sharing instances, propose 0 to all re - votable asynchronous Byzantine agreement instances that have not started.

[0099] In one embodiment, the asynchronous distributed key update module is used for:

[0100] If a second secret sharing value is received from the high - threshold asynchronous integrity secret sharing instance corresponding to the second server, and 1 has been proposed to the re - votable asynchronous Byzantine agreement instance corresponding to the second server, and the re - votable asynchronous Byzantine agreement instance corresponding to the second server has not terminated, respond 1 to the re - votable asynchronous Byzantine agreement instance corresponding to the second server, and the re - votable asynchronous Byzantine agreement instance determines the output decision according to the response;

[0101] Obtain the decision output by the asynchronous Byzantine negotiation instance with re-votability;

[0102] Add the identifiers of the second servers corresponding to the asynchronous Byzantine negotiation instances with re-votability that all decide 1 to the second set;

[0103] When all the asynchronous Byzantine negotiation instances with re-votability terminate and all the high-threshold asynchronous integrity secret sharing instances corresponding to the first set are received, obtain a second shared set corresponding to the second set, where the second shared set is a set formed by the sharing of the second secret sharing values;

[0104] Use the second shared set as the private key update part of the first server.

[0105] In the method proposed in the embodiments of the present invention, ADKG and ADKR assume that the adversary can at most break n - 1 / 3 servers. However, when the time of the asynchronous distributed system becomes longer, the adversary can control malicious servers, try to steal the private keys from correct servers, or recover the content of the private keys by sending malicious requests to correct servers. At this time, it is necessary to periodically run key updates on the servers in the distributed system and delete the old private keys saved in the original servers. Even if a malicious server obtains the private key of a correct server, since the key is updated, the behavior of the malicious server is in vain.

[0106] Figure 4 This is an example of an asynchronous distributed key generation system supporting periodic updates in the embodiments of the present invention. The asynchronous distributed key generation system supporting periodic updates (DKMS system) initializes the private keys of each server and the global public key by running an asynchronous distributed key generation module. Every once in a while T (which can be called a period), the asynchronous distributed key generation system supporting periodic updates needs to run an asynchronous distributed key update module to update the keys. Assume that the adversary breaks server P0; in period 1, the adversary obtains the private key sk1' of p1; in period 2, the adversary obtains the private key sk2" of P2. After the end of period 2, the adversary has obtained sk0, sk0', sk0", sk1', sk2" in total (it should be noted that the adversary breaks server P0, so it can obtain the private keys of P0 in any period), but cannot reconstruct the private key sk. This is because the adversary can only complete key recovery by obtaining two private keys from different servers in the same period.

[0107] Therefore, in the constructed DKMS system, it is necessary to reasonably set the size of the period so that the adversary cannot collect enough private keys in the same period. The specific period value can be obtained through repeated experiments.

[0108] Deploy the method proposed in the embodiments of the present disclosure in multiple asynchronous distributed systems, and set the number of nodes to be 4, 13, 25, 49, and 64 respectively. Figure 5 It is a schematic diagram comparing the latency of three implementations of three asynchronous distributed key generations in the embodiments of the present invention with existing protocols. It can be seen that the latency of the existing DYX+ protocol is the highest, which is 4.6 times, 7.2 times, and 8.2 times that of the three protocols ADKG-V1, ADKG-V2, and ADKG-V3 in the embodiments of the present invention respectively. And when n is less than 16, the latency of the method of the present invention is lower than that of the current protocol DXKR.

[0109] In summary, in the method and system proposed in the embodiments of the present invention, a first secret sharing value is shared in a high-threshold asynchronous integrity secret sharing instance corresponding to a first server; according to the first secret sharing value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server, a proposal is made to a re-votable asynchronous Byzantine agreement instance corresponding to the second server, where the second server is other servers in the asynchronous distributed system except the first server; according to the decision of the re-votable asynchronous Byzantine agreement instance corresponding to the second server, a private key and a public key of the first server are generated as the current private key and the current public key of the first server; every preset period, by using 0 as the second secret sharing value shared by the high-threshold asynchronous integrity secret sharing, a private key update part of the first server is obtained, and the superposition value of the private key update part and the current private key is used as the updated current private key of the first server, and the current public key of the first server is updated at the same time. Through the above process, the time complexity can be O(1) during the generation process of the private key and the public key. Since the high-threshold asynchronous perfect secret sharing instance adopted in the embodiments of the present invention itself shares secrets with domain elements and uses commitments as proofs provided to other servers, in the final reconstruction process, the last domain element is used as the private key and the group element is used as the public key, so the solution proposed in the embodiments of the present invention supports domain elements as private keys; in addition, since the high-threshold asynchronous perfect secret sharing instance is constructed by a random matrix extraction method, the conversion from low-threshold asynchronous perfect secret sharing to high-threshold asynchronous distributed key generation can be realized, so that the solution proposed in the embodiments of the present invention supports high thresholds. In addition, in the embodiments of the present invention, the private key and the public key are updated every preset period, and when updating, by using 0 as the second secret sharing value shared by the high-threshold asynchronous integrity secret sharing, the set formed by the shares of 0 obtained for the private key update part can be 0, and the superposition value of the share of 0 and the current private key can make the updated private key still equal to the old private key after recovery.

[0110] The embodiments of the present invention also provide a computer device, Figure 6Schematic diagram of a computer device in an embodiment of the present invention. The computer device 600 includes a memory 610, a processor 620, and a computer program 630 stored on the memory 610 and executable on the processor 620. When the processor 620 executes the computer program 630, the above data visualization method based on the data exchange model is implemented.

[0111] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above data visualization method based on the data exchange model.

[0112] An embodiment of the present invention further provides a computer program product including a computer program, which, when executed by a processor, implements the above data visualization method based on the data exchange model.

[0113] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0114] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the specified functions in Figure 1 one or more of the processes Figure 1 or multiple processes and / or blocks

[0115] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means for implementing the specified functions in Figure 1 one or more of the processes Figure 1 or multiple processes and / or blocks

[0116] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operation steps are performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions for implementing the steps of the process Figure 1 a process or processes and / or blocks Figure 1 steps for the functions specified in a block or blocks.

[0117] The specific embodiments described above have further elaborated on the objectives, technical solutions, and beneficial effects of the present invention. It should be understood that the above are only specific embodiments of the present invention and are not intended to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims

1. An asynchronous distributed key generation method supporting periodic updates, characterized in that, A first server applied to an asynchronous distributed system, where the first server is any server in the asynchronous distributed system, including: Sharing a first secret sharing value in a high-threshold asynchronous integrity secret sharing instance corresponding to the first server; Proposing to a re-votable asynchronous Byzantine consensus instance corresponding to the second server according to the first secret sharing value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server, where the second server is other servers in the asynchronous distributed system except the first server; Generating a private key and a public key of the first server according to the decision of the re-votable asynchronous Byzantine consensus instance corresponding to the second server, and using them as the current private key and the current public key of the first server; Every preset period, obtaining a private key update part of the first server by using 0 as the second secret sharing value shared by the high-threshold asynchronous integrity secret sharing, and using the superposition value of the private key update part and the current private key as the updated current private key of the first server, and simultaneously updating the current public key of the first server.

2. The method according to claim 1, wherein Proposing to a re-votable asynchronous Byzantine consensus instance corresponding to the second server according to the first secret sharing value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server, including: After receiving a first secret sharing value from the high-threshold asynchronous integrity secret sharing instance corresponding to the second server, proposing 1 to the re-votable asynchronous Byzantine consensus instance corresponding to the second server; After receiving the first quantity of high-threshold asynchronous integrity secret sharing instances, proposing 0 to all the re-votable asynchronous Byzantine consensus instances that have not started.

3. The method according to claim 1, wherein Generating a private key and a public key of the first server according to the decision of the re-votable asynchronous Byzantine consensus instance corresponding to the second server, including: If receiving a first secret sharing value from the high-threshold asynchronous integrity secret sharing instance corresponding to the second server, and having proposed 1 to the re-votable asynchronous Byzantine consensus instance corresponding to the second server, and the re-votable asynchronous Byzantine consensus instance corresponding to the second server has not terminated, responding 1 to the re-votable asynchronous Byzantine consensus instance corresponding to the second server, and the re-votable asynchronous Byzantine consensus instance determines the output decision according to the response; Obtaining the decision output by the re-votable asynchronous Byzantine consensus instance; Adding the identifiers of the second servers corresponding to all the re-votable asynchronous Byzantine consensus instances with the decision being 1 to the first set; When all the re-votable asynchronous Byzantine consensus instances terminate and all the high-threshold asynchronous integrity secret sharing instances corresponding to the first set are received, obtaining a first shared set corresponding to the first set, where the first shared set is a set formed by the sharing of the first secret sharing value; Using the first shared set as the private key of the first server, and generating the public key of the first server according to the private key of the first server.

4. The method according to claim 1, characterized in that, By using 0 as the second secret sharing value shared by the high-threshold asynchronous integrity secret sharing, it can be achieved that the updated private key is still equal to the old private key after recovery, including: Share a second secret share value in the high-threshold asynchronous integrity secret sharing instance corresponding to the first server, where the second secret share value is 0; Verify the second secret share value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server; Propose to the re-votable asynchronous Byzantine agreement instance corresponding to the second server according to the verification result, where the second server is other servers in the asynchronous distributed system except the first server; Generate a private key update part of the first server according to the decision of the re-votable asynchronous Byzantine agreement instance corresponding to the second server.

5. The method according to claim 4, characterized in that, Propose to the re-votable asynchronous Byzantine agreement instance corresponding to the second server according to the verification result, including: When the verification result is passed, propose 1 to the re-votable asynchronous Byzantine agreement instance corresponding to the second server, otherwise propose 0; After receiving the high-threshold asynchronous integrity secret sharing instances of the first quantity n - f, propose 0 to all the re-votable asynchronous Byzantine agreement instances that have not started.

6. The method according to claim 4, wherein, Generate a private key update part of the first server according to the decision of the re-votable asynchronous Byzantine agreement instance corresponding to the second server, including: If a second secret share value is received from the high-threshold asynchronous integrity secret sharing instance corresponding to the second server, and 1 has been proposed to the re-votable asynchronous Byzantine agreement instance corresponding to the second server, and the re-votable asynchronous Byzantine agreement instance corresponding to the second server has not terminated, respond 1 to the re-votable asynchronous Byzantine agreement instance corresponding to the second server, and the re-votable asynchronous Byzantine agreement instance determines the output decision according to the response; Obtain the decision output by the re-votable asynchronous Byzantine agreement instance; Add the identifiers of the second servers corresponding to all the re-votable asynchronous Byzantine agreement instances with the decision being 1 to the second set; When all the re-votable asynchronous Byzantine agreement instances have terminated and all the high-threshold asynchronous integrity secret sharing instances corresponding to the first set have been received, obtain a second shared set corresponding to the second set, where the second shared set is a set formed by the sharing of the second secret share value; Use the second shared set as the private key update part of the first server.

7. An asynchronous distributed key generation system supporting periodic updates, characterized in that, Applied to the first server in the asynchronous distributed system, where the first server is any server in the asynchronous distributed system, including: An asynchronous distributed key generation module, used to share a first secret share value in the high-threshold asynchronous integrity secret sharing instance corresponding to the first server; propose to the re-votable asynchronous Byzantine agreement instance corresponding to the second server according to the first secret share value of the high-threshold asynchronous integrity secret sharing instance corresponding to the received second server, where the second server is other servers in the asynchronous distributed system except the first server; generate the private key and public key of the first server according to the decision of the re-votable asynchronous Byzantine agreement instance corresponding to the second server, and use them as the current private key and current public key of the first server; An asynchronous distributed key update module, which is used to obtain a private key update part of the first server by using 0 as the second secret sharing value of the asynchronous integrity secret sharing with a high threshold every preset period, and use the superimposed value of the private key update part and the current private key as the current private key updated by the first server, and update the current public key of the first server at the same time.

8. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program, and when the computer program is executed by a processor, it implements the method according to any one of claims 1 to 6.

Images