Lightweight SPHINCS + hardware accelerator supporting all-parameter configuration

Abstract

The invention discloses a lightweight SPHINCS + hardware accelerator supporting full parameter configuration, and the hardware accelerator comprises a control unit which is used for selecting a parameter set in SPHINCS + according to an externally input parameter selection signal, and selecting a variant in SPHINCS + according to an externally input variant selection signal; the Hash function kernel unit comprises various Hash function processing modules and is used for selecting signals according to an externally input mode and calling the corresponding Hash function processing modules; the signature generation unit is used for generating a signature; and the storage unit comprises a signature register and a data register, the signature register is used for storing each component required in the signature generation stage, and the data register is used for storing the intermediate data generated in the signature generation stage. The method supports all parameter sets of SPHINCS +, can realize optimized utilization of storage resources, adapts to different application scenes, and can be widely applied to the technical field of computer systems.

Description

Technical Field

[0001] This application relates to the field of computer system technology, and in particular to a lightweight SPHINCS+ hardware accelerator that supports full parameter configuration. Background Technology

[0002] The SPHINCS+ framework is a flexible architecture that supports 36 parameter configurations, covering three hash functions (SHA-2, SHA-3, and Haraka), six parameter sets (corresponding to NIST security levels 1-5), and two instances (the simple variant "simple" and the robust variant "robust"). This flexibility allows SPHINCS+ to adapt to different application scenarios. For example, low-latency wireless communication typically requires a low security level to achieve low-latency signatures, while financial transaction systems require a higher security level.

[0003] However, existing hardware accelerators are mostly designed for single configurations and lack flexibility. Most current hardware accelerator designs are optimized for specific security configurations and lack dynamic support for the full parameter set of SPHINCS+. This rigid architecture forces signers and verifiers to pre-coordinate parameter settings, making it difficult to adapt to dynamically changing deployment environments. In resource-constrained IoT devices, existing solutions often fail to achieve a good balance between area efficiency and performance.

[0004] Regarding storage optimization, existing solutions are inefficient at handling Merkle tree structures. Furthermore, existing solutions lack optimization in leaf node management, requiring leaf nodes to be recalculated for each signature, increasing unnecessary hash operations and further impacting system performance.

[0005] In terms of adaptability to multiple scenarios, existing technologies have significant shortcomings. Resource-constrained environments such as the Internet of Things (IoT) require low-power, small-area designs, while financial-grade applications require strong resistance to side-channel attacks. Existing solutions struggle to achieve these often conflicting design goals within the same architecture, either sacrificing security for high performance or significantly reducing throughput for small size. Summary of the Invention

[0006] To address the aforementioned technical issues, the purpose of this application is to provide a lightweight SPHINCS+ hardware accelerator that supports full parameter configuration, enabling dynamic support for full parameter configuration, optimized utilization of storage resources, and adaptability to various scenarios.

[0007] To achieve the above objectives, one aspect of this application proposes a lightweight SPHINCS+ hardware accelerator that supports full parameter configuration, comprising: The control unit is used to schedule the key generation stage, the signature generation stage, and the signature verification stage, and selects the parameter set in SPHINCS+ according to the parameter selection signal of the external input, and selects the variant in SPHINCS+ according to the variant selection signal of the external input. A hash function core unit, the input of which is connected to the first output of the control unit, includes multiple hash function processing modules, which are used to call the corresponding hash function processing module according to the externally input mode selection signal; A signature generation unit, wherein the input terminal of the signature generation unit is connected to the second output terminal of the control unit, is used to generate a signature; The storage unit, including the hash function kernel unit and the signature generation unit, is connected to the storage unit and includes a signature register and a data register. The signature register is used to store the various components required in the signature generation stage, and the data register is used to store the intermediate data generated in the signature generation stage.

[0008] In some embodiments, the lightweight SPHINCS+ hardware accelerator further includes: The input / output port is connected to the signature generation unit and is used to input messages, signatures, and random number seeds, and to output signatures and signature verification results.

[0009] In some embodiments, the hash function processing module includes: The first hash function processing module, wherein the control unit and the storage unit are both connected to the first hash function processing module, is used to generate a digest based on the SHAKE-256 hash function; The second hash function processing module, wherein the control unit and the storage unit are both connected to the second hash function processing module, is used to generate a digest based on the SHA-256 hash function; The third hash function processing module, in which both the control unit and the storage unit are connected, is used to generate digests based on the Haraka hash function.

[0010] In some embodiments, the signature register includes: The leaf node storage module is used to store all leaf nodes at the top level of the Merkle tree during the key generation phase.

[0011] In some embodiments, the signature register includes: The mask storage module is used to store the mask data required for the Robust variant.

[0012] In some embodiments, the signature register includes: The seed storage module is used to store seed and address data in advance during WOTS+ hash chain calculation and Merkle tree calculation.

[0013] In some embodiments, the control unit is further configured to divide the Merkle tree into multiple subtrees of preset heights to achieve Merkle tree reconstruction.

[0014] In some embodiments, the control unit implements the scheduling of the key generation phase, the signature generation phase, and the signature verification phase based on a finite state machine.

[0015] In some embodiments, the generated signature is transmitted immediately during the signature generation phase.

[0016] In some embodiments, the signature is discarded immediately after use during the signature verification phase.

[0017] The beneficial effects of this application are as follows: This application provides a lightweight SPHINCS+ hardware accelerator that supports full parameter configuration, including a control unit, a hash function core unit, a signature generation unit, and a storage unit. The control unit is used to schedule the key generation stage, the signature generation stage, and the signature verification stage, and selects the parameter set in SPHINCS+ based on the externally input parameter selection signal, and selects the variant in SPHINCS+ based on the externally input variant selection signal; the hash function core unit includes multiple hash function processing modules, used to execute the corresponding hash function processing module according to the externally input pattern selection signal; the signature generation unit is used to generate a signature; the storage unit includes a signature register and a data register, the signature register is used to store the various components required in the signature generation stage, and the data register is used to store the intermediate data generated in the signature generation stage. On the one hand, this application integrates multiple hash function processing modules in the hash function core unit. By using parameter selection signals, variant selection signals, and mode selection signals, the corresponding parameter set, variant, and hash function are selected, achieving full programmability of configuration and supporting all parameter sets of SPHINCS+ to cater to different application scenarios. On the other hand, a hierarchical storage strategy is adopted in the storage unit. The signature register and data register store the components and intermediate data respectively, which can optimize the utilization of storage resources. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments of this application are described below. It should be understood that the drawings described below are only for the purpose of clearly illustrating some embodiments of the technical solutions in this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1A structural block diagram of a lightweight SPHINCS+ hardware accelerator supporting full parameter configuration provided in one embodiment of this application; Figure 2 A structural block diagram of a lightweight SPHINCS+ hardware accelerator supporting full parameter configuration, provided for another embodiment of this application; Figure 3 A schematic diagram of the structure of a lightweight SPHINCS+ hardware accelerator supporting full parameter configuration provided in one embodiment of this application; Figure 4 A detailed architectural diagram of a hash function kernel provided in one embodiment of this application; Figure 5 A schematic diagram illustrating the workflow of a hash core provided in one embodiment of this application; Figure 6 This is a schematic diagram of Merkle tree reconstruction provided in one embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0021] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0022] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0023] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0024] SPHINCS+: A hash-based stateless post-quantum digital signature scheme, standardized by NIST (National Institute of Standards and Technology) as SLH-DSA (stateless hash-based digital signature algorithm), providing long-term security.

[0025] WOTS+ (WinternitzOne-TimeSignaturePlus): is the underlying component of SPHINCS+, a one-time signature scheme that generates a signature by dividing the message into blocks and performing hash chain calculations.

[0026] Merkle tree: The core data structure of SPHINCS+, a balanced binary tree used to compress and authenticate multiple public keys, with its root node serving as the public key.

[0027] XMSSMT (eXtended Merkle Signature Scheme with Multi-Tree): is the framework foundation of SPHINCS+, a multi-layered Merkle tree structure that organizes multiple Merkle trees through a hypertree to support multi-message signatures.

[0028] FORS (ForestOfRandomSubsets): is a signature generation component of SPHINCS+, a forest structure consisting of k Merkle trees used to generate short signatures.

[0029] Hash functions: These are the cryptographic foundation of SPHINCS+, including three types: SHA-256, SHAKE-256, and Haraka, used for signing, key compression, and random number generation.

[0030] AES (Advanced Encryption Standard) is a widely used symmetric block cipher algorithm. It was officially established as a Federal Information Processing Standard (FIPS PUB197) by the National Institute of Standards and Technology (NIST) in 2001 to replace the insecure DES (Data Encryption Standard) algorithm.

[0031] With the rapid development of quantum computers, traditional public-key cryptography systems face severe security challenges. Classical cryptographic schemes such as the RSA (Rivest-Shamir-Adleman) algorithm based on the large number factorization problem and the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithm based on the elliptic curve discrete logarithm problem will become completely ineffective under Shor's algorithm attack on quantum computers. To address this threat, NIST launched the Post-Quantum Cryptography (PQC) standardization process in 2016, and selected four algorithms in 2022. Among them, SPHINCS+ stood out as the only stateless signature scheme based on hash functions, and was standardized as FIPS205 (i.e., SLH-DSA) in August 2024.

[0032] SPHINCS+ security is built upon the long-proven cryptographic assumption of collision resistance of hash functions, rather than an unproven mathematical problem. Therefore, it is considered a reliable choice for quantum security, possessing unique long-term security advantages. The scheme employs a hierarchical structure, integrating cryptographic components such as the Winternitz One-Time Signature Enhancement Scheme (WOTS+), the Extended Merkle Tree Multi-Tree Signature Scheme (XMSSMT), and the Random Subset Forest (FORS) to form a complete signature framework.

[0033] Based on an in-depth analysis of the current SPHINCS+ hardware implementation technology, existing technical solutions have insufficient research in several key dimensions such as configuration flexibility, storage efficiency, and performance balance. This seriously restricts the promotion and deployment of SPHINCS+ in practical applications of post-quantum cryptography.

[0034] In terms of configuration flexibility, existing hardware accelerators generally suffer from rigid architecture. Most designs bind the hardware structure to specific parameter configurations, such as supporting only a single hash function or a fixed security level. This design makes the accelerators unable to adapt to dynamically changing application scenarios. For example, in scenarios requiring a switch from low-security daily communication to high-security financial transactions, the system must deploy multiple dedicated accelerators, significantly increasing hardware costs and system complexity. More importantly, this rigid architecture contradicts the original design intent of the SPHINCS+ standard, which supports 36 parameter configurations, limiting its applicability in diverse application environments.

[0035] Regarding storage optimization, the storage requirements of the Merkle tree structure in the SPHINCS+ algorithm increase exponentially with the tree height. When processing a Merkle tree of height 14, traditional storage methods require 16,384 storage units. However, in actual signing processes, most intermediate nodes are used very infrequently, resulting in a serious waste of storage resources. Furthermore, existing schemes lack sufficient optimization in leaf node management, requiring the recalculation of leaf nodes for each signature, increasing unnecessary hash operations and further impacting system performance.

[0036] In balancing performance and area, existing solutions often struggle to achieve both efficiency and resource consumption. Some designs improve throughput through deep pipelining, but at the cost of a significant increase in resource consumption; while other area optimization solutions severely sacrifice performance. This imbalance makes it difficult to effectively deploy existing accelerators in resource-constrained application scenarios (such as IoT edge devices). Furthermore, the signature latency issue remains unresolved; the serial execution of hash operations and inefficient message scheduling mechanisms result in generally low hash core utilization, failing to fully realize the potential of hardware acceleration.

[0037] Existing technologies have significant shortcomings in adaptability to multiple scenarios. Resource-constrained environments such as the Internet of Things (IoT) require low-power, small-area designs, while financial-grade applications demand strong resistance to side-channel attacks. Existing solutions struggle to achieve these often conflicting design goals within the same architecture, either sacrificing security for high performance or significantly reducing throughput for small size.

[0038] In summary, existing SPHINCS+ hardware acceleration technologies suffer from several core technical shortcomings, including insufficient configuration flexibility, low storage efficiency, performance-area imbalance, excessively high signature latency, and poor adaptability to various scenarios. These shortcomings severely restrict the large-scale deployment of SPHINCS+ in practical applications, urgently requiring an innovative hardware architecture that can simultaneously address these issues.

[0039] In view of this, this application proposes a lightweight SPHINCS+ hardware accelerator that supports full parameter configuration, including a control unit, a hash function kernel unit, a signature generation unit, and a storage unit. The control unit is used to schedule the key generation stage, the signature generation stage, and the signature verification stage, and selects the parameter set in SPHINCS+ according to an externally input parameter selection signal, and selects a variant in SPHINCS+ according to an externally input variant selection signal; the hash function kernel unit includes multiple hash function processing modules, used to execute the corresponding hash function processing module according to an externally input pattern selection signal; the signature generation unit is used to generate a signature; the storage unit includes a signature register and a data register, the signature register is used to store the various components required in the signature generation stage, and the data register is used to store the intermediate data generated in the signature generation stage. On the one hand, this application integrates multiple hash function processing modules in the hash function core unit. By using parameter selection signals, variant selection signals, and mode selection signals, the corresponding parameter set, variant, and hash function are selected, achieving full programmability of configuration and supporting all parameter sets of SPHINCS+ to cater to different application scenarios. On the other hand, a hierarchical storage strategy is adopted in the storage unit. The signature register and data register store the components and intermediate data respectively, which can optimize the utilization of storage resources.

[0040] Reference Figure 1 , Figure 1 This is a structural block diagram of a lightweight SPHINCS+ hardware accelerator supporting full parameter configuration, provided in one embodiment of this application. This embodiment of the application proposes a lightweight SPHINCS+ hardware accelerator supporting full parameter configuration, comprising: The control unit is used to schedule the key generation stage, the signature generation stage, and the signature verification stage, and selects the parameter set in SPHINCS+ according to the parameter selection signal of the external input, and selects the variant in SPHINCS+ according to the variant selection signal of the external input. The hash function core unit has its input connected to the first output of the control unit and includes multiple hash function processing modules. These modules are used to call the corresponding hash function processing module based on the external input mode selection signal. A signature generation unit, the input of which is connected to the second output of the control unit, is used to generate a signature; The storage unit, hash function kernel unit, and signature generation unit are all connected to the storage unit, including a signature register and a data register. The signature register is used to store the various components required in the signature generation stage, and the data register is used to store the intermediate data generated in the signature generation stage.

[0041] Reference Figure 2 , Figure 2The structural block diagram of a lightweight SPHINCS+ hardware accelerator supporting full parameter configuration provided in another embodiment of this application, further as an optional implementation, includes: The input / output port is connected to the signature generation unit and is used to input messages, signatures, and random number seeds, and to output signatures and signature verification results.

[0042] Specifically, this embodiment is implemented on an FPGA (Field Programmable Gate Array) platform and designed and coded using Verilog Hardware Description Language (HDL). This embodiment fully implements a hardware accelerator that supports full parameter configuration of SPHINCS+, and its core objective is to achieve high-performance signature generation and verification while maintaining lightweight hardware resource consumption.

[0043] In some alternative embodiments, such as Figure 3 The diagram illustrates the structure of a lightweight SPHINCS+ hardware accelerator supporting full parameter configuration, according to one embodiment of this application. The system includes a control unit, a hash function core unit, a signature generation unit, a storage unit, and input / output ports. Different parameter sets are selected via parameter selection signals, instance variants (including Robust and Simple variants) are controlled via variant selection signals, and the underlying hash function is controlled via mode selection signals. This achieves full programmability for runtime configuration, enabling a single hardware accelerator to adapt to various application scenarios, from IoT devices to financial systems. Users can flexibly adjust different security levels from NIST Level 1 to Level 5 at runtime according to actual needs without replacing hardware, significantly improving device utilization and deployment flexibility. For example, energy efficiency optimization can be prioritized in IoT devices, while security performance can be emphasized in financial systems, enabling seamless deployment in various scenarios from smart homes to financial infrastructure, laying a solid foundation for the widespread adoption of post-quantum cryptography technology.

[0044] The storage unit is designed based on the specific requirements of the SPHINCS+ algorithm and adopts a hierarchical storage strategy, including a signature register and a data register. The signature register is specifically used to store the various components required for SPHINCS+ signing, including the random number R, FORS signature data, and supertree signature data; the data register is used to temporarily store the intermediate results generated during the FORS and WOTS+ calculation process.

[0045] The signature unit generates verifiable quantum-safe signatures in a stateless mode through the collaboration of chain signatures, tree signatures, and FORS signatures, combined with randomization and supertree authentication. This is the core mechanism of SPHINCS+'s implementation of post-quantum digital signatures.

[0046] The input / output ports are used to interact with users for messages, signature input, random number seeds, signature output, and signature verification results.

[0047] As an optional implementation, the control unit uses a finite state machine to schedule the key generation phase, signature generation phase, and signature verification phase.

[0048] Specifically, the control unit employs a hierarchical finite state machine design. Through intelligent process scheduling and state management, it coordinates cryptographic operations (such as key generation, signing, and verification) with underlying algorithm components (such as hash chains, Merkle trees, and key compression), thereby achieving efficient utilization of system resources and secure and reliable operation. The state transition logic of the finite state machine ensures that key generation, signing, and verification processes are executed in a strict sequence. For example, key generation must be completed before signing, avoiding logical conflicts.

[0049] Reference Figure 3 As an optional implementation, the hash function processing module includes: The first hash function processing module, the control unit and the storage unit are both connected to the first hash function processing module, and are used to generate digests based on the SHAKE-256 hash function; The second hash function processing module, the control unit and the storage unit are both connected to the second hash function processing module, and are used to generate digests based on the SHA-256 hash function; The third hash function processing module, the control unit and the storage unit are all connected to the third hash function processing module, and are used to generate digests based on the Haraka hash function.

[0050] Specifically, the hash function core unit of this application embodiment innovatively integrates multiple hash function processing modules, and realizes dynamic support for different hash algorithms such as SHA-256, SHAKE-256 and Haraka through hardware reuse technology.

[0051] In some alternative embodiments, such as Figure 4The diagram shows a detailed architecture of a hash function core provided in one embodiment of this application. This unit adopts a unified sponge structure design, enabling flexible handling of variable-length input and output data. The SHAKE-256 hash function implementation uses a 24-round Keccak permutation algorithm, with each round containing five standard steps: θ (Theta), ρ (Rho), π (Pi), χ (Chi), and ι (Iota). The SHA-256 hash function implementation uses a 64-round standard computation process, with each round including key operations such as message scheduling and message expansion. The Haraka hash function implementation is based on the AES structure, completing hash calculation through 10 rounds of efficient permutation. The hash core controls the number of iterations in the absorption and squeezing phases using parameters M and N, precisely controls the length of the output digest using the cnt signal, and achieves interaction between the hash core and the system using a full signal, thus perfectly supporting all parameter configurations of SPHINCS+.

[0052] Reference Figure 3 As an optional implementation, the signature register includes: The leaf node storage module is used to store all leaf nodes at the top level of the Merkle tree during the key generation phase.

[0053] It should be noted that, regarding signature speed optimization, this application proposes an innovative leaf node storage strategy. Through in-depth analysis of the structural characteristics of the Merkle tree, it was found that storing the top-level Merkle tree nodes during the key generation stage can accelerate the number of hash function operations performed on the tree during the signature process, thereby reducing signature time. Specifically, a leaf node storage module stores all leaf nodes of the top-level Merkle tree to minimize hash operations using as few storage resources as possible, achieving the most efficient storage implementation. This optimization strategy performs excellently under different parameter configurations, and storing leaf nodes always achieves the lowest overall cost.

[0054] Reference Figure 3 As an optional implementation, the signature register includes: The mask storage module is used to store the mask data required for the Robust variant.

[0055] Specifically, the mask storage module is used to support the mask data storage required for the robust variant, ensuring security against side-channel attacks.

[0056] Reference Figure 3 As an optional implementation, the signature register includes: The seed storage module is used to store seed and address data in advance during WOTS+ hash chain calculation and Merkle tree calculation.

[0057] It should be noted that, in terms of performance optimization, this application's embodiments introduce an advanced message prefetching mechanism. During the WOTS+ hash chain and Merkle tree calculations, the seed and address data are preloaded into registers through the seed storage module (including public key seed storage and private key seed storage), effectively reducing the idle time of the hash core. Specifically, each hash operation can save 4 + n / 64 clock cycles, where n is the bit length of the hash output (typically 128, 192, or 256 bits). This optimization mechanism significantly improves the utilization rate of the hash core, resulting in a substantial improvement in overall performance. Figure 5 The diagram shows the workflow of a hash core provided in one embodiment of this application, including the specific timing of message prefetching and the direction of data flow.

[0058] As an optional implementation, the control unit is also used to divide the Merkle tree into multiple subtrees of preset heights to achieve Merkle tree reconstruction.

[0059] It should be noted that, addressing the storage challenges of tall Merkle trees, this application proposes an innovative tree structure reconstruction method. By dividing a large tree of height H into multiple smaller trees of height H′, storage requirements are significantly reduced. This method is particularly suitable for resource-constrained applications, achieving substantial optimization of storage resources without significantly increasing the complexity of control logic.

[0060] For example, setting the supertree's reconstruction height H′ to 3 and the FORS tree's reconstruction height to 5 reduces the storage requirement from 2H to 2H′. Figure 6 The figure shows a schematic diagram of Merkle tree reconstruction provided in one embodiment of this application. The figure shows a specific example of dividing a Merkle tree with height H=4 into a subtree with height H′=2.

[0061] As an optional implementation, the generated signature is transmitted immediately during the signature generation stage.

[0062] As a further optional implementation, the used signature is discarded immediately during the signature verification stage.

[0063] It should be noted that the embodiments of this application also employ a memory-minimized real-time signature stream technology. By transmitting the signature data immediately after generation instead of storing it completely, memory requirements are further reduced. Simultaneously, during the signature verification process, the signature data is discarded immediately after use to avoid unnecessary storage overhead. This pipelined processing approach improves system throughput.

[0064] The structure and working principle of a lightweight SPHINCS+ hardware accelerator supporting full parameter configuration according to an embodiment of this application have been described above. It can be recognized that, compared with existing hardware accelerators, this application has the following advantages: I. In terms of configuration flexibility, the innovative unified hardware architecture design successfully solves the problem of rigid configuration in existing SPHINCS+ hardware accelerators. Compared with the limitations of existing technologies that only support single parameter configuration, this technology achieves full support for all 36 parameter configurations of SPHINCS+ for the first time by selecting the corresponding parameter set, variant, and hash function through parameter selection signals, variant selection signals, and mode selection signals. This includes dynamic switching of three hash functions (SHA-256, SHAKE-256, Haraka), six security levels (NIST Level 1-5), and two instance types (simple, robust). This enables a single hardware accelerator to adapt to diverse application environments, from high-speed IoT scenarios to high-security financial requirements.

[0065] Second, regarding storage efficiency, by employing leaf node storage technology and the Merkle tree reconstruction method, the exponentially increasing storage requirements of traditional solutions were successfully reduced. Simultaneously, by promptly outputting and discarding signatures, the storage requirements for intermediate data were further reduced, making it possible to deploy high-performance post-quantum cryptography algorithms in resource-constrained IoT devices.

[0066] Thirdly, regarding the balance between performance and area optimization, significant performance improvements were achieved while maintaining lightweight hardware characteristics through the collaborative design of the reconfigurable hash core and control unit. Specifically, by pre-loading seed and address data, the utilization rate of the hash core was improved, and the algorithm's running speed was increased.

[0067] Fourth, regarding signature latency optimization, by storing all leaf nodes of the top-level Merkle tree during the key generation stage, the hash function operations required to reconstruct the tree during the signing process are reduced, thus accelerating the signing time. Simultaneously, the hash core adopts a unified sponge structure design, supporting seamless switching between SHA-256, SHAKE-256, and Haraka hash functions, ensuring algorithm security while reducing signing time. Especially in resource-constrained environments, it demonstrates superior signature speed, providing technical support for the large-scale application of edge computing devices.

[0068] Fifth, in terms of multi-scenario adaptability, through dynamic configuration methods based on parameter selection signals, variant selection signals and mode selection signals, and intelligent scheduling methods based on finite state machines, the hardware accelerator can automatically adjust the computing strategy according to different application scenarios and adapt to multiple scenarios.

[0069] In the foregoing description of this specification, the references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0070] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0071] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A lightweight SPHINCS+ hardware accelerator supporting full parameter configuration, characterized in that, The application relates to a lightweight SPHINCS+ hardware accelerator. The lightweight SPHINCS+ hardware accelerator comprises: a control unit for scheduling a key generation stage, a signature generation stage and a signature verification stage, and selecting a parameter set in SPHINCS+ according to an externally input parameter selection signal and selecting a variant in SPHINCS+ according to an externally input variant selection signal; a hash function core unit, an input end of the hash function core unit being connected with a first output end of the control unit, the hash function core unit comprising a plurality of hash function processing modules for calling corresponding hash function processing modules according to an externally input mode selection signal; a signature generation unit, an input end of the signature generation unit being connected with a second output end of the control unit, the signature generation unit being used for generating a signature; 2. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration according to claim 1, wherein, a storage unit, the hash function core unit and the signature generation unit being connected with the storage unit, the storage unit comprising a signature register and a data register, the signature register being used for storing various components required in a signature generation stage, and the data register being used for storing intermediate data generated in the signature generation stage. The lightweight SPHINCS+ hardware accelerator further comprises:

3. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration of claim 1, wherein, an input / output port, the input / output port being connected with the signature generation unit and being used for inputting a message, a signature and a random number seed and outputting a signature and a signature verification result. The hash function processing modules comprise: a first hash function processing module, the control unit and the storage unit being connected with the first hash function processing module, the first hash function processing module being used for generating a digest based on a SHAKE-256 hash function; a second hash function processing module, the control unit and the storage unit being connected with the second hash function processing module, the second hash function processing module being used for generating a digest based on a SHA-256 hash function; 4. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration of claim 1, wherein, a third hash function processing module, the control unit and the storage unit being connected with the third hash function processing module, the third hash function processing module being used for generating a digest based on a Haraka hash function. The signature register comprises:

5. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration of claim 1, wherein, a leaf node storage module for storing all leaf nodes of a top layer of a Merkle tree in a key generation stage. The signature register comprises:

6. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration of claim 1, wherein, a mask storage module for storing mask data required by a Robust variant. The signature register comprises:

7. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration of claim 1, wherein, a seed storage module for storing seed and address data in advance in a WOTS+ hash chain calculation and a Merkle tree calculation process.

8. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration of claim 1, wherein, The control unit is further used for dividing a Merkle tree into a plurality of small trees with a preset height to realize Merkle tree reconstruction.

9. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration of claim 1, wherein, The control unit realizes scheduling of a key generation stage, a signature generation stage and a signature verification stage based on a finite state machine.

10. The lightweight SPHINCS+ hardware accelerator supporting full parameter configuration of claim 1, wherein, In the signature generation stage, the generated signature is immediately transmitted. In the signature verification stage, the used signature is immediately discarded.

Images