A method for designing an efficient XMSS computing unit architecture supporting the SPHINCS+ protocol

Abstract

This invention discloses a high-efficiency XMSS computation unit architecture design method supporting the SPHINCS+ protocol, relating to the field of hardware acceleration technology, and solving the problem of slow hardware computation speed of traditional SPHINCS+ XMSS signatures. Firstly, at the algorithm level, the Merkle tree construction logic is optimized by adjusting the key pair selected during signing and reducing the number of nodes to be computed during signing, thereby reducing the overall overhead of tree construction. Secondly, in terms of hardware architecture, a parallel processing approach using multiple hash chains is adopted, optimizing the overall pipeline layout. Furthermore, an innovative method of alternating dual-key pair input is used, effectively reducing the overall clock cycles required for key pair generation and signature computation, significantly improving hardware utilization. Experimental results show that this design achieves speedups of 3.86 and 3.87 for key generation and signature computation, respectively, on an FPGA platform. This invention has promising application prospects in the field of hardware acceleration of post-quantum cryptography algorithms supporting the SPHINCS+ protocol.

Description

Technical Field

[0001] This invention relates to the field of hardware acceleration technology, and specifically to a method for designing an efficient XMSS computing unit architecture that supports the SPHINCS+ protocol. Background Technology

[0002] In 2016, the National Institute of Standards and Technology (NIST) initiated a comprehensive standardization process for post-quantum cryptography (PQC) algorithms to address the looming threat posed by quantum computing. In July 2022, NIST finalized four candidate algorithms in the PQC competition, including SPHINCS+. SPHINCS is a popular hash-based stateless digital signature scheme whose security relies entirely on cryptographic hash functions, rather than complex mathematical problems. Its enhanced version, SPHINCS+, was officially standardized by NIST in 2023, providing higher security guarantees and computational efficiency. SPHINCS+ is based on Merkel tree theory and, by integrating XMSS, enables the generation of multiple signatures using a single private key while maintaining statelessness. This scheme employs a hierarchical supertree structure, fundamentally preventing key reuse and thus achieving stateless security. This architecture significantly reduces key management complexity and system overhead compared to traditional stateful signature schemes. However, XMSS key pair generation and signature computation involve a large number of hash function calculations, which are extremely slow, necessitating further improvements in computational speed and speedup. Summary of the Invention

[0003] To address the issue of slow hardware computation speed in traditional SPHINCS+ XMSS signatures, this invention provides a method for designing an efficient XMSS computation unit architecture that supports the SPHINCS+ protocol, comprising:

[0004] S1. Configure the hash operation unit as a parallel multi-channel pipeline architecture containing 4 parallel hash calculation links to improve the computational efficiency of the pipeline;

[0005] S2. In the SPHINCS+ signature process, a dual-path task scheduling logic is used to alternately read two different sets of key pair data, and the calculation tasks of the two different sets of key pair data are cross-distributed to the four parallel hash calculation links, and the key pair calculation tasks after the link allocation are output.

[0006] S3. Based on the key pair calculation task allocated by the output link, during the calculation of the hash function, the calculation operation of the second key pair data is inserted during the pipeline calculation gap or storage access waiting period of the first key pair data, thereby reducing the overall calculation time and finally obtaining the parallel hash calculation result;

[0007] S4. Based on the parallel hash calculation result, generate a Merkle tree. During the generation process, the node optimization logic determines the unnecessary calculation nodes according to the index value of the current signature and skips the calculation of the unnecessary calculation nodes, and outputs the Merkle tree calculation result after the optimization of unnecessary nodes.

[0008] Furthermore, in S1, the four parallel hash calculation links are adapted to the chain function operation requirements for leaf node generation in the XMSS algorithm. The generation of a single leaf node requires 67 chain function operations to be completed through the four parallel hash calculation links, and a single complete chain function operation includes one PRF operation and 15 F operations. The calculations within the chain function have data dependencies, while the operations between the four parallel hash calculation links are independent of each other, and the synchronous operation of each link is achieved through the parallel architecture.

[0009] Furthermore, in S2, when the two different sets of key pair data are read alternately using the dual-path task scheduling logic, in order to adapt to the operation rhythm of the four parallel hash calculation links, dual SHA-512 hash kernels are set accordingly. The dual SHA-512 hash kernels are used to perform public key compression calculation and Merkle tree generation H calculation on the key pair calculation tasks allocated by the links, respectively, to solve the problem of task blocking caused by the difference between the 64 rounds of calculation cycle of SHA-256 and the 80 rounds of calculation cycle of SHA-512.

[0010] Furthermore, in S3, for the key pair calculation task after the link allocation, while inserting the second set of key pair data calculation operations during the pipeline calculation gap or storage access wait period for processing the first set of key pair data, the concatenated message blocks of the SHA-256 function and SHA-512 function in the hash function are pre-calculated respectively, so that the PRF, F, and PRF required for processing the key pair calculation task are processed. The four functions, H, and F, reduce the computation of message blocks by one per call. Specifically, to complete one XMSS key pair generation operation, the PRF function needs to be called 17,152 times and the F function needs to be called 257,280 times. Pre-computation significantly reduces the overall computational load of parallel hashing.

[0011] Furthermore, in S4, when the node optimization logic determines unnecessary computation nodes based on the current signature index value, if the index value is detected to be a positive even number or a positive odd number, the Merkle tree node update phase is entered and this phase is divided into five sub-loops. Each sub-loop allocates the node update interval according to the following rules:

[0012] When the index value is a positive even number, the first sub-loop is responsible for values ​​from 0 to... The second sub-loop is responsible for updating nodes within the index value range. to Update nodes within an index value range;

[0013] When the index value is a positive odd number, the third sub-loop is responsible for... to The fourth sub-loop is responsible for updating nodes within the index value range. to Update nodes within an index value range;

[0014] The fifth sub-loop has a maximum index value determined by the subtree height. The remaining nodes are updated by gradually decreasing the number of nodes until the number of nodes reaches zero. By using the above interval allocation method, the computation of unnecessary computation nodes is accurately skipped, thus shortening the computation time of the identity authentication path nodes based on the Merkle tree generation results.

[0015] The beneficial effects of this invention are as follows: This invention proposes an optimized Merkle tree construction algorithm, which can reduce the number of Merkle tree nodes that need to be calculated during the signature process, quickly calculate identity path nodes, and reduce tree construction overhead; This invention designs a WOTS+ leaf node accelerator with four-way hash chain parallelism and a Merkle tree accelerator with dual hash cores, and achieves a tight coupling design between the two through ping-pong switching, reducing waiting time and resource conflicts, forming a stable end-to-end pipeline, and significantly improving parallelism; This invention proposes a hardware acceleration scheme adapted to the XMSS algorithm in SPHINCS+, which is evaluated on FPGA and ASIC platforms, and achieves speedup ratios of 3.86 and 3.87 for key generation and signature calculation, respectively, with good area efficiency. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the process of the present invention;

[0017] Figure 2 This is a schematic diagram of the XMSS tree structure;

[0018] Figure 3 This is a schematic diagram of the identity authentication path nodes;

[0019] Figure 4 for Schematic diagram of the operation message block;

[0020] Figure 5 This is a schematic diagram of a four-way parallel hardware architecture;

[0021] Figure 6 This is a schematic diagram of a dual-hash-core compression hardware architecture;

[0022] Figure 7 This is a schematic diagram of the production line;

[0023] Figure 8 A schematic diagram of the four functions used in the XMSS algorithm;

[0024] Figure 9 For pre-computed hardware architecture diagrams;

[0025] Figure 10 Diagram illustrating the traditional Merkle tree construction order;

[0026] Figure 11 A diagram illustrating the optimized Merkle tree construction order;

[0027] Figure 12 A diagram illustrating the overall architecture of key generation and signing;

[0028] Figure 13 Overall architecture diagram for signature verification;

[0029] Figure 14 This is the hardware architecture layout of XMSS. Detailed Implementation

[0030] The technical solution of the present invention will be further described below with reference to embodiments, but it is not limited thereto. Any modifications or equivalent substitutions to the technical solution of the present invention without departing from the spirit and scope of the technical solution of the present invention should be covered within the protection scope of the present invention. In the following embodiments, process equipment or devices not specifically specified are all conventional equipment or devices in the art. Unless specifically specified, the technical means used in the embodiments of the present invention are all conventional means well known to those skilled in the art.

[0031] Example 1: A method for designing an efficient XMSS computing unit architecture supporting the SPHINCS+ protocol, comprising:

[0032] S1. Configure the hash operation unit as a parallel multi-channel pipeline architecture containing 4 parallel hash calculation links to improve the computational efficiency of the pipeline;

[0033] S2. In the SPHINCS+ signature process, a dual-path task scheduling logic is used to alternately read two different sets of key pair data, and the calculation tasks of the two different sets of key pair data are cross-distributed to the four parallel hash calculation links, and the key pair calculation tasks after the link allocation are output.

[0034] S3. Based on the key pair calculation task allocated by the output link, during the calculation of the hash function, the calculation operation of the second key pair data is inserted during the pipeline calculation gap or storage access waiting period of the first key pair data, thereby reducing the overall calculation time and finally obtaining the parallel hash calculation result;

[0035] S4. Based on the parallel hash calculation result, generate a Merkle tree. During the generation process, the node optimization logic determines the unnecessary calculation nodes according to the index value of the current signature and skips the calculation of the unnecessary calculation nodes, and outputs the Merkle tree calculation result after the optimization of unnecessary nodes.

[0036] Specifically, the XMSS structure reference in SPHINCS+ Figure 2 As shown, it consists of a Winternitz One-Time Signature Plus (WOTS+) key pair and a Merkle tree structure. The WOTS+ private key... Divided into lengths of substring, see reference Figure 2 As shown in the red nodes, each red node corresponds to one substring, each The value of the substring is determined by the private key seed. and public key seed and the corresponding address Calculated using the PRF function, a variant of the hash function. Each The substring passes through consecutive Round-robin hash function operations (this process is called hash chaining) yield the corresponding public key. substring, see reference Figure 2 As shown in the blue node. To obtain the complete WOTS+ public key, you need to... Performing a hash operation on each substring is called public-key compression. The compressed result is the final WOTS + public key, which is the reference. Figure 2 The green node in the Merkle tree. Because this node is located at the bottom level of the Merkle tree, it is also called a leaf node. The leaf nodes are hashed in pairs sequentially to obtain the corresponding nodes above them. This process is repeated to obtain the nodes at the next higher level, ultimately leading to the top-level node, i.e., the reference node. Figure 2 The black node in the diagram is called the root node, and its value is the public key value of XMSS.

[0037] XMSS in SPHINCS+ consists of three important parameters , and Definition, where This is the height of the Merkle tree. Based on the binary tree structure of a Merkle tree, the total number of leaf nodes in the tree is... It is the maximum number of messages that can be signed. The Winderitz parameter determines the number of iterations required to calculate the WOTS+public key from the WOTS+private key. These are security parameters, representing the byte length of the signable message, as well as the lengths of the private key element, public key element, and signature element. The number of chain functions required to calculate each WOTS+ public key is determined by the following formula:

[0038]

[0039]

[0040]

[0041] This invention uses the SLH-DSA-SHA2-256s parameter set, and the relevant parameters under this parameter set are: .

[0042] XMSS extends the WOTS+ signature scheme to allow signing multiple messages, for messages with a height of [missing information]. The Merkle tree contains WOTS + public key, therefore can be used for signing. Message. The length of the XMSS signature is 1000. The XMSS signature consists of WOTS+signature and the corresponding authentication path node. When calculating the XMSS signature, a leaf node is first selected, with the leaf node index starting from... arrive Then, the message to be signed is processed, and the message is transformed into... A hexadecimal number, using Subtract these hexadecimal numbers in sequence (repeatedly) (times), obtained The results are then summed to obtain the message checksum. This checksum is represented in the same way as... Each hexadecimal number is concatenated with a checksum to obtain the processed message digest. When calculating the signature, each entry is... substring to The number of hash function iterations required for the substring is determined by the corresponding message digest, and a total of [number] iterations are needed. A string, this Each of the hexadecimal numbers corresponds to a number of iterations of a substring, and the result is obtained through iteration. A byte's message is WOTS + signature.

[0043] An authentication path node consists of the sibling nodes of each node on the path from the leaf node to the root node. (See reference) Figure 3 As shown, taking a Merkle tree of height 3 as an example, assuming the signature selects node K2 (the yellow node in the diagram), the path from this node to the root node is K2-n. 1,1 -n2,0 The corresponding identity authentication path node is K3, n 1,0 n 2,1 (Green nodes in the diagram). Except for the top layer, each layer has an authentication path node. For a height of... For Merkle trees, there are a total Each authentication path node is calculated and then concatenated with the WOTS+ signature to obtain the complete XMSS signature.

[0044] Dual SHA-512 core: A dual-hash-core compression hardware architecture where four H registers provide the initial hash values ​​needed for different computation stages of the two hash cores, selected by a two-to-one data selector. The K register provides fixed hash constant values ​​for the hash operation, and five W registers provide the message blocks needed for different computation stages of the two hash cores.

[0045] Furthermore, in S1, the four parallel hash calculation links are adapted to the chain function operation requirements for leaf node generation in the XMSS algorithm. The generation of a single leaf node requires 67 chain function operations to be completed through the four parallel hash calculation links, and a single complete chain function operation includes one PRF operation and 15 F operations. The calculations within the chain function have data dependencies, while the operations between the four parallel hash calculation links are independent of each other, and the synchronous operation of each link is achieved through the parallel architecture.

[0046] Specifically, after the chain function is calculated, it needs to go through... The final leaf nodes are obtained after SHA-512 computation, therefore the number of parallel rows needs to be adapted. Function operations, Function message block arrangement reference Figure 4 As shown, the first one is by The message block consisting of "0" has been omitted through pre-computation; only the remaining message blocks need to be considered. For The function, in addition to the pre-computed message block, needs to compute 18 more message blocks, each 128 bytes long. Using a four-way parallel computation chain function achieves a good match between the number of message blocks and the number of parallel chain functions. Although the length of the result from each four-way parallel computation meets the length of a message block, the first message block contains a 22-byte address. Therefore, the result of the fourth chain needs to be split, dividing the 32-byte result into the first 10 bytes and the last 22 bytes, forming two separate message blocks for subsequent computation. The first 10 bytes of the fourth chain's computation result are used directly in the current round of computation, while the last 22 bytes are reserved for the next round. Therefore, a 22-byte FIFO is needed to store this data, updating the 22-byte value in the FIFO after the next round of chain function computation is completed.

[0047] Four-way parallel hardware architecture reference Figure 5 As shown, the finite state machine (FSM) controls the input, start, and stop of four chain function modules. Each chain module consists of 16 serial F modules, corresponding to one round of PRF computation and 15 rounds of F computation in the chain function calculation. Within each chain function, when performing key pair generation, each chain function undergoes a complete 16-round iteration and only outputs the result of the 16th round as the input value for subsequent compression. When performing signature functionality, each chain function performs 16 complete iterations and, after each iteration, performs a judgment, outputting the required intermediate value as the signature value based on the corresponding value of the information to be signed. When performing signature verification, each chain function only needs to output the required intermediate value as the pki, without needing to iterate through all 16 rounds. The FSM_Chain controls the iteration of the 16 serial F modules. Although this serial design increases the overall area significantly, it greatly improves computational efficiency by implementing a pipeline effect. After the first 16 rounds of iteration, four new sets of computation results can be output after each iteration. The F module consists internally of an SHA-256 hash kernel and a corresponding state machine FSM_F, with padding being the filling parameter used during hash operations.

[0048] Furthermore, in S2, when the two different sets of key pair data are read alternately using the dual-path task scheduling logic, in order to adapt to the operation rhythm of the four parallel hash calculation links, dual SHA-512 hash kernels are set accordingly. The dual SHA-512 hash kernels are used to perform public key compression calculation and Merkle tree generation H calculation on the key pair calculation tasks allocated by the links, respectively, to solve the problem of task blocking caused by the difference between the 64 rounds of calculation cycle of SHA-256 and the 80 rounds of calculation cycle of SHA-512.

[0049] Specifically, the hardware structure reference for dual-hash-core compressed key pairs is as follows: Figure 6 The four H registers provide the initial hash values ​​needed for different computation stages of the two hash cores, selected by a two-to-one data selector. The K register provides a fixed hash constant value for the hash operation, and the five W registers provide the message blocks needed for different computation stages of the two hash cores. To fully utilize the two hash cores, minimize idle time, and improve hardware utilization, an alternating key pair input method is used to minimize the impact of the different operation cycles of the two hash functions. For specific key pair input and pipeline details, please refer to [reference needed]. Figure 7 The computation mode of the two hash kernels is divided into The four-way parallel chain function structure first calculates chain 0 to chain 3 of the first key pair, then calculates chain 0 to chain 3 of the second key pair. After the first set of chain function values ​​is calculated, the left SHA-512 core performs compression. After one SHA-256 operation cycle, the second set of chain function values ​​is calculated. At this time, the left core has not yet completed compression, so the value is handed over to the right SHA-512 core for compression. Since the two sets of key pairs are input alternately, the left core will always compress key pairs with even indices, and the right core will always compress key pairs with odd indices. For the same SHA-512 core, there are idle cycles between the computation of two message blocks. This is due to the difference in the operation cycles of SHA-256 and SHA-512 functions. These idle cycles are used to calculate the last message block (padding block) of the key pair compression operation. Each padding block requires two idle cycles to complete. When both the left and right cores complete a full padding block operation, the calculation of the two leaf nodes is finished. At this point, each core uses an idle cycle to perform the H function operation, calculating the internal nodes of the Merkle tree. After the right core completes the Tℓ operation of the last leaf node, the hash core enters the Ending state. In this state, the final padding operation no longer uses an idle cycle but directly performs a full round of computation. After this, the right core performs the final eight H operations alone to calculate the root node value. When performing signature verification, only the value of one leaf node needs to be calculated. There is no need for alternating input; the right core directly performs continuous Tℓ operations on all message blocks of the specified key pair, with the calculation process identical to that of the last leaf node. This pipelined design interweaves the compression calculation of the last message block and the calculation of the internal nodes of the Merkle tree within the idle cycles of the Tℓ function calculation, fully utilizing the gaps caused by the different operation cycles of the two different hash functions, reducing overall computation time, and improving hardware utilization.

[0050] Furthermore, in S3, for the key pair calculation task after the link allocation, while inserting the second set of key pair data calculation operations during the pipeline calculation gap or storage access wait period for processing the first set of key pair data, the concatenated message blocks of the SHA-256 function and SHA-512 function in the hash function are pre-calculated respectively, so that the PRF, F, and PRF required for processing the key pair calculation task are processed. The four functions, H, and F, reduce the computation of message blocks by one per call. Specifically, to complete one XMSS key pair generation operation, the PRF function needs to be called 17,152 times and the F function needs to be called 257,280 times. Pre-computation significantly reduces the overall computational load of parallel hashing.

[0051] Specifically, the principle of hash kernel precomputation is to generate a lookup table during initial computation, thereby avoiding repeated computations in subsequent processes. For the XMSS algorithm, which requires numerous calls to the SHA2 function, precomputation can significantly accelerate computation. (Reference) Figure 8 Four functions used in XMSS are given, based on SHA-256 and SHA-512. The SHA-256 function has a single message block length of 512 bits, while the SHA-512 function has a single message block length of 1024 bits. The format of the first message block for all four functions is... The combination of "0" and "0". These are random values ​​generated before the calculation begins, and can be used as known quantities. The "0"s used for concatenation are also known quantities. According to the traditional calculation process, each time these four functions are called, the calculation must be repeated. Message blocks concatenated with "0"s severely impact overall computation speed. (Reference) Figure 9 The diagram shows the hardware structure of the pre-computation architecture. `pre` is a 1-bit pre-computation signal, and the two registers store the initial hash values ​​for the SHA-256 and SHA-512 functions, respectively. At the start of computation, `pre` is 0, indicating the start of pre-computation. The selector selects the initial hash values: H_256 = H_old_256, H_512 = H_old_512. These are then input into the corresponding hash kernels for a hash operation. The resulting pre-computation value is used again as input to update the values ​​in the registers. At this point, the `pre` signal jumps to 1, H_256 = H_new_256, H_512 = H_new_512, and the pre-computation is complete.

[0052] Furthermore, in S4, when the node optimization logic determines unnecessary computation nodes based on the current signature index value, if the index value is detected to be a positive even number or a positive odd number, the Merkle tree node update phase is entered and this phase is divided into five sub-loops. Each sub-loop allocates the node update interval according to the following rules:

[0053] When the index value is a positive even number, the first sub-loop is responsible for values ​​from 0 to... The second sub-loop is responsible for updating nodes within the index value range. to Update nodes within an index value range;

[0054] When the index value is a positive odd number, the third sub-loop is responsible for... to The fourth sub-loop is responsible for updating nodes within the index value range. to Update nodes within an index value range;

[0055] The fifth sub-loop has a maximum index value determined by the subtree height. The remaining nodes are updated by gradually decreasing the number of nodes until the number of nodes reaches zero. By using the above interval allocation method, the computation of unnecessary computation nodes is accurately skipped, thus shortening the computation time of the identity authentication path nodes based on the Merkle tree generation results.

[0056] For details, please refer to Figure 10 Taking a Merkle tree of height 4 as an example, the yellow nodes are the leaf nodes selected for signature calculation, and the red nodes are the corresponding authentication path nodes. The numbers in the nodes indicate the calculation order of each node during Merkle tree construction. In the traditional Merkle tree construction calculation order, the fourth authentication path node, AUTH3, requires three additional H operations after the last leaf node is calculated. For the green nodes in the diagram, these nodes are unnecessary in the authentication path node calculation process. If all nodes that are helpful in calculating authentication paths are moved to the leaf node calculation process, and nodes that are not helpful are moved to positions requiring extra calculation time and are not calculated, the time required to calculate authentication path nodes is shortened. (Reference) Figure 11 This demonstrates an optimized Merkle tree construction example. The computation order of all nodes in the diagram is indicated by the numbers within the nodes. First, the Merkle tree is constructed from right to left, starting with node AUTH3. After calculating all nodes to the right of the yellow node, the process returns to the leftmost position, resuming the Merkle tree construction from left to right. At this point, the yellow node is the last leaf node to be calculated. Once the WOTS+ signature of the yellow node is calculated, the complete XMSS signature is finished, and the nodes in the green section have not yet been calculated. If a leaf node with an even index is selected, the construction order is reversed: the Merkle tree is constructed from left to right until the node preceding the selected leaf node is calculated, then the Merkle tree is constructed from right to left, calculating all leaf nodes. In this case, the selected leaf node is the last node to be calculated.

[0057] Example 2: Reference Figures 12-14 This embodiment describes a high-efficiency XMSS computing unit architecture design that supports the SPHINCS+ protocol. It is used to implement the overall architecture of the high-efficiency XMSS computing unit architecture design that supports the SPHINCS+ protocol described in Embodiment 1. The architecture includes the overall architecture for key generation and signing (XMSS_signature), the overall architecture for signature verification (XMSS_verification), and the layout of the proposed XMSS hardware architecture.

[0058] refer to Figure 12 When performing the key generation function, the address module inside the WOTS+ module updates the initial input address to the new address needed for each module's calculation, in conjunction with the input... Calculate the private key ,in Each Calculated by the Chain module The corresponding round generation When performing the signature function, the 32-byte message to be signed is input into the MSG submodule to calculate the checksum, and the message to be signed is converted into a new signature using the checksum. hexadecimal numbers The data is input into the WOTS+ module and calculated based on the corresponding round. Byte's WOTS+ signature.

[0059] Specifically, the round value output by the WOTS+ module acts as a counter, whenever there is a... Once the calculation is complete, the `round` value will be updated accordingly. Internally, the Merkle module calculates the addresses needed for public key compression and Merkle tree construction based on the `round` value, following the pipeline described in Section 3.2.1. `Idx` is the key pair index selected during signing, input into both the WOTS+ module and the Merkle module as the basis for calculating the WOTS+ signature and authentication path nodes. The Merkle module calculates the corresponding authentication path node index based on the `idx` value and extracts the corresponding value. This process uses an optimized Merkle tree construction algorithm. After both parts are fully calculated, and ,in The final XMSS signature is obtained by assembling the components in sequence.

[0060] refer to Figure 13Furthermore, verifying an XMSS signature requires calculating a public key from the message and signature value, processing the message into a message digest in the same way as in the signature, then using the message digest and the WOTS chain to calculate the WOTS+ public key, which is the leaf node used for signing. The obtained leaf node is then hashed with the corresponding authentication path node value in the signature to iteratively calculate the value of the root node. This value is compared with the original root node value. If the comparison matches, the signature verification is successful; otherwise, the signature verification fails.

[0061] Specifically, during signature verification, the known signature SigXMSS is input. The signature is divided into the WOTS+ signature part and the identity authentication path node part, which are input into the WOTS+ module and the Merkle module respectively for calculation. The signature verification process only needs to calculate one leaf node, the index of which is determined by the input Idx. After the leaf node is calculated, the Merkle module uses the H function to calculate the final root node based on the value of the leaf node and the value of the known identity authentication path node. The root node is compared with the root node calculated by the key generation function. If they match, the signature verification is successful.

[0062] refer to Figure 14 The proposed XMSS hardware architecture layout further demonstrates that the digital back-end process is implemented using TSMC's 55nm standard cell library. The layout consists entirely of standard cells; the layout successfully passed the Design Rule Check (DRC) and Layout-to-Schematic (LVS) verification steps.

[0063] Specifically, interconnections are omitted in the diagram for easier observation of the cell layout. The final achieved highest operating frequency is 266MHz, with an equivalent gate count of approximately 1,208 kGates and a core area of ​​approximately 605 × 605 µm² (excluding I / O pins). The layout and routing have been optimized to minimize inter-channel crosstalk.

[0064] This invention specifically optimizes the node calculation of Merkle trees. It can accurately identify and skip unnecessary calculation nodes for Merkle trees of different heights. For example, for a Merkle tree with a height of 4, one unnecessary calculation node can be reduced per level. For a Merkle tree with a height of 8 implemented in this invention, the calculation of 7 unnecessary nodes can be saved, and the overall calculation time of h'-1 nodes can be saved (where h' is the height of the Merkle tree). The number of calculation nodes that can be saved under different parameter sets in the FIPS 205 standard is detailed in Table 1.

[0065] The design of this invention is implemented in hardware on the Xilinx Virtex-7 platform, with a main frequency of 40MHz, consuming 512,621 LUTs and 108,667 FFs. Based on this hardware implementation, generating a key pair for the XMSS algorithm in the SPHINCS+ protocol requires only 0.289 × 10^64 bytes. 6Each clock cycle requires 0.288 × 10⁻⁶ clock cycles for signature calculation. 6 The signature verification calculation only requires 0.004 × 10⁻¹⁰ clock cycles. 6 Table 2 shows a comparison of the calculation cycles for each stage of the final design of this invention, with and without pre-calculation, and without pre-calculation.

[0066] Because the XMSS algorithm in SPHINCS+ differs significantly from the standard XMSS algorithm, directly comparing computation cycles cannot objectively reflect performance. Therefore, this invention compares its performance with existing solutions across three dimensions: speedup ratio, ATP (area-time product), and the number of results generated per unit area per unit time (see Table 3) to minimize comparison bias caused by algorithm differences. ATP, the product of the LUT and the computation cycle, is a key indicator of computational efficiency; this invention sets its own ATP to 1 as a baseline. Speedup ratio is the ratio of computation time between the non-parallel architecture and the parallel architecture of this invention; the speedup ratios for key generation and signature computation of this invention are 3.86 and 3.87, respectively. The number of results generated per unit area per unit time directly reflects the overall efficiency of the hardware in terms of area and time; the number of key pairs and signatures generated under this metric is 2.70 (×10⁻⁶). -10 ) and 2.71 (×10 -10 It should be noted that the standard XMSS algorithm can quickly calculate the identity authentication path node through the BDS algorithm. However, the XMSS algorithm in SPHINCS+ implemented in this invention cannot use the BDS algorithm because the key pair needs to be randomly selected during signing. The difference in the core algorithm makes the ATP and the number of results generated per unit time per unit area not directly comparable. However, the speedup ratio is only related to the hardware architecture design, which can effectively eliminate the influence of algorithm differences. This invention achieves a signature calculation speedup ratio of 3.87 based on a four-way parallel architecture, which is significantly better than the seven-way parallel architecture scheme [8] (5.75), scheme [1] (2.46), and the schemes

[10] and [5] that do not use a parallel architecture. This fully demonstrates that the architecture design of this invention has a significant speedup effect on the signature calculation of the XMSS algorithm in the SPHINCS+ protocol.

[0067] Table 1

[0068]

[0069] Table 2

[0070]

[0071] Table 3

[0072]

[0073] Although the invention has been described with reference to a limited number of embodiments, those skilled in the art will understand from the foregoing description that other embodiments are conceivable within the scope of the invention described herein. Furthermore, it should be noted that the language used in this specification has been chosen primarily for readability and instructional purposes, and not for the purpose of interpreting or limiting the subject matter of the invention. Therefore, many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the appended claims. The disclosure of the invention is illustrative and not restrictive, and the scope of the invention is defined by the appended claims.

Claims

1. A method for designing an efficient XMSS computing unit architecture supporting the SPHINCS+ protocol, characterized in that, include: S1. Configure the hash operation unit as a parallel multi-channel pipeline architecture containing 4 parallel hash calculation links to improve the computational efficiency of the pipeline; S2. In the SPHINCS+ signature process, a dual-path task scheduling logic is used to alternately read two different sets of key pair data, and the calculation tasks of the two different sets of key pair data are cross-distributed to the four parallel hash calculation links, and the key pair calculation tasks after the link allocation are output. S3. Based on the key pair calculation task allocated by the output link, during the calculation of the hash function, the calculation operation of the second key pair data is inserted during the pipeline calculation gap or storage access waiting period of the first key pair data, thereby reducing the overall calculation time and finally obtaining the parallel hash calculation result; S4. Based on the parallel hash calculation result, generate a Merkle tree. During the generation process, the node optimization logic determines the unnecessary calculation nodes according to the index value of the current signature and skips the calculation of the unnecessary calculation nodes, and outputs the Merkle tree calculation result after the optimization of unnecessary nodes.

2. The method for designing an efficient XMSS computing unit architecture supporting the SPHINCS+ protocol according to claim 1, characterized in that, In S1, the four parallel hash calculation links are adapted to the chain function operation requirements for leaf node generation in the XMSS algorithm. The generation of a single leaf node requires 67 chain function operations to be completed through the four parallel hash calculation links, and a single complete chain function operation includes one PRF operation and 15 F operations. The calculations within the chain function have data dependencies, while the operations between the four parallel hash calculation links are independent of each other, and the synchronous operation of each link is achieved through the parallel architecture.

3. The method for designing an efficient XMSS computing unit architecture supporting the SPHINCS+ protocol according to claim 2, characterized in that, In S2, when the two sets of different key pairs are read alternately using the dual-path task scheduling logic, in order to adapt to the operation rhythm of the four parallel hash calculation links, dual SHA-512 hash kernels are set accordingly. The dual SHA-512 hash kernels are used to perform public key compression calculation and Merkle tree generation H calculation on the key pair calculation tasks allocated by the links, respectively, to solve the problem of task blocking caused by the difference between the 64 rounds of calculation cycle of SHA-256 and the 80 rounds of calculation cycle of SHA-512.

4. The method for designing an efficient XMSS computing unit architecture supporting the SPHINCS+ protocol according to claim 3, characterized in that, In S3, for the key pair calculation task after the link allocation, while inserting the second set of key pair data calculation operations during the pipeline calculation gap or storage access wait period for processing the first set of key pair data, pre-calculation processing is performed on the concatenated message blocks of the SHA-256 function and SHA-512 function in the hash function, so that the PRF, F, and other parameters required for processing the key pair calculation task are calculated. The four functions, H, and F, reduce the computation of message blocks by one per call. Specifically, to complete one XMSS key pair generation operation, the PRF function needs to be called 17,152 times and the F function needs to be called 257,280 times. Pre-computation significantly reduces the overall computational load of parallel hashing.

5. The method for designing an efficient XMSS computing unit architecture supporting the SPHINCS+ protocol according to claim 4, characterized in that, In S4, when the node optimization logic determines unnecessary computation nodes based on the current signature index value, if the index value is detected to be a positive even number or a positive odd number, the Merkle tree node update phase is entered and this phase is divided into five sub-loops. Each sub-loop allocates the node update interval according to the following rules: When the index value is a positive even number, the first sub-loop is responsible for values ​​from 0 to... The second sub-loop is responsible for updating nodes within the index value range. to Update nodes within an index value range; When the index value is a positive odd number, the third sub-loop is responsible for... to The fourth sub-loop is responsible for updating nodes within the index value range. to Update nodes within an index value range; The fifth sub-loop has a maximum index value determined by the subtree height. The remaining nodes are updated by gradually decreasing the number of nodes until the number of nodes reaches zero. By using the above interval allocation method, the computation of unnecessary computation nodes is accurately skipped, thus shortening the computation time of the identity authentication path nodes based on the Merkle tree generation results.

Images