Digital signature method and device, SPHINCS+ architecture, equipment and storage medium

Abstract

The application discloses a digital signature method, device, SPHINCS+ architecture, equipment and storage medium, relates to the field of information security technology, and the digital signature method comprises: abstract processing, FORS signature, bottom layer signature, WOTS+ signature and signature packaging, can execute FORS public key generation in parallel through multiple hash accelerators under the condition that the processor core is not copied, eliminates the software scheduling bottleneck; the authentication path of the current layer subtree is merged out through one hash accelerator, and the remaining hash accelerators are distributed to the next layer subtree to execute the public key leaf node generation task, and the interlayer idle gap is eliminated; the WOTS+ signature algorithm is adopted to significantly reduce the tail chain expected length and reduce the overall signature delay; a single processor core can efficiently coordinate multiple hash accelerators, realizes nearly linear signature acceleration at the cost of moderate increase in area, thereby meeting the low-latency signature demand of real-time sensitive scenes such as V2X and secure boot.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to digital signature methods, devices, SPHINCS+ architecture, equipment and storage media. Background Technology

[0002] SPHINCS+ is a hash-based digital signature scheme selected by NIST (National Institute of Standards and Technology) in the post-quantum cryptography standardization project. Its security relies solely on the collision resistance of the underlying hash function and it has good resistance to quantum computing attacks.

[0003] Existing hardware / software co-design schemes, such as the single-accelerator architecture SLotH, fail to fully exploit the inherent parallelism of SPHINCS+ at each level of the FORS, WOTS+, and XMSS supertrees. To meet the low-latency signature requirements of real-time sensitive scenarios such as V2X (vehicle-to-everything) and secure boot, it is possible to consider extending the single-accelerator architecture to a multi-accelerator architecture to pursue a higher speedup ratio. However, the extended multi-accelerator architecture often suffers from the following technical drawbacks.

[0004] FORS tree scheduling bottleneck: FORS (Random Subset Forest) consists of k independent binary Merkle trees (i.e., FORS trees) of height a. Each tree requires 2... a Second leaf node hash and 2 a-1 In the secondary internal node merging, each hash operation requires the processor core to trigger, poll, and configure related message blocks and addresses via the MMIO (Memory Mapped Input / Output) register. When multiple accelerators execute in parallel, the processor core must frequently perform software-level context switching between multiple accelerators, becoming a serialization bottleneck for the entire FORS computation. In practical applications, the software-scheduled dual-accelerator configuration only achieves a slight improvement over a single accelerator, far below the theoretically linear double speedup.

[0005] XMSS Supertree Interlayer Idleness: The XMSS supertree contains d layers of XMSS subtrees. When the signature of each XMSS subtree ends, multiple serial authentication path merging operations are required along the path from the signature leaf node to the root node. During this merging phase, only one of the P accelerators can participate in the computation, while the remaining P-1 accelerators are idle at each interlayer switching boundary, resulting in significant waste of hardware resources.

[0006] WOTS+ chain scheduling imbalance: WOTS+ signatures are generated based on L independent WOTS+ chains, each requiring 0 to w hash operations, where w is the Winderitz parameter. Under simple FIFO dynamic scheduling, the expected length of the WOTS+ chain at the tail of the scheduling queue is greater than the average chain length, leading to increased pause times between accelerators and affecting the overall signature latency.

[0007] The aforementioned drawbacks prevent simple multi-accelerator expansion schemes from achieving the theoretically linear speedup. Furthermore, if scheduling bottlenecks are circumvented by replicating complete processor cores, the area overhead increases linearly with the number of processor cores, making it unsuitable for deployments with strict area and power consumption constraints, such as HSMs (Hardware Security Modules). Summary of the Invention

[0008] In view of this, the purpose of this application is to provide a digital signature method, apparatus, SPHINCS+ architecture, device and storage medium that overcomes the aforementioned FORS tree scheduling bottleneck, XMSS supertree inter-layer idle defects and WOTS+ chain scheduling imbalance problems without copying processor cores, enabling a single processor core to efficiently coordinate multiple hash accelerators to accelerate signatures, thereby meeting the low-latency signature requirements of real-time sensitive scenarios such as V2X and secure boot.

[0009] To achieve the above objectives, this application provides the following technical solution:

[0010] Firstly, this application provides a digital signature method based on the SPHINCS+ architecture, comprising the following steps:

[0011] S1. Obtain a random mask, message digest, and private key seed. Based on the message digest, determine each FORS tree, each XMSS subtree, and the signature leaf node of each XMSS subtree. Based on the private key seed, derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree.

[0012] S2. Sign the message digest based on the FORS private key to obtain the FORS signature, and schedule multiple hash accelerators to perform layer-by-layer hash merging operations on the leaf nodes of each FORS tree in parallel to obtain the FORS public key;

[0013] S3. Based on the WOTS+ private key of the signature leaf node of the underlying XMSS subtree, perform the WOTS+ signature algorithm on the FORS public key to obtain the WOTS+ signature of the FORS public key;

[0014] S4. Schedule multiple hash accelerators to generate public key leaf nodes of the nth layer XMSS subtree in parallel;

[0015] S5. Schedule a hash accelerator to perform layer-by-layer hash merging operation on the leaf nodes of the nth layer XMSS subtree to obtain the root node and authentication path of the nth layer XMSS subtree. At the same time, schedule the remaining hash accelerators to pre-generate the public key leaf nodes of the (n+1)th layer XMSS subtree in parallel.

[0016] S6. Based on the WOTS+ private key of the signature leaf node of the (n+1)th layer XMSS subtree, perform the WOTS+ signature algorithm on the root node of the nth layer XMSS subtree to obtain the WOTS+ signature of the nth layer XMSS subtree.

[0017] S7. Take the bottom XMSS subtree as the 0th level XMSS subtree, and repeat steps S4-S6 layer by layer upward from the bottom XMSS subtree until the root node and authentication path of the top XMSS subtree are obtained in step S5.

[0018] S8. Generate an XMSS supertree signature based on the authentication path and WOTS+ signature of each XMSS subtree, and generate an SPHINCS+ signature based on the random mask, the FORS signature and the XMSS supertree signature.

[0019] Optionally, step S1 includes:

[0020] S11. Obtain the random mask, message digest, and private key seed; the message digest is calculated from the original message, public key seed, public key root value, and random mask using a hash function;

[0021] S12. Divide the message digest by bit to obtain the index of each FORS tree, the index of each XMSS subtree, and the index of the signature leaf node of each XMSS subtree, so as to determine the corresponding FORS tree, XMSS subtree, or signature leaf node of the XMSS subtree according to the index.

[0022] S13. Based on the private key seed, derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree through a pseudo-random function.

[0023] Optionally, step S2 includes:

[0024] S21. Based on the FORS private key, calculate the public key of the leaf node of each FORS tree, and construct the Merkle authentication path from the leaf node to the root node of each FORS tree to obtain the FORS signature.

[0025] S22. Schedule multiple hash accelerators and perform layer-by-layer hash merging operations on the leaf nodes of each FORS tree in parallel through the FORS tree FSM built into each hash accelerator to obtain the FORS public key.

[0026] Optionally, in steps S3 and S6, the WOTS+ signature algorithm includes:

[0027] Based on the WOTS+ private key, the corresponding FORS public key or the root node of the XMSS subtree is converted into a WOTS+ message number sequence; the WOTS+ message number sequence includes L w-ary WOTS+ chains;

[0028] Traverse the WOTS+ message number sequence, place WOTS+ chains smaller than the chain length threshold τ at the end of the WOTS+ message number sequence, and place WOTS+ chains not smaller than the chain length threshold τ at the beginning of the WOTS+ message number sequence, so as to reconstruct the WOTS+ message number sequence into a WOTS+ chain scheduling queue.

[0029] Traverse the WOTS+ chain scheduling queue, and use the chain function to perform hash iteration on the components of the WOTS+ private key corresponding to each WOTS+ chain in turn to generate the corresponding signature components;

[0030] The signature components are combined in the order of generation to obtain the WOTS+ signature corresponding to the FORS public key or the XMSS subtree.

[0031] Optionally, the formula for calculating the chain length threshold τ is:

[0032] τ = ceil(w × m / L);

[0033] In the formula, m represents the number of WOTS+ chains processed in parallel, and ceil(·) represents the floor function.

[0034] Optionally, in steps S4-S5, the task of generating the public key leaf nodes of the XMSS subtree is evenly distributed to each hash accelerator for parallel execution.

[0035] Secondly, this application provides a digital signature device based on the SPHINCS+ architecture, comprising:

[0036] The digest processing module is used to obtain a random mask, a message digest, and a private key seed; determine each FORS tree, each XMSS subtree, and the signature leaf node of each XMSS subtree based on the message digest; and derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree based on the private key seed.

[0037] The FORS signature module is used to sign the message digest based on the FORS private key to obtain the FORS signature, and to schedule multiple hash accelerators to perform the layer-by-layer hash merging operation of the leaf nodes of each FORS tree in parallel to obtain the FORS public key.

[0038] The public key signature module is used to perform the WOTS+ signature algorithm on the FORS public key based on the WOTS+ private key of the signature leaf node of the underlying XMSS subtree, so as to obtain the WOTS+ signature of the FORS public key.

[0039] The WOTS+ signature module is used to schedule multiple hash accelerators to generate the public key leaf nodes of the nth layer XMSS subtree in parallel; it schedules one hash accelerator to perform layer-by-layer hash merging operations on the leaf nodes of the nth layer XMSS subtree to obtain the root node and authentication path of the nth layer XMSS subtree, while scheduling the remaining hash accelerators to pre-generate the public key leaf nodes of the (n+1)th layer XMSS subtree in parallel; based on the WOTS+ private key of the signature leaf node of the (n+1)th layer XMSS subtree, it performs the WOTS+ signature algorithm on the root node of the nth layer XMSS subtree to obtain the WOTS+ signature of the nth layer XMSS subtree; it takes the bottom XMSS subtree as the 0th layer XMSS subtree, and repeats the above steps layer by layer upwards from the bottom XMSS subtree until the root node and authentication path of the top XMSS subtree are obtained in the above steps;

[0040] The signature encapsulation module is used to generate an XMSS supertree signature based on the authentication path of each XMSS subtree and the WOTS+ signature, and to generate an SPHINCS+ signature based on the random mask, the FORS signature and the XMSS supertree signature.

[0041] Thirdly, this application provides a SPHINCS+ architecture, applied to the digital signature method or digital signature apparatus as described above, comprising:

[0042] The hash acceleration engine includes multiple hash accelerators, each with an independently configured address generator, register set, and FORS tree (FSM).

[0043] The RISC-V core is communicatively connected to the hash acceleration engine and is used to send commands and parameters to the hash acceleration engine through the MIMO register.

[0044] The storage subsystem is communicatively connected to the hash acceleration engine and the RISC-V core, respectively, and is used to store FORS tree data, XMSS subtree data, and data generated by the hash acceleration engine and the RISC-V core.

[0045] The hash accelerator is configured as the Keccak accelerator.

[0046] Fourthly, this application provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the digital signature method as described above.

[0047] Fifthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the digital signature method described above.

[0048] The present application adopts the above technical solution, and its beneficial effects compared with the prior art are as follows:

[0049] This application enables the parallel execution of layer-by-layer hash merging operations on all leaf nodes of each FORS tree through multiple hash accelerators without replicating processor cores. This offloads software scheduling operations to hardware execution, eliminating the MIMO bottleneck of software scheduling and optimizing acceleration. Leveraging the property that the signature leaf node index of the XMSS subtree is derived from the message digest, a hash accelerator merges the authentication path of the current layer's XMSS subtree, while the remaining hash accelerators are allocated to the next layer's XMSS subtree to perform public key leaf node generation tasks. This eliminates inter-layer idle gaps in the XMSS supertree and reduces hardware resource waste. When generating WOTS+ signatures, a WOTS+ signature algorithm based on long-chain priority scheduling and short-chain last scheduling is adopted, significantly reducing the expected length of the tail WOTS+ chain in the WOTS+ chain scheduling queue and lowering the overall signature latency. A single processor core can thus efficiently coordinate multiple hash accelerators, achieving near-linear signature acceleration at the cost of a moderate increase in area, thereby meeting the low-latency signature requirements of real-time sensitive scenarios such as V2X and secure boot. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0051] Figure 1 This is a flowchart of a digital signature method provided in an embodiment of this application.

[0052] Figure 2 This is a schematic diagram of a hierarchical parallel scheduling method for XMSS supertrees provided in an embodiment of this application.

[0053] Figure 3 This is a schematic diagram of a digital signature method provided in an embodiment of this application.

[0054] Figure 4 This application provides a state transition diagram for a FORS tree FSM.

[0055] Figure 5 A comparison chart of experimental results for the number of FORS signature cycles provided in the embodiments of this application.

[0056] Figure 6 A comparison diagram of the WOTS+ signature algorithm provided in the embodiments of this application before and after WOTS+ chain scheduling.

[0057] Figure 7This is a structural diagram of a digital signature device provided in an embodiment of this application.

[0058] Figure 8 This is a schematic diagram of a SPHINCS+ architecture provided for an embodiment of this application.

[0059] Figure 9 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0060] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0061] See Figure 1 This application discloses a digital signature method based on the SPHINCS+ architecture, comprising the following steps:

[0062] S1. Obtain the random mask, message digest, and private key seed. Based on the message digest, determine each FORS tree, each XMSS subtree, and the signature leaf node of each XMSS subtree. Based on the private key seed, derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree.

[0063] S2. Sign the message digest based on the FORS private key to obtain the FORS signature, and schedule multiple hash accelerators to perform the layer-by-layer hash merging operation of the leaf nodes of each FORS tree in parallel to obtain the FORS public key;

[0064] S3. Based on the WOTS+ private key of the signature leaf node of the underlying XMSS subtree, perform the WOTS+ signature algorithm on the FORS public key to obtain the WOTS+ signature of the FORS public key;

[0065] S4. Schedule multiple hash accelerators to generate public key leaf nodes of the nth layer XMSS subtree in parallel;

[0066] S5. Schedule a hash accelerator to perform layer-by-layer hash merging operation on the leaf nodes of the nth layer XMSS subtree to obtain the root node and authentication path of the nth layer XMSS subtree. At the same time, schedule the remaining hash accelerators to pre-generate the public key leaf nodes of the (n+1)th layer XMSS subtree in parallel.

[0067] S6. Based on the WOTS+ private key of the signature leaf node of the (n+1)th layer XMSS subtree, perform the WOTS+ signature algorithm on the root node of the nth layer XMSS subtree to obtain the WOTS+ signature of the nth layer XMSS subtree.

[0068] S7. Take the bottom XMSS subtree as the 0th level XMSS subtree, and repeat steps S4-S6 upwards layer by layer from the bottom XMSS subtree until the root node and authentication path of the top XMSS subtree are obtained in step S5.

[0069] S8. Generate an XMSS supertree signature based on the authentication path and WOTS+ signature of each XMSS subtree, and generate an SPHINCS+ signature based on the random mask, FORS signature and XMSS supertree signature.

[0070] Figure 2 This is a schematic diagram of a hierarchical parallel scheduling method for XMSS supertrees provided in an embodiment of this application.

[0071] See Figure 2 Regarding the switching of processing flow between XMSS subtrees, it is understandable that after the root node of the nth level XMSS subtree is reconstructed, the hash accelerator that originally performed the layer-by-layer hash merging operation of the leaf nodes of the nth level XMSS subtree is added to the leaf node generation pool of the (n+1)th level XMSS subtree. At this time, all hash accelerators execute the public key leaf node generation task of the (n+1)th level XMSS subtree in parallel.

[0072] Based on the above technical solution, this embodiment uses multiple hash accelerators to perform layer-by-layer hash merging operations on all leaf nodes of each FORS tree in parallel, thus sinking the software scheduling operation to hardware execution, eliminating the MIMO bottleneck of software scheduling, and optimizing the acceleration effect. Taking advantage of the property that the signature leaf node index of the XMSS subtree is derived from the message digest, the authentication path of the current layer XMSS subtree is merged through a hash accelerator, while the remaining hash accelerators are allocated to the next layer XMSS subtree to perform the public key leaf node generation task, eliminating the inter-layer idle gaps of the XMSS supertree and reducing the waste of hardware resources.

[0073] In some embodiments, step S1 specifically includes:

[0074] S11. Obtain the random mask, message digest, and private key seed; the message digest is calculated from the original message, public key seed, public key root value, and random mask using a hash function.

[0075] S12. Divide the message digest by bit to obtain the index of each FORS tree, the index of each XMSS subtree, and the index of the signature leaf node of each XMSS subtree, so as to determine the corresponding FORS tree, XMSS subtree, or signature leaf node of the XMSS subtree based on the index.

[0076] S13. Based on the private key seed, derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree through a pseudo-random function.

[0077] Figure 3 This diagram illustrates a digital signature method provided in an embodiment of this application. The diagram shows the construction process of message digest, FORS tree, and XMSS supertree in the SPHINCS+-based digital signature method.

[0078] See Figure 3 , digest represents a message summary, H msg Let R represent the hash function, R represent the random mask, pk.seed represent the public key seed, pk.root represent the public key root (corresponding to the root node of the top-level XMSS subtree), and M represent the original message. After dividing the message digest, the first k bits (0, 1, ..., k-1) are used as indices for each FORS tree to determine k FORS trees; idx_tree and idx_leaf are the indices of the XMSS subtree and the signature leaf node of the XMSS subtree, respectively, to determine the XMSS subtree and the signature leaf node of the XMSS subtree, respectively.

[0079] A pseudo-random function (PRF) can be constructed based on the HKDF function to expand from the private key seed to generate multiple private key components, forming the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree.

[0080] Through the above technical solution, the index of the FORS tree, the index of the XMSS subtree, and the index of the signature leaf node of the XMSS subtree are all deduced deterministically from the message digest, and are independent of the root of the XMSS subtree. The signature leaf node index of the (n+1)th layer XMSS subtree is known before the root node of the nth layer XMSS subtree is calculated. Therefore, the public key leaf node generation task of the (n+1)th layer XMSS subtree can be started in advance during the reconstruction of the root node of the nth layer XMSS subtree, so as to realize the hierarchical scheduling mechanism of XMSS supertree without inter-layer idle gaps.

[0081] In some embodiments, step S2 specifically includes:

[0082] S21. Based on the FORS private key, calculate the public key of the leaf node of each FORS tree, and construct the Merkle authentication path from the leaf node to the root node of each FORS tree to obtain the FORS signature.

[0083] S22. Schedule multiple hash accelerators and perform layer-by-layer hash merging operations on the leaf nodes of each FORS tree in parallel through the FORS tree FSM built into each hash accelerator to obtain the FORS public key.

[0084] See Figure 3 ADRS represents the context address, FORS_roots represents the list of root nodes of k FORS trees, and PK... FORSThis represents the FORS public key. It is understandable that the primitive T... k (pk.seed, ADRS, FORS_roots) securely compresses a FORS forest structure consisting of k FORS trees into a fixed-length FORS public key by hashing the public key seed, context address, and a list of root nodes of k FORS trees, thus ensuring the integrity and security of the SPHINCS+ scheme.

[0085] Figure 4 This application provides a FORS tree FSM state transition diagram, which illustrates the switching and determination process of the FORS tree FSM between various states.

[0086] See Figure 4 The state sequence of the FORS tree FSM is defined as: F_IDLE→F_SKGEN→F_NODE_INIT→F_PREP_LEAF→F_WAIT_LEAF→F_CHECK→F_MERGE→F_NEXT→F_IDLE; During the layer-by-layer hash merge operation of the leaf nodes of the FORS tree, the functional definitions of each state are as follows:

[0087] F_IDLE: Waiting for software to trigger;

[0088] F_SKGEN: Derive the key corresponding to the current leaf node based on the private key seed;

[0089] F_NODE_INIT: Initializes the Merkle tree node stack;

[0090] F_PREP_LEAF: Prepare the hash accelerator input for the next leaf node;

[0091] F_WAIT_LEAF: Waiting for the hash accelerator to complete the leaf node hash operation;

[0092] F_MERGE: Determines whether the current node can be merged as a sibling node with the top element of the stack;

[0093] F_MERGE: Performs a hash accelerator permutation operation to merge sibling nodes;

[0094] F_NEXT: Incrementing leaf node index or issuing an interrupt command when the entire FORS tree is complete.

[0095] The software uses MIMO to write a trigger signal (including parameters such as the FORS tree index determined based on message digest and context address, the index of the FORS tree leaf node, the private key seed address, and the target buffer address). The FORS tree FSM can then autonomously complete the 2x2 operation of a single FORS tree of height 'a'. a Second leaf node hash and 2a-1 The internal node merge operation is only notified to the processor core via an interrupt instruction when the entire FORS tree is completed, so as to drive the processor core to exit the single hash operation of the FORS tree.

[0096] Based on the above technical solution, this embodiment configures an independent FORS tree FSM for each hash accelerator, sinking the entire FORS tree processing flow to the hardware layer. This allows all leaf node hashing and node merging calculations of each FORS tree to be completed autonomously in the hardware, with the processor core only participating in initial triggering and completion interrupts. Thus, FORS tree-level parallelism is achieved under the multi-accelerator SPHINCS+ architecture, eliminating the need for software-managed synchronization or context switching and removing the serial bottleneck caused by MIMO software scheduling in FORS.

[0097] Figure 5 This is a comparison chart of experimental results for the number of FORS signature cycles under different accelerator configurations provided in this application embodiment. The chart shows the number of FORS signature cycles corresponding to the single accelerator scheme based on SLotH (blue bars), the software-scheduled dual accelerator scheme (yellow bars), and the dual accelerator scheme in this embodiment (purple bars).

[0098] See Figure 5 Experimental results show that, compared with the single-accelerator scheme, the dual-accelerator scheme in this embodiment achieves a periodic reduction of nearly an order of magnitude in FORS processing time, and far exceeds the dual-accelerator scheme of software scheduling.

[0099] In some embodiments, the WOTS+ signature algorithm specifically includes the following in steps S3 and S6:

[0100] Based on the WOTS+ private key, the corresponding FORS public key or the root node of the XMSS subtree is converted into a WOTS+ message number sequence; the WOTS+ message number sequence includes L WOTS+ chains in base w;

[0101] Traverse the WOTS+ message number sequence, place WOTS+ chains smaller than the chain length threshold τ at the end of the WOTS+ message number sequence, and place WOTS+ chains not smaller than the chain length threshold τ at the beginning of the WOTS+ message number sequence, so as to reconstruct the WOTS+ message number sequence into a WOTS+ chain scheduling queue.

[0102] Traverse the WOTS+ chain scheduling queue and use the chain function to hash the components of the WOTS+ private key corresponding to each WOTS+ chain in turn to generate the corresponding signature components.

[0103] The signature components are combined in the order of generation to obtain the WOTS+ signature corresponding to the FORS public key or the XMSS subtree.

[0104] To address the tail-end pause problem caused by uneven chain lengths in WOTS+, the above embodiments propose a WOTS+ chain scheduling algorithm based on end-padding. To facilitate understanding of the algorithm's implementation by those skilled in the art, the following pseudocode is provided:

[0105] Input: WOTS + message number sequence {M i}, i=0,1,...,L-1; chain length threshold τ;

[0106] Initialize head←0, tail←L-1;

[0107] for i=0 to L-1 do:

[0108] if M i <τ then: indices[tail]←i; tail←tail-1; (short chain placed at the tail of the scheduling queue)

[0109] else: indices[tail] ← i; head ← head + 1; (sets the head of the long-chain scheduling queue)

[0110] Output: the scheduling queue indices[0, 1, ..., L-1].

[0111] When generating signature components, the hash accelerator always takes tasks from the head of the scheduling queue for execution, scheduling the long chain at the head first and then the short chain at the tail.

[0112] The above technical solution divides the L WOTS+ chains into two categories, long chains and short chains, according to the number of iterations derived from their message digests. This allows the longest chain to be scheduled first and the shortest chain to be scheduled last, thereby significantly reducing the expected length of the WOTS+ chains at the tail of the scheduling queue.

[0113] Preferably, the formula for calculating the chain length threshold τ is:

[0114] τ = ceil(w × m / L);

[0115] In the formula, m represents the number of WOTS+ chains processed in parallel, and ceil(·) represents the floor function.

[0116] The following explains the selection criteria for the chain length threshold τ under the condition w=16. m represents the number of WOTS+ chains processed in parallel, i.e., the number of WOTS+ chains that the hash accelerator can process simultaneously. The WOTS+ signature algorithm needs to ensure that the expected number of short chains E=L·τ / w≥m, so that the hash accelerator can fill the left and right parallel slots with enough short chains during the tail processing stage of the scheduling queue, thus avoiding long chains dragging down the overall WOTS+ signature completion time. Considering the most stringent configuration m=8 and L=35, we derive τ≥16×8 / 35≈3.657. Therefore, we take the chain length threshold τ=4 as the minimum feasible integer threshold to provide the tightest upper bound for the tail length. In implementation, if the actual number of short chains is less than m, the shortest existing WOTS+ chains can be used to fill the end of the scheduling queue.

[0117] Actual measurements show that when m=8 and τ=4, the expected length of the tail chain is reduced from approximately 13.69 steps under simple FIFO scheduling to approximately 2.90 steps after executing the WOTS+ chain scheduling algorithm, reliably solving the tail pause problem caused by uneven chain length in WOTS+.

[0118] Figure 6 This diagram illustrates a comparison of the WOTS+ signature algorithm provided in this application before and after WOTS+ chain scheduling. It shows the WOTS+ chain scheduling queue processed in parallel by four hash accelerators (acc0, acc1, acc2, and acc3) when m=4. Part (a) represents the situation before executing the WOTS+ chain scheduling algorithm, and part (b) represents the situation after executing the WOTS+ chain scheduling algorithm. When w=16, the bit addresses of each WOTS+ chain are 0, 1, ..., 15, with address 15 represented by pk in the diagram.

[0119] See Figure 6 Before WOTS+ chain scheduling, as shown in part (a), the tail chain addresses processed in parallel by the hash accelerators are 2-14. After acc0 finishes processing tail chain 14 and acc3 finishes processing tail chain 13-14, they still need to wait for acc2 to process tail chain 5-14 and acc3 to process tail chain 2-14, resulting in excessively long tail pause times between hash accelerators. After WOTS+ chain scheduling, as shown in part (b), the tail chain addresses processed in parallel by the hash accelerators are 12-14, with a maximum address difference of no more than 2. The tail chain lengths of each WOTS+ chain scheduling queue are relatively balanced, thus significantly reducing the tail idle time between hash accelerators and lowering the overall signature latency.

[0120] In some embodiments, in order to fully utilize the chain-level parallelism of multiple hash accelerators in the WOTS+ signature generation stage to improve signature efficiency, in steps S4-S5, the public key leaf node generation task of the XMSS subtree is evenly distributed to each hash accelerator for parallel execution.

[0121] It should be noted that in the digital signature method disclosed in the embodiments of this application, the parts not specifically described, such as the layer-by-layer hash operation of the leaf nodes of the XMSS subtree, the hash iteration of the components of the WOTS+ private key corresponding to the WOTS+ chain through the chain function, the generation of the XMSS supertree signature based on the authentication path of each XMSS subtree and the WOTS+ signature, and the generation of the SPHINCS+ signature based on the random mask, FORS signature and XMSS supertree signature, are already relatively mature technologies in the field, and this specification will not explain them in detail.

[0122] See Figure 7 This application also discloses a digital signature device based on the SPHINCS+ architecture, comprising:

[0123] The digest processing module 701 is used to obtain a random mask, a message digest and a private key seed, determine each FORS tree, each XMSS subtree and the signature leaf node of each XMSS subtree based on the message digest, and derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree based on the private key seed.

[0124] FORS signature module 702 is used to sign message digests based on FORS private keys to obtain FORS signatures, and to schedule multiple hash accelerators to perform layer-by-layer hash merging operations on the leaf nodes of each FORS tree in parallel to obtain FORS public keys.

[0125] The public key signature module 703 is used to perform the WOTS+ signature algorithm on the FORS public key based on the WOTS+ private key of the signature leaf node of the underlying XMSS subtree to obtain the WOTS+ signature of the FORS public key.

[0126] The WOTS+ signature module 704 is used to schedule multiple hash accelerators to generate the public key leaf nodes of the nth layer XMSS subtree in parallel; schedule one hash accelerator to perform layer-by-layer hash merging operation on the leaf nodes of the nth layer XMSS subtree to obtain the root node and authentication path of the nth layer XMSS subtree, and simultaneously schedule the other hash accelerators to pre-generate the public key leaf nodes of the (n+1)th layer XMSS subtree in parallel; based on the WOTS+ private key of the signature leaf node of the (n+1)th layer XMSS subtree, perform the WOTS+ signature algorithm on the root node of the nth layer XMSS subtree to obtain the WOTS+ signature of the nth layer XMSS subtree; take the bottom XMSS subtree as the 0th layer XMSS subtree, and repeat the above steps layer by layer upward from the bottom XMSS subtree until the root node and authentication path of the top XMSS subtree are obtained in the above steps;

[0127] The signature encapsulation module 705 is used to generate an XMSS supertree signature based on the authentication path of each XMSS subtree and the WOTS+ signature, and to generate an SPHINCS+ signature based on the random mask, FORS signature and XMSS supertree signature.

[0128] It should be noted that the apparatus disclosed in the above embodiments is only illustrated by the division of the above functional modules when executing the digital signature method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus disclosed in the above embodiments and the digital signature method embodiments belong to the same concept, and the implementation process can be found in the method embodiments, which will not be repeated here.

[0129] See Figure 8 This application also discloses a SPHINCS+ architecture, applied to any of the digital signature methods or digital signature devices disclosed in the foregoing embodiments, including:

[0130] The hash acceleration engine includes multiple hash accelerators, each with an independently configured address generator, register set, and FORS tree (FSM).

[0131] The RISC-V core communicates with the hash acceleration engine and is used to send commands and parameters to the hash acceleration engine through the MIMO register;

[0132] The storage subsystem communicates with the hash acceleration engine and the RISC-V core respectively, and is used to store FORS tree data, XMSS subtree data, and data generated by the hash acceleration engine and the RISC-V core.

[0133] The hash accelerator is configured as the Keccak accelerator.

[0134] Through the above technical solution, this embodiment only replicates the lightweight Keccak accelerator, and the single RISC-V core and BRAM (Block Random Access Memory) are kept shared. Compared with the existing multi-core RISC-V solutions, it can significantly reduce the area overhead while achieving a similar or higher speedup ratio. It is more suitable for area-sensitive deployment forms such as HSM and embedded security coprocessors. Therefore, when applied to the digital signature method disclosed in any of the foregoing embodiments or the digital signature verification method extended based on the method, it can efficiently coordinate multiple hash accelerators and achieve near-linear signature acceleration or verification at the cost of a moderate increase in area, thereby meeting the low-latency signature requirements of real-time sensitive scenarios such as V2X and secure boot.

[0135] During implementation, the number P of hash accelerators can be flexibly configured between 1 and 8 based on the actual application scenario's trade-offs regarding latency, area, and power consumption. Actual testing shows that the hash acceleration engine achieves optimal performance when P=4. When P>4, the speedup increase slows significantly due to the distribution overhead of a single RISC-V core and the Amdahl bottleneck. Therefore, P=4 is the most cost-effective deployment point.

[0136] Furthermore, this embodiment has been verified to be effective on two FPGA platforms: Xilinx Zynq UltraScale+ XCZU3EG (250 MHz) and Artix-7XC7A100T (125 MHz). A single hash accelerator configured on Artix-7 achieves a speedup of 1.46-2.80 times compared to the SLotH architecture, proving that the architectural advantages of this embodiment can be migrated across FPGA series without platform-specific tuning. This embodiment covers six parameter sets for SLH-DSA-128 / 192 / 256, including fast and small, which can be flexibly selected according to the application scenario: the fast variant is suitable for low-latency signatures, and the small variant is suitable for signature size-sensitive scenarios.

[0137] In summary, this application can perform layer-by-layer hash merging operations on all leaf nodes of each FORS tree in parallel through multiple hash accelerators without replicating processor cores. This offloads software scheduling operations to hardware execution, eliminating the MIMO bottleneck of software scheduling and optimizing acceleration. Utilizing the property that the signature leaf node index of the XMSS subtree is derived from the message digest, a hash accelerator is used to merge the authentication path of the current layer's XMSS subtree. Simultaneously, the remaining hash accelerators are allocated to the next layer's XMSS subtree to perform public key leaf node generation tasks, eliminating inter-layer idle gaps in the XMSS supertree and reducing hardware resource waste. When generating WOTS+ signatures, a WOTS+ signature algorithm based on long-chain priority scheduling and short-chain last scheduling is adopted, significantly reducing the expected length of the tail WOTS+ chain in the WOTS+ chain scheduling queue and lowering the overall signature latency. A single processor core can thus efficiently coordinate multiple hash accelerators, achieving near-linear signature acceleration at the cost of a moderate increase in area, thereby meeting the low-latency signature requirements of real-time sensitive scenarios such as V2X and secure boot.

[0138] See Figure 9 This application also discloses an electronic device, including: at least one processor 91, at least one memory 92, a power supply 93, a communication interface 94, an input / output interface 95, and a communication bus 96. The memory 92 stores a computer program, and when the processor 91 executes the computer program, it implements the relevant steps in the digital signature method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 90 in this embodiment can specifically be an electronic computer.

[0139] In this embodiment, the power supply 93 is used to provide operating voltage for the various hardware devices on the electronic device 90; the communication interface 94 can create a data transmission channel between the electronic device 90 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 95 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0140] In addition, the memory 92, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon can include an operating system 921, computer programs 922, etc., and the storage method can be temporary storage or permanent storage.

[0141] The operating system 921 is used to manage and control the various hardware devices on the electronic device 90 and the computer program 922, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the digital signature method executed by the electronic device 90 as disclosed in any of the foregoing embodiments, the computer program 922 may further include a computer program capable of performing other specific tasks.

[0142] Furthermore, embodiments of this application also disclose a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned disclosed digital signature method. Specific steps of this method can be found in the corresponding content of the foregoing embodiments, and will not be repeated here.

[0143] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The apparatuses disclosed in the embodiments are described simply because they correspond to the methods disclosed in the embodiments; relevant parts can be found in the method section.

[0144] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0145] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0146] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0147] The above embodiments are only for illustrating the technical concept and features of this application. Their purpose is to enable those skilled in the art to understand the content of this application and implement it. They should not be used to limit the scope of protection of this application. All equivalent changes or modifications made in accordance with the spirit and essence of this application should be covered within the scope of protection of this application.

Claims

1. A digital signature method, based on the SPHINCS+ architecture, characterized in that, Includes the following steps: S1. Obtain a random mask, message digest, and private key seed. Based on the message digest, determine each FORS tree, each XMSS subtree, and the signature leaf node of each XMSS subtree. Based on the private key seed, derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree. S2. Sign the message digest based on the FORS private key to obtain the FORS signature, and schedule multiple hash accelerators to perform layer-by-layer hash merging operations on the leaf nodes of each FORS tree in parallel to obtain the FORS public key; S3. Based on the WOTS+ private key of the signature leaf node of the underlying XMSS subtree, perform the WOTS+ signature algorithm on the FORS public key to obtain the WOTS+ signature of the FORS public key; S4. Schedule multiple hash accelerators to generate public key leaf nodes of the nth layer XMSS subtree in parallel; S5. Schedule a hash accelerator to perform layer-by-layer hash merging operation on the leaf nodes of the nth layer XMSS subtree to obtain the root node and authentication path of the nth layer XMSS subtree. At the same time, schedule the remaining hash accelerators to pre-generate the public key leaf nodes of the (n+1)th layer XMSS subtree in parallel. S6. Based on the WOTS+ private key of the signature leaf node of the (n+1)th layer XMSS subtree, perform the WOTS+ signature algorithm on the root node of the nth layer XMSS subtree to obtain the WOTS+ signature of the nth layer XMSS subtree. S7. Take the bottom XMSS subtree as the 0th level XMSS subtree, and repeat steps S4-S6 layer by layer upward from the bottom XMSS subtree until the root node and authentication path of the top XMSS subtree are obtained in step S5. S8. Generate an XMSS supertree signature based on the authentication path and WOTS+ signature of each XMSS subtree, and generate an SPHINCS+ signature based on the random mask, the FORS signature and the XMSS supertree signature.

2. The digital signature method according to claim 1, characterized in that, Step S1 includes: S11. Obtain the random mask, message digest, and private key seed; the message digest is calculated from the original message, public key seed, public key root value, and random mask using a hash function; S12. Divide the message digest by bit to obtain the index of each FORS tree, the index of each XMSS subtree, and the index of the signature leaf node of each XMSS subtree, so as to determine the corresponding FORS tree, XMSS subtree, or signature leaf node of the XMSS subtree according to the index. S13. Based on the private key seed, derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree through a pseudo-random function.

3. The digital signature method according to claim 1, characterized in that, Step S2 includes: S21. Based on the FORS private key, calculate the public key of the leaf node of each FORS tree, and construct the Merkle authentication path from the leaf node to the root node of each FORS tree to obtain the FORS signature. S22. Schedule multiple hash accelerators and perform layer-by-layer hash merging operations on the leaf nodes of each FORS tree in parallel through the FORS tree FSM built into each hash accelerator to obtain the FORS public key.

4. The digital signature method according to claim 1, characterized in that, In steps S3 and S6, the WOTS+ signature algorithm includes: Based on the WOTS+ private key, the corresponding FORS public key or the root node of the XMSS subtree is converted into a WOTS+ message number sequence; the WOTS+ message number sequence includes L w-ary WOTS+ chains; Traverse the WOTS+ message number sequence, place WOTS+ chains smaller than the chain length threshold τ at the end of the WOTS+ message number sequence, and place WOTS+ chains not smaller than the chain length threshold τ at the beginning of the WOTS+ message number sequence, so as to reconstruct the WOTS+ message number sequence into a WOTS+ chain scheduling queue. Traverse the WOTS+ chain scheduling queue, and use the chain function to perform hash iteration on the components of the WOTS+ private key corresponding to each WOTS+ chain in turn to generate the corresponding signature components; The signature components are combined in the order of generation to obtain the WOTS+ signature corresponding to the FORS public key or the XMSS subtree.

5. The digital signature method according to claim 4, characterized in that, The formula for calculating the chain length threshold τ is as follows: τ = ceil(w × m / L); In the formula, m represents the number of WOTS+ chains processed in parallel, and ceil(·) represents the floor function.

6. The digital signature method according to claim 1, characterized in that, In steps S4-S5, the task of generating the public key leaf nodes of the XMSS subtree is evenly distributed to each hash accelerator for parallel execution.

7. A digital signature device, based on the SPHINCS+ architecture, characterized in that, include: The digest processing module is used to obtain a random mask, a message digest, and a private key seed; determine each FORS tree, each XMSS subtree, and the signature leaf node of each XMSS subtree based on the message digest; and derive the FORS private key and the WOTS+ private key of the signature leaf node of each XMSS subtree based on the private key seed. The FORS signature module is used to sign the message digest based on the FORS private key to obtain the FORS signature, and to schedule multiple hash accelerators to perform the layer-by-layer hash merging operation of the leaf nodes of each FORS tree in parallel to obtain the FORS public key. The public key signature module is used to perform the WOTS+ signature algorithm on the FORS public key based on the WOTS+ private key of the signature leaf node of the underlying XMSS subtree, so as to obtain the WOTS+ signature of the FORS public key. The WOTS+ signature module is used to schedule multiple hash accelerators to generate the public key leaf nodes of the nth layer XMSS subtree in parallel; it schedules one hash accelerator to perform layer-by-layer hash merging operation on the leaf nodes of the nth layer XMSS subtree to obtain the root node and authentication path of the nth layer XMSS subtree, while scheduling the other hash accelerators to pre-generate the public key leaf nodes of the (n+1)th layer XMSS subtree in parallel. Based on the WOTS+ private key of the signature leaf node of the (n+1)th layer XMSS subtree, the WOTS+ signature algorithm is executed on the root node of the nth layer XMSS subtree to obtain the WOTS+ signature of the nth layer XMSS subtree; the bottom layer XMSS subtree is taken as the 0th layer XMSS subtree, and the above steps are repeated layer by layer from the bottom layer XMSS subtree until the root node and authentication path of the top layer XMSS subtree are obtained in the above steps. The signature encapsulation module is used to generate an XMSS supertree signature based on the authentication path of each XMSS subtree and the WOTS+ signature, and to generate an SPHINCS+ signature based on the random mask, the FORS signature and the XMSS supertree signature.

8. A SPHINCS+ architecture, applied to the digital signature method as described in any one of claims 1-6 or the digital signature apparatus as described in claim 7, characterized in that, include: The hash acceleration engine includes multiple hash accelerators, each with an independently configured address generator, register set, and FORS tree (FSM). The RISC-V core is communicatively connected to the hash acceleration engine and is used to send commands and parameters to the hash acceleration engine through the MIMO register. The storage subsystem is communicatively connected to the hash acceleration engine and the RISC-V core, respectively, and is used to store FORS tree data, XMSS subtree data, and data generated by the hash acceleration engine and the RISC-V core. The hash accelerator is configured as the Keccak accelerator.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the digital signature method as described in any one of claims 1-6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the digital signature method as described in any one of claims 1-6.

Images