System and method for hash-based PQC multiple signature and computer readable medium thereof

Abstract

A system and a method for hash-based post-quantum cryptography (PQC) multiple signature are provided, which generate a plurality of signature requests for a plurality of signature devices based on a message. Each signature device produces, in parallel processing, a hash signature of the signature device based on the signature request of the signature device, a plurality of Merkle trees and a plurality of one-time signature (OTS) elements in a hash-based hyper-tree of the signature device, and a plurality of few-time signature (FTS) elements connected to the hyper-tree. Next, the message and the hash signatures are assembled to form a multiple hash signature of the message. This parallel processing accelerates the production of the multiple hash signature. The present invention also provides a computer-readable medium for executing the method of the present invention.

Description

[Technical Field]

[0001] This invention relates to post-quantum signature technology, and more particularly to a hash-based post-quantum multi-signature system, method and computer-readable medium thereof. [Previous Technology]

[0002] With the development of quantum computers, current standard public-key cryptosystems, such as the RSA encryption algorithm and elliptic curve cryptography (ECC), will likely be cracked by quantum computers in the near future. Correspondingly, post-quantum cryptography (PQC) is a public-key cryptosystem specifically researched to resist quantum computer attacks. PQC uses existing computers and networks, without relying on quantum mechanics, and resists quantum computer attacks by solving computational problems that cannot be effectively solved by quantum computers.

[0003] Current PQC signature algorithms are divided into two categories based on their underlying technology: lattice-based and hash-based signature algorithms. Algorithms based on lattice cryptography include Dilithium and FALCON. Algorithms based on hashing include SPHINCS+.

[0004] Algorithms based on lattice cryptography utilize mathematical challenges of lattice problems, such as the Shortest Vector Problem (SVP) and the Closest Vector Problem (CVP), to achieve resistance to quantum computer attacks.

[0005] Hash-based signature algorithms utilize a combination of one-time signature (OTS), few-time signature (FTS), and Merkle tree authentication paths to create a signature technology. This technology leverages the collision resistance of hash functions, which quantum algorithms cannot effectively break, to resist quantum computer attacks. Furthermore, its security does not depend on a specific hash function; therefore, even if some hash functions are broken, they can be replaced with more secure ones. In addition, through the security design of the extended Merkle Signature Scheme (XMSS), its security is guaranteed even if the hash function algorithm is broken. Sphincs+ is currently the only hash-based signature algorithm. As the only quantum-resistant algorithm of a different system, it can serve as the only backup algorithm when lattice cryptography signature algorithms are broken, thus possessing unique value.

[0006] However, hash-based signature algorithms are significantly slower than other algorithms in calculating signatures because they require constructing the entire hypertree to calculate the hypertree signature and authentication path, which is very memory-intensive and time-consuming. Therefore, when this signature algorithm is applied to a multi-node message transmission system and multiple signatures are required for the same message, it will become the performance bottleneck of the entire system, resulting in severe delays in message transmission. [Summary of the Invention]

[0007] To solve the above problems, the present invention provides a post-quantum multi-signature method, comprising: generating a signature path, wherein the signature path includes a plurality of signature devices; generating signature requests for each of the signature devices according to a message; causing each of the signature devices to generate a hash signature of the signature device in parallel processing, based on the signature request of the signature device, and based on a plurality of Merkle trees and a plurality of one-time signature (OTS) elements in a hash-based supertree of the signature device, and based on a plurality of finite-time signature (FTS) elements connecting the supertree; and assembling the message and the plurality of hash signatures into a multi-hash signature of the message.

[0008] The present invention further provides a post-quantum multi-signature system, including a master control device and multiple signature devices, the multiple signature devices forming a signature path. The master control device is used to generate multiple signature requests based on a message, and is also used to dispatch each signature request to one of the multiple signature devices. Each signature device is used to generate a hash signature of the signature device in parallel processing, based on the signature request of the signature device, and based on multiple Merkle trees and multiple One-Time Signature (OTS) elements in the hash-based supertree of the signature device, and based on multiple Finite-Time Signature (FTS) elements connected to the supertree. The master control device is also used to assemble the message and the multiple hash signatures into a multiple hash signature of the message.

[0009] The present invention further discloses a computer-readable medium, which is used in a computing device or computer and stores instructions to execute the aforementioned quantum multi-signature method.

[0010] The present invention provides a mechanism for accelerating and parallelizing multi-signature operations, and provides a caching mechanism for some signature operations, thereby achieving a multi-signature acceleration technology that can resist quantum computer attacks and at the same time significantly improve signature performance. [Simplified Explanation of the Diagram]

[0095] Figure 1 is an architecture diagram of the post-quantum multi-signature system of the present invention.

[0096] Figure 2 is a flowchart of the post-quantum multi-signature method of the present invention.

[0097] Figure 3 is a schematic diagram of the superstructure tree of each signature device of the present invention.

[0098] Figure 4 is a structural diagram of the verification device of the present invention.

[0099] Figure 5 is a flowchart of the multi-signature verification method of the present invention.

Implementation Method

[0011] Figure 1 is an architectural diagram of the post-quantum multi-signature system 10 of the present invention. The post-quantum multi-signature system 10 includes a master control device 11 and multiple signing devices 12. In one embodiment, the master control device 11 and each signing device 12 are independent computers or servers.

[0012] Although Figure 1 shows five signature devices 12, the present invention does not limit the number of signature devices 12.

[0013] The main control device 11 includes a signature path generation module 111, a signature request delivery module 112, and a signature assembly module 113. Each signature device 12 includes a signature plaintext generation module 121, a signature index generation module 122, and a signature calculation and retrieval module 123. The signature path generation module 111 in the main control device 11 is communicatively connected to the signature request delivery module 112, and the signature request delivery module 112 is communicatively connected to the signature plaintext generation module 121 of each signature device 12. In each signature device 12, the signature plaintext generation module 121 is communicatively connected to the signature index generation module 122, and the signature index generation module 122 is communicatively connected to the signature calculation and retrieval module 123. The signature calculation and retrieval module 123 of each signature device 12 is communicatively connected to the signature assembly module 113 of the main control device 11.

[0014] Each module 111~113 and 121~123 in Figure 1 can be software, hardware or firmware; if it is hardware, it can be a processing unit, processing core or processor with data processing and computing capabilities; if it is software or firmware, it can include instructions executable by the processing unit, processing core or processor, and can be installed on the same hardware device or distributed in different multiple hardware devices.

[0015] Figure 2 is a flowchart of the post-quantum multisignature method executed by the post-quantum multisignature system 10. This post-quantum multisignature method can generate multiple hash signatures for a specified message M. The flowchart in Figure 2 is explained below.

[0016] In step 21, the signature path generation module 111 generates a signature path according to the order of the signature devices to be added to the multi-signature operation. This signature path can be all signature devices 12 arranged according to their signature order. For example, if an important transaction message needs to be confirmed by multiple parties, each signature device 12 can represent one of the parties, and the confirmation operation is to perform a signature operation on the transaction message. As another example, if an approval process needs to be confirmed through multiple checkpoints, each signature device 12 can perform confirmation at one of the checkpoints.

[0017] In step 22, the signature request dispatch module 112 generates a corresponding signature request for each signature device 12 in the signature path, and simultaneously dispatches the signature request to each signature device. If there are N+1 signature devices 12 (N can be any positive integer), each signature device 12 can be assigned a number from 0 to N, and the content of the signature request for each signature device n (0≦n≦N) is as follows:

[0018] If n>0, then its signature request contains {M,PK(n-1)}, where M is the aforementioned message that needs to generate multiple hash signatures, and PK(n-1) is the public key of the previous signature device (i.e., signature device n-1) in the signature path or signature sequence.

[0019] If n=0, then its signature request does not contain the public key of the previous signature device, so its signature request contains {M}.

[0020] The subsequent steps 23 to 25 are executed in parallel by each signing device, as explained below.

[0021] In step 23, after receiving the signing request, the signature plaintext generation module 121 of each signing device generates the signature plaintext Cn for subsequent signing operations according to the request content. The generation method is as follows:

[0022] If n>0, then Cn=M∥PK(n-1), where ∥ represents the concatenation operation, that is, concatenating M and PK(n-1) in the signature request together.

[0023] If n=0, then Cn=M.

[0024] In hash-based signature technology, the signature value, plaintext, and public key are interdependent. Traditional multi-signature operations, in order to establish dependency with the previous signing device, require the signature content of the previous device to be used as part of the plaintext for calculating the signature. However, this necessitates waiting for the previous signing device to complete its signature before the next signing device can calculate its signature.

[0025] In contrast, the present invention calculates the signature based on the plaintext and the public key of the previous signing device, thus maintaining the dependency with the previous signing device. Since the plaintext and the public key of each signing device can be obtained in advance, there is no need to wait for the calculation results of other signing devices. Therefore, each signing device can calculate its signature value simultaneously, thereby achieving parallel signing calculation.

[0026] In step 24, the signature index generation module 122 of each signature device generates the signature index of this signature device.

[0027] The signature index is used to specify the authentication path in the hypertree of this signature device. Figure 3 is a schematic diagram of the hypertree 30 of each signature device of the present invention. In one embodiment, as shown in Figure 3, the hypertree 30 may be a structure of height d layers (layer 0 to layer d-1, where d can be any integer greater than 1), wherein the highest layer d-1 includes a Merkle tree 362 and a plurality of One-Time Signature (OTS) elements 361, and each of the remaining layers includes a plurality of Merkle trees and a plurality of OTS elements, for example, a plurality of Merkle trees 352 in layer d-2, or a plurality of Merkle trees 302 and a plurality of OTS elements 301 in layer 0. Each leaf node of each Merkle tree is connected to a corresponding OTS element located in the same layer. Except for layer 0, each OTS element in each layer is connected to the root node of a corresponding Merkle tree in the next layer. Each OTS element 301 in layer 0 is connected to a corresponding finite-time signature (FTS) element 33.

[0028] As can be seen from the above description, the Merkle tree and OTS elements in the supertree 30 are arranged in a tree-like pattern from top to bottom. To avoid making Figure 3 too complicated, Figure 3 only shows a small part of the Merkle tree and OTS elements, and only shows one of the multiple FTS elements 33, as a representative example.

[0029] Each OTS element inputs its public key into the corresponding leaf node of the corresponding Merkle tree at the same level. Therefore, each leaf node of each Merkle tree is the public key of the corresponding OTS element at the same level. Except for level 0, the input of each OTS element is the root node of the corresponding Merkle tree at the next level. The input of each OTS element 301 at level 0 is the public key of the corresponding FTS element 33.

[0030] A Merkle tree is created by pairwise hashing of two sibling nodes to obtain their hash value, which is then used as the parent node. This process is repeated to merge and calculate the parent node of each sibling node at each level, until the root node is obtained. The root node of the Merkle tree 362 at the highest level (d-1) is the public key PK(n) of this signature device.

[0031] To verify whether a leaf node in a Merkle tree is correct, simply repeat the above steps, performing pairwise operations on each node to obtain hash values, until the same root node is calculated, thus completing the verification. Due to the characteristics of Merkle trees, it is not necessary to record all nodes in the entire tree; only the nodes in its authentication path need to be recorded to calculate the root node.

[0032] For example, taking the Merkle tree 302 in Figure 3 as an example, to verify its leaf node G, it is only necessary to record its sibling node F. The leaf node F and leaf node G are calculated to obtain its parent node E. Then, by recording the sibling node D of node E, its parent node B can be calculated. Then, by recording the sibling node C of node B, the root node A can be calculated. Therefore, the authentication path of leaf node G is the nodes F, D, and C marked with double circles in Merkle tree 302. Merkle trees at higher levels can be deduced in the same way. Each level of each Merkle tree only needs to record one node, so it is not necessary to record all nodes to complete the verification, which greatly reduces the computation time and storage space.

[0033] The supertrees 30 of each signing device have the same structure. However, the OTS and FTS elements in the supertrees 30 of each signing device have different combinations of public and private keys.

[0034] The aforementioned signature index is used to specify a leaf node of a Merkle tree 302 in the 0th level of the supertree 30. Therefore, the signature index includes the number of the Merkle tree 302 in the 0th level of the supertree 30 and the number of the leaf node. As can be seen from Figure 3, there is a unique path between the leaf node and the root node of the Merkle tree 362 in the top d-1 level. Therefore, the signature index can fix the unique path between the leaf node and the root node of the Merkle tree 362, and fix the corresponding authentication path of the unique path. For example, the leaf node specified by the signature index is leaf node G of the Merkle tree 302. Each node on the unique path from leaf node G to the root node of the Merkle tree 362 is marked with a thick circle, while each node on the corresponding authentication path is marked with a double circle.

[0035] The signature index is calculated differently depending on whether the signature device is in accelerated mode.

[0036] If this signing device executes accelerated mode during this signing request, its signing index is calculated as follows:

[0037] First, generate a pseudo-random number R(n).

[0038] R(n)=PRF(PK(n)∥V(n),SK(n)), where PRF is a pseudorandom function, PK(n) is the public key of the signing device, SK(n) is the private key of the signing device, and V(n) is a variable parameter that changes to a new value every certain period of time to change R(n) to recalculate the signature index, thereby controlling whether the hypertree signature needs to be recalculated (details will be described later). For example, V(n) can change according to the number of times the signature index or hypertree signature is used, for example, changing V(n) every 1000 uses.

[0039] Next, use R(n) and PK(n) to generate the signature index.

[0040] {Leaf-Index(layer(0)),Tree-Index(layer(0))}=GenIndexInit(R(n),PK(n))

[0041] Leaf-Index(layer(0)) and Tree-Index(layer(0)) are the leaf node number and Merkle tree number of the 0th layer in the signature index, respectively. GenIndexInit is a function that generates Leaf-Index(layer(0)) and Tree-Index(layer(0)) based on R(n) and PK(n). As long as the inputs are the same R(n) and PK(n), GenIndexInit will generate the same leaf node number and Merkle tree number. For example, GenIndexInit can be a function based on hash.

[0042] If this signing device does not execute the acceleration mode during this signing request, its R(n) value depends on the signed plaintext Cn.

[0043] R(n)=PRF(Cn,SK(n))

[0044] The two numbers of the signature index are dependent on R(n) and Cn.

[0045] {Leaf-Index(layer(0)),Tree-Index(layer(0))}=GenIndexInit(R(n),Cn)

[0046] The signature index may also include the Merkle tree numbers and leaf node numbers traversed by the unique path at each level from level 1 to level d-1. As can be seen from the example in Figure 3, once the Merkle tree numbers traversed by the unique path at a certain level are known, the Merkle tree numbers and leaf node numbers traversed by the unique path at the previous level can be easily deduced.

[0047] Whether to execute the acceleration mode can be decided by each signing device itself, or determined based on other conditions. For example, if the received signing request does not contain the public key of the previous signing device, it can be determined that this signing device is signing device 0 in the signing path, that is, the first signing device in the signing path. Therefore, to improve security, the acceleration mode is not activated. Alternatively, whether to activate the acceleration mode can be flexibly determined by the actual use case and application system design. For example, each signing device can decide whether to activate the acceleration mode based on the importance of its role and permissions or the importance of the process checkpoint it executes.

[0048] In step 25, the signature calculation and retrieval module 123 of each signature device calculates the hash signature of its respective signature device.

[0049] First, the FTS element 33 connected below the leaf node specified by the above-mentioned signature index is used to calculate the FTS element signature FTS-Signature(n) of this signature device, as follows.

[0050] FTS-Signature(n)=FTS-Sign(Cn,Leaf-Index(layer(0)),SK(n))

[0051] The above formula means that the key set of the FTS element is generated using the leaf node number Leaf-Index(layer(0)) in the signature index and the private key SK(n) of this signature device, and the signature plaintext Cn is input into the FTS element to calculate the signature FTS-Signature(n) of this signature device. In other words, FTS-Signature(n) is the digital signature of the signature plaintext Cn calculated by the FTS element.

[0052] The FTS element signature FTS-Signature(n) contains the authentication path of the FTS element, which is different from the authentication path of the supertree 30 described above. Each FTS element 33 includes at least one Merkle tree. The FTS element merges its key set through these Merkle trees to generate the public key of the FTS element. This merging process defines the authentication path of the FTS element, which is part of the FTS element signature FTS-Signature(n).

[0053] Next, calculate the supertree signature HT-Signature(n) of supertree 30, as shown in the following formula.

[0054] HT-Signature(n)=HT-Sign(PK(FTS),Leaf-Index(layer(0)),Tree-Index(layer(0)),SK(n))

[0055] The above formula means that the public key PK(FTS) of the FTS element is input as plaintext into the OTS element 301 connected below the leaf node specified by the signature index Leaf-Index(layer(0)) and Tree-Index(layer(0)) to calculate the supertree signature HT-Signature(n).

[0056] In the calculation of the supertree signature HT-Signature(n), the plaintext input for the signature calculation of the OTS element at level 0 is the public key PK(FTS) of the FTS element, while the plaintext input for the signature calculation of the OTS element at each other level is the root node of the corresponding Merkle tree at the next level. The private key SK(n) of this signature device is used for the signature calculation of each OTS element. The supertree signature HT-Signature(n) includes the authentication path in each Merkle tree (e.g., all nodes marked with double circles in Figure 3) on the unique path from the OTS element below the leaf node specified by the signature index to the root node of the topmost Merkle tree in the supertree 30, and includes the digital signature obtained by the signature calculation of the root node of the Merkle tree connected to the input end (the lower end shown in Figure 3) of each OTS element on the unique path.

[0057] The supertree signature HT-Signature(n) does not need to wait for the signature request containing message M to arrive before it can be calculated. As long as the signature index has been generated, the supertree signature HT-Signature(n) can be calculated in advance. This is because the signing operation of the FTS element does not matter what the content of the signature plaintext Cn is, as long as the signature index remains unchanged, the same public key PK(FTS) of the same FTS element can be obtained, and the same supertree signature HT-Signature(n) can also be obtained.

[0058] Therefore, the signature calculation and caching module 123 can store the supertree signature HT-Signature(n) in the cache. When a signature request is received again, if the signing device is in acceleration mode, the previously calculated supertree signature HT-Signature(n) can be directly retrieved from the cache without having to recalculate the supertree signature HT-Signature(n).

[0059] The cache may be located in the memory or encrypted storage device of each signing device.

[0060] If the number of times the signature index has been used has reached the preset number, the signature index generation module 122 can generate a new signature index by updating the V(n) value. Then, the signature calculation and caching module 123 can use the new signature index to calculate a new supertree signature HT-Signature(n) and store it in the cache.

[0061] Next, the hash signature HB-Signature(n) that makes up this signature device is sent to the signature assembly module 113 of the main control device 11 as shown below.

[0062] HB-Signature(n)={R(n),PK(n),FTS-Signature(n),HT-Signature(n)}

[0063] In step 26, the multi-signature assembly module 113 of the main control device 11 assembles the hash signatures calculated by each signature device 12 and the message M into a multi-hash signature MH-Signature of the message M according to the order of the signature path.

[0064] MH-Signature={M,[HB-Signature(0),HB-Signature(1),...,HB-Signature(N)]}

[0065] Figure 4 is an architectural diagram of the seal verification device 40 of the present invention. The seal verification device 40 may be an independent computer or server, used to verify the multiple hash signature MH-Signature of message M, and includes a signature decomposition module 41, a seal plaintext generation module 42, a seal index generation module 43, a signature verification module 44, and a verification result merging module 45, which are connected in the following order.

[0066] Each module 41 to 45 in Figure 4 can be software, hardware or firmware; if it is hardware, it can be a processing unit, processing core or processor with data processing and computing capabilities; if it is software or firmware, it can include instructions that can be executed by the processing unit, processing core or processor, and can be installed on the same hardware device or distributed on different multiple hardware devices.

[0067] Figure 5 is a flowchart of the multi-signature verification method executed by the signature verification device 40. This multi-signature verification method can be used to verify the multi-hash signature MH-Signature of message M. The flowchart in Figure 5 is explained below.

[0068] In step 51, the signature disassembly module 41 disassembles the multiple hash signature MH-Signature to extract the message M, and extracts the hash signature array [HB-Signature(0),HB-Signature(1),…,HB-Signature(N)] of each signature device. In this array, the hash signatures of each signature device are stored in the order of the signature devices in the signature path.

[0069] In step 52, the verification plaintext generation module 42 generates the verification plaintext Cn for each signing device. For each signing device n, the verification plaintext Cn is the same as the signing plaintext Cn generated by the signing plaintext generation module 121.

[0070] As described above, the verification plaintext Cn of the signing device 0 is M.

[0071] The plaintext for verification of the remaining signing devices n is Cn=M∥PK(n-1). The hash signature HB-Signature(n) of the signing device n is ={R(n),PK(n),FTS-Signature(n),HT-Signature(n)}. Therefore, the public key PK(n-1) of the previous signing device on the signing path can be obtained from the hash signature HB-Signature(n-1) of the (n-1)th signing device in the hash signature array.

[0072] In step 53, the verification index generation module 43 generates the verification index for each signing device. For each signing device n, its verification index is the same as the signing index generated by the signing index generation module 122.

[0073] If the signing device n is in accelerated mode, the verification index is calculated using the pseudo-random random number R(n) of the signing device n and the public key PK(n), as shown below.

[0074] {Leaf-Index(layer(0)),Tree-Index(layer(0))}=GenIndexInit(R(n),PK(n)), where the pseudo-random number R(n) and the public key PK(n) can be extracted from the hash signature HB-Signature(n) of the signature device n.

[0075] If the signing device n does not execute the accelerated mode, the verification index is calculated using the pseudo-random random number R(n) of the signing device n and the verification plaintext Cn, as shown below.

[0076] {Leaf-Index(layer(0)),Tree-Index(layer(0))}=GenIndexInit(R(n),Cn)

[0077] In step 54, the signature verification module 44 verifies the hash signature HB-Signature(n) of each signature device. This verification operation is divided into two main steps: first, verifying the FTS element signature FTS-Signature(n) of each signature device; and second, verifying the hypertree signature HT-Signature(n) of each signature device.

[0078] The verification of the FTS element signature FTS-Signature(n) is to use the previously generated signature plaintext Cn and signature index, as well as the FTS element signature FTS-Signature(n) and public key PK(n) in the hash signature HB-Signature(n) as parameters to verify the FTS element signature FTS-Signature(n). The verification result will obtain the public key PK(FTS) of the FTS element, as shown below.

[0079] PK(FTS)=FTS-Verify(Cn,Leaf-Index(layer(0)),FTS-Signature(n),PK(n))

[0080] Next, the public key PK(FTS) of the FTS element is used as plaintext, along with the verification index and the public key PK(n) of the signing device n, to verify the hypertree signature HT-Signature(n), as shown below. If the root node of the calculated hypertree matches the public key PK(n), the verification is successful.

[0081] Verify-Result=HT-Verify(PK(FTS),Leaf-Index(layer(0)),Tree-Index(layer(0)),HT-Signature(n),PK(n))

[0082] Verify-Result is a Boolean value that indicates whether the verification result of the hypertree signature HT-Signature(n) is successful or unsuccessful.

[0083] In step 55, the verification result merging module 45 performs a Boolean AND operation on the verification results Verify-Result of all signing devices to obtain a merged overall verification result Verify-All-Result, as shown below.

[0084] Verify-All-Result=Verify-Result(0) & Verify-Result(1) & Verify-Result(2) &...& Verify-Result(N)

[0085] As can be seen from the above formula, if the verification result of any signing device fails (false), the overall verification result after merging will also fail. The overall verification result after merging will only be successful if the verification result of each signing device is successful (true). If the overall verification result fails, it indicates that the content of message M is incorrect or that the signature of at least one signing device is incorrect, and it should not be read. If the overall verification result is successful, it indicates that the content of message M and the signatures of all signing devices are correct, and its content can be read for subsequent processing.

[0086] Then, the verification result merging module 45 combines the signature verification results of each signature device into an array, and combines it with the merged overall verification result to form a multi-signature verification result format, as shown below.

[0087] {Verify-All-Result,[Verify-Result(0),Verify-Result(1),Verify-Result(2),...,Verify-Result(N)]}

[0088] In one embodiment, the seal verification device 40 may be incorporated into the post-quantum multi-signature system 10, and the multi-signature verification method executed by the seal verification device 40 may be incorporated into the post-quantum multi-signature method executed by the post-quantum multi-signature system 10.

[0089] Furthermore, the present invention discloses a computer-readable medium applied in a computing device or computer having a processor (e.g., CPU, GPU, etc.) and / or memory, and storing instructions, which can be executed by the computing device or computer through the processor and / or memory to perform the above-described methods and steps when the computer-readable medium is executed. In one embodiment, the computer-readable medium is a non-transitory computer-readable storage medium.

[0090] Compared with existing signature technologies, the multi-signature technology of the present invention has the following main differences.

[0091] First, it has a signature acceleration mode, which can significantly shorten the signature processing time of a single signature device.

[0092] Second, it supports parallel signature calculation, and multiple signature devices participating in multi-signature operations can perform signature calculations simultaneously without waiting for other signature devices.

[0093] In summary, this invention provides a hash-based multisignature acceleration technology to solve the problem of slow hash-based signature algorithms. This invention supports parallel signing, enabling all signing devices participating in multisignature to execute signing operations in parallel without waiting for other nodes to complete their signing tasks. It also provides acceleration modes and caching mechanisms for some signing operations, achieving a multisignature acceleration technology with security resistant to quantum computer attacks and significantly improved signing performance.

[0094] The above embodiments are used to illustrate the principles and effects of the present invention, and are not intended to limit the present invention. Anyone skilled in the art can modify the above embodiments without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention should be as set forth in the following claims.

Claims

1. A post-quantum multi-signature method, comprising: A signature path is generated, wherein the signature path includes multiple signature devices; a signature request is generated for each of the signature devices based on a message; each signature device, in parallel processing, generates a signature plaintext based on its signature request, and then, based on the signature plaintext and multiple Merkle trees and multiple One-Time Signature (OTS) elements in the hash-based supertree of the signature device, and based on multiple Finite-Time Signature (FTS) elements connected to the supertree... The component manufactures a hash signature for the signing device, wherein the signing request of the first signing device in the signing path includes the message, the plaintext of the signature of the first signing device is the message, the signing requests of the remaining signing devices include the message and the public key of the previous signing device in the signing path, and the plaintext of the signature of the remaining signing devices is the message concatenated with the public key; and the component assembles the message and the plurality of hash signatures into a multi-hash signature for the message.

2. The quantum multi-signature method as described in claim 1 further includes instructing each signing device to perform the following steps: generating a pseudo-random number based on the private key of the signing device; generating a signature index of the signing device based on the pseudo-random number, wherein, The signature index specifies a leaf node of a Merkle tree at the lowest level of the supertree, and further specifies a unique path from that leaf node to the root node of the unique Merkle tree at the highest level of the supertree; and generates the hash signature of the signature device based on the signature plaintext, the corresponding leaf node among the plurality of FTS elements, and the OTS elements and Merkle trees traversed by the unique path in the supertree.

3. The quantum multi-signature method as described in claim 2 further includes instructing each signing device to perform the following steps: generating the pseudo-random number based on the public key and the private key of the signing device; and generating the signature index of the signing device based on the public key and the pseudo-random number.

4. The quantum multi-signature method as described in request item 3, wherein, The pseudo-random number is generated based on the public key, the private key, and a variable parameter, which varies according to the number of times the signature index is used.

5. The quantum multi-signature method as described in claim 2 further includes instructing each signing device to perform the following steps: generating a pseudo-random number based on the plaintext of the signature of the signing device and the private key; and generating the signature index of the signing device based on the pseudo-random number and the plaintext of the signature.

6. The quantum multisignature method as described in claim 2 further includes instructing each signing device to perform the following steps: inputting the plaintext of the signature of the signing device into the FTS element corresponding to the leaf node to obtain the FTS element signature of the signing device; and inputting the public key of the FTS element corresponding to the leaf node into the lowest-level complex OTS elements of the supertree connected to the leaf node to obtain the supertree signature of the signing device, wherein, The signature device's hash signature includes the FTS element signature and the hypertree signature.

7. The quantum multi-signature method as described in request item 6, wherein, The supertree signature includes the authentication path corresponding to the unique path in each Merkle tree through which the unique path passes in the supertree, and the supertree signature further includes the digital signature calculated by each OTS element through which the unique path passes in the supertree based on the signature calculation of the root node of the Merkle tree to which its input is connected.

8. The quantum multi-signature method as described in claim 6 further includes instructing each of the signature devices to perform the following steps: storing the supertree signature in a cache so that the supertree signature in the cache can be directly retrieved when the hash signature is produced next time.

9. A post-quantum multi-signature system, comprising: One main control device; And a plurality of signature devices, which form a signature path, wherein the master control device is used to generate a plurality of signature requests based on a message, the master control device is multiplexed to dispatch each signature request to one of the plurality of signature devices, each signature device is used to generate signature plaintext of the signature device according to the signature request of the signature device in a parallel processing manner, and then, based on the signature plaintext and the plurality of Merkle trees and plurality of one-time signature (OTS) elements in the hash-based supertree of the signature device, and according to the connection of the supertree The multiple finite-time signature (FTS) element is used to produce a hash signature of the signature device, wherein the signature request of the first signature device in the signature path includes the message, the signature plaintext of the first signature device is the message, the signature requests of the remaining signature devices include the message and the public key of the previous signature device in the signature path, and the signature plaintext of the remaining signature devices is the message concatenated with the public key, and the master device is multiplexed to assemble the message and the multiple hash signatures into a multi-hash signature of the message.

10. A computer-readable medium, applied in a computing device or computer, storing instructions for performing the quantum multi-signature method as described in any one of claims 1 to 8.

Images