A hardware acceleration method and system for ML-DSA signature based on norm rejection

Abstract

The application relates to an ML-DSA signature hardware acceleration method and system based on norm rejection. The method comprises the following steps: in one ML-DSA signature attempt, sampling, polynomial operation and intermediate quantity generation are performed by a hardware signature controller; a norm check module performs norm rejection judgment on the intermediate quantity according to a norm judgment rule stipulated in an ML-DSA standard, and generates a norm rejection signal; when the norm rejection signal indicates that the current signature attempt is bound to be rejected, the hardware signature controller bypasses a MakeHint calculation path and directly enters the next signature attempt; when the norm rejection signal does not indicate that the current signature attempt is bound to be rejected, MakeHint calculation and subsequent standard checking are continuously performed. By adopting the method, invalid hardware calculation in the rejected signature attempt can be reduced without changing the ML-DSA standard sampling mode, threshold, acceptance rule and signature output format.

Description

Technical Field

[0001] This application relates to the field of quantum cryptography, and in particular to a hardware acceleration method and system for ML-DSA signatures based on norm rejection. Background Technology

[0002] Post-quantum cryptography is used to resist potential attacks by quantum computing on traditional public-key cryptosystems. ML-KEM is used for key encapsulation, and ML-DSA is used for digital signatures; the two are often used in combination in embedded devices, edge platforms, and secure communication systems. Lattice-based cryptographic algorithms involve computational processes such as sampling, multinomial operations, hashing, encoding, and rejection sampling, and are suitable for acceleration using FPGA, ASIC, or SoC hardware coprocessors.

[0003] Existing lattice-based cryptography hardware implementations typically focus on arithmetic modules such as single cryptographic primitives, NTT, or polynomial multiplication, or implement coprocessors compatible with multiple lattice-based algorithms such as Kyber and Dilithium. Publicly available solutions have addressed areas such as Kyber / Dilithium-compatible coprocessors, parallel small polynomial multiplication for lattice-based signatures, general-purpose storage structures, and pipelined scheduling. While these solutions can improve arithmetic throughput, the following problems remain in the complete key establishment and signature authentication process: ML-DSA signature operations exhibit rejection sampling characteristics; different messages and random inputs may lead to different signature attempt counts, resulting in random fluctuations in signature latency. If the hardware lacks a profiling count of signature attempts and rejection reasons, it is difficult to determine whether the latency primarily stems from norm rejection, MakeHint rejection, or other paths. When the standard norm check has determined that the current signature attempt will inevitably be rejected, if the hardware continues to execute MakeHint calculations and related subsequent paths, invalid cycles that do not affect the final signature output will be generated. Reducing the number of rejections by changing the sampling method, threshold, or acceptance rules may alter the ML-DSA signature distribution, making it unsuitable for standard-compliant secure implementations.

[0004] Therefore, there is a need for a control method that reduces invalid hardware computations in rejected signature attempts without changing the ML-DSA standard sampling, threshold, acceptance rules, and output format, and provides hardware-level profiling counts to locate and verify signature retry bottlenecks. Summary of the Invention

[0005] Therefore, it is necessary to provide a norm-based rejection-based ML-DSA signature hardware acceleration method and system that can reduce invalid hardware computations in rejected signature attempts and provide hardware-level profiling counts to locate signature retry bottlenecks without changing the ML-DSA standard sampling method, threshold, acceptance rules, and signature output format.

[0006] A hardware acceleration method for ML-DSA signatures based on norm rejection, the method being executed based on a hardware acceleration device comprising a signature controller, a sampling and polynomial operation module, a norm checking module, a MakeHint module, a retry control module, and a parsing counter register group, comprising: The signature controller receives a signature start command from an external input and performs initialization operations on the signature attempt count, norm rejection count, MakeHint rejection count, joint rejection count, and most recent rejection flag in the parsing count register group; The sampling and polynomial operation module performs sampling and polynomial operation processing for a single signature attempt, generates an intermediate quantity for norm checking, and transmits the intermediate quantity to the norm checking module. The norm checking module verifies the received intermediate quantity according to the norm determination rules specified in the ML-DSA standard, generates a norm rejection signal, and outputs the norm rejection signal to the signature controller and retry control module. If the norm rejection signal indicates that the current signature attempt will definitely be rejected, the signature controller updates the norm rejection count and the most recent rejection flag in the parsing count register group, bypasses the calculation path of the MakeHint module through the retry control module, and jumps to the signature retry entry to start the next signature attempt; If the norm rejection signal does not indicate that the current signature attempt will necessarily be rejected, the signature controller starts the MakeHint module to perform the corresponding calculation. After the calculation is completed, it performs subsequent standard checks. If the subsequent standard check determines that it is a rejection, it updates the corresponding rejection count in the profile count register group and starts the next signature attempt. If the subsequent standard check determines that it passes, it outputs the final signature result.

[0007] A hardware acceleration system for ML-DSA signature based on norm rejection, the system comprising a signature controller, a sampling and polynomial operation module, a norm checking module, a MakeHint module, a retry control module, and a parsing counter register group; The signature controller is used to control the state transitions and updates of the counter register for ML-DSA signature attempts; The sampling and polynomial operation module is used to generate the polynomial or vector intermediates required for signature attempts and output them to the norm checking module; The norm checking module is used to verify the received intermediate quantity according to the norm determination rules specified in the ML-DSA standard, generate a norm rejection signal and output it to the signature controller and retry control module. The retry control module is used to send a bypass control signal to the signature controller when the norm rejection signal indicates that the current signature attempt will inevitably be rejected, so that the signature controller bypasses the calculation path of the MakeHint module and jumps to the next signature attempt; The MakeHint module is used to receive the start signal from the signature controller and perform the corresponding calculation when the norm rejection signal does not indicate that the current signature attempt will necessarily be rejected. The profile counter register group is used to record the number of signature attempts and the corresponding count values ​​for various rejection reasons.

[0008] The aforementioned hardware acceleration method and system for ML-DSA signatures based on norm rejection employs a technique that incorporates a norm checking module, a retry control module, and a profiling counter register group within the ML-DSA signature hardware architecture. After a single signature attempt completes the standard norm check and generates a norm rejection signal, the retry control module controls the hardware state transition based on the rejection signal. When it is determined that the current signature attempt will inevitably be rejected, the MakeHint calculation path is bypassed, and the next signature attempt is initiated. The entire process strictly adheres to the sampling method, judgment threshold, acceptance rules, and signature output format of the ML-DSA standard. This scheme directly eliminates the MakeHint problem in norm rejection scenarios without altering the cryptographic algorithm rules, changing the signature distribution, or introducing security risks. The invalid hardware cycles of the eHint computation path alleviate the random fluctuations in signature latency caused by rejection sampling, reduce the ineffective consumption of hardware resources, and are suitable for actual operating scenarios where norm rejection is the main reason for retry. Furthermore, by using a hardware profile counter register that can classify and count the number of signature attempts, norm rejections, MakeHint rejections, joint rejections, and the most recent rejection flag, the hardware-level observability of the reasons for signature retry is achieved, solving the problem that existing hardware cannot accurately locate performance bottlenecks. At the same time, this acceleration architecture can be integrated with ML-KEM acceleration peripherals to form a complete post-quantum cryptography processing system, which can be adapted to various hardware platforms such as FPGA, ASIC, SoC programmable logic and cryptographic coprocessors, and has broad system applicability. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the overall structure of a quantum cryptography processing system in one embodiment; Figure 2 This is a schematic diagram of an ML-DSA signature hardware acceleration device in one embodiment; Figure 3 This is a flowchart illustrating a hardware acceleration method for ML-DSA signatures based on norm rejection in one embodiment. Figure 4 This is a schematic diagram of the signature retry control process based on norm rejection determination in another embodiment; Figure 5 This is a schematic diagram illustrating the analysis of the counting and control register group in one embodiment. Detailed Implementation

[0010] 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 and not intended to limit the scope of this application.

[0011] The norm rejection-based ML-DSA signature hardware acceleration method provided in this application can be applied to, for example... Figure 1 The quantum cryptography processing system shown employs a collaborative architecture between a processing system 100 and a hardware acceleration side 200. The processing system 100 accesses the hardware acceleration side 200 via a storage mapping interface 300. The processing system 100 includes a scheduling control unit 101, an MMIO read / write unit 102, and a result verification unit 103. The hardware acceleration side 200 includes an ML-KEM acceleration peripheral 210, an ML-DSA acceleration peripheral 220, a state retention unit 230, and a period and parsing register 240. In this system, the ML-KEM acceleration peripheral 210 supports KeyGen, Enc, and Dec operations, while the ML-DSA acceleration peripheral 220 supports ML-DSAKeyGen, Sign, and Verify operations. The complete process executes ML-KEMKeyGen, ML-DSAKeyGen, ML-KEMEnc, ML-DSASign, ML-KEMDec, and ML-DSAVerify sequentially. The hardware acceleration side 200 retains necessary states between multiple cryptographic operation stages through the state retention unit 230, while the processing system side 100 is responsible for scheduling, reading and writing, state checking, and output verification. The hardware acceleration side retains at least a portion of the key, ciphertext, shared secret, intermediate signature state, operation state, or cycle count information between multiple cryptographic operation stages. The processing system side is used to set the operation mode, write input data, initiate hardware operations, read the operation state, read output data, read the cycle count, and read the parsing count through a storage mapping interface. The hardware acceleration side can be implemented in an FPGA, ASIC, SoC programmable logic, or cryptographic coprocessor.

[0012] In one embodiment, such as Figure 3 As shown, a hardware acceleration method for ML-DSA signatures based on norm rejection is provided. The method is based on... Figure 2 The hardware acceleration device shown includes a signature controller, a sampling and polynomial operation module, a norm checking module, a MakeHint module, a retry control module, and a profile counter register set. Figure 2In the illustrated ML-DSA signature hardware acceleration device, the input FIFO receives the signature input written by the processing system; the signature controller controls one or more signature attempts in a single signature operation; the sampling and polynomial operation module generates the polynomial or vector intermediate quantities required for the signature attempt; the norm checking module generates a norm rejection signal; the retry control module controls whether to bypass the MakeHint module based on the norm rejection signal; the parsing counter register group records the number of signature attempts and the reasons for rejection; and the cycle counter records the number of hardware operation cycles. The hardware acceleration device exchanges signature input data and signature output data with the external processing system through the input FIFO, output FIFO, or memory mapping window.

[0013] Includes the following steps: Step 1: The signature controller receives the signature start instruction from the external input and performs initialization operations on the signature attempt count, norm rejection count, MakeHint rejection count, joint rejection count, and most recent rejection flag in the parsing count register group.

[0014] The signature attempt count records the total number of signature attempts in a single signature operation; the norm rejection count records the number of signature attempt failures caused by norm rejection; the MakeHint rejection count records the number of failures caused by MakeHint-related rejections in subsequent standard checks; the combined rejection count records the number of times norm rejection and MakeHint rejection occur simultaneously; and the most recent rejection flag records the reason type of the most recent rejection. By initializing these counters, we ensure that each signature operation records profiling data starting from zero, providing an accurate counting benchmark for subsequent performance analysis.

[0015] Step 2: The sampling and polynomial operation module performs sampling and polynomial operation processing for a single signature attempt, generates an intermediate quantity for norm checking, and transmits the intermediate quantity to the norm checking module.

[0016] In a signature attempt, the hardware first generates intermediate quantities to be checked, such as relevant intermediate quantities for calculating or checking w0-cs2, which are the underlying data for subsequent norm checks.

[0017] Step 3: The norm checking module performs verification processing on the received intermediate quantity according to the norm determination rules specified in the ML-DSA standard, generates a norm rejection signal, and outputs the norm rejection signal to the signature controller and retry control module.

[0018] The norm checking module determines whether the current intermediate quantity meets the norm requirements according to the norm threshold and judgment rules specified in the ML-DSA standard. If it does not meet the requirements, a valid norm rejection signal is generated, indicating that the current signature attempt will inevitably be rejected. This norm rejection signal is generated after the hardware state calculation or check of w0-cs2 has been completed.

[0019] Step 4: If the norm rejection signal indicates that the current signature attempt will definitely be rejected, the signature controller updates the norm rejection count and the most recent rejection flag in the parsing count register group, bypasses the calculation path of the MakeHint module through the retry control module, and jumps to the signature retry entry to start the next signature attempt.

[0020] When the norm rejection signal is triggered, the current signature attempt has been determined to fail the norm check. Therefore, any results generated by continuing MakeHint computation will not affect the final signature output and are considered invalid computations. This step bypasses the computation path of the MakeHint module by using the retry control module, while controlling the MakeHint module to remain in a reset state or maintain its current local state without initiating new computation operations, thus saving invalid computation cycles. Simultaneously, the signature controller updates the norm rejection count and the most recent rejection flag, providing data for subsequent performance analysis.

[0021] Step 5: If the norm rejection signal does not indicate that the current signature attempt will necessarily be rejected, the signature controller starts the MakeHint module to perform the corresponding calculation. After the calculation is completed, the subsequent standard check is performed. If the subsequent standard check determines that it is a rejection, the corresponding rejection count in the parsing count register group is updated and the next signature attempt is started. If the subsequent standard check determines that it passes, the final signature result is output.

[0022] If the norm rejection signal is not triggered, the current signature attempt initially passes the norm check and needs to continue executing MakeHint calculation and subsequent standard checks to complete the full signature verification process. If the subsequent standard check determines rejection, the corresponding rejection count is updated according to the specific situation—if the norm rejection signal is also valid, the joint rejection count is updated; if the norm rejection signal is invalid, the MakeHint rejection count is updated—and the next signature attempt is initiated. If the subsequent standard check does not reject, the signature result is output and the signature operation ends.

[0023] In the aforementioned hardware acceleration method for ML-DSA signatures based on norm rejection, the hardware signature controller first verifies intermediate quantities according to the norm determination rules specified in the ML-DSA standard during an ML-DSA signature attempt by the norm check module and generates a norm rejection signal. When this signal indicates that the current attempt will inevitably be rejected, the retry control module immediately bypasses the MakeHint calculation path and jumps directly to the signature retry entry. At the same time, the MakeHint module is kept in a reset state to save invalid cycles. This method utilizes the inherent logic that once norm rejection is achieved, subsequent MakeHint calculations have no contribution to the final signature output. By cutting off the invalid calculation path in advance at the hardware control layer, the invalid calculation cycle of the MakeHint path in signature attempts rejected by norm is significantly reduced without changing the sampling method, threshold, acceptance rules, and signature output format of ML-DSA. This solves the efficiency problem of hardware continuing to execute MakeHint calculations and generating invalid cycles when the standard norm check has determined that the current attempt will inevitably be rejected. Meanwhile, this application addresses the issue of lacking signature attempt and rejection reason analysis counts in the hardware acceleration device, which makes it difficult to determine the main rejection path from which the delay originates. This is achieved by setting up a set of profiled count registers, including signature attempt count, norm rejection count, MakeHint rejection count, joint rejection count, and recent rejection flag, in the hardware acceleration device and updating these counts in real time under the control of the signature controller. This allows the processing system to directly read the rejection reason distribution and retry count, thus accurately locating whether the signature delay originates from norm rejection or MakeHint rejection. This solves the observability defect of hardware lacking signature attempt and rejection reason profiled counts, making it difficult to determine the main rejection path from which the delay originates. Furthermore, the hardware acceleration device of this application can be integrated with ML-KEM acceleration peripherals in the same post-quantum cryptography processing system. It retains key, ciphertext, shared secret, intermediate signature states, and cycle count information between multiple cryptographic operation stages. Through a unified storage mapping interface, it provides scheduling, reading, writing, status checking, and output verification for the processing system. This makes it suitable for FPGA, ASIC, SoC programmable logic, or cryptographic coprocessors, solving the problem of hardware acceleration and system integration adaptation in the complete key establishment and signature authentication process. This application works synergistically from two levels: early termination due to invalid computation and fine-grained analysis of rejection reasons. While maintaining the behavior of the ML-DSA standard algorithm completely unchanged, it achieves a balance between the efficiency, observability, and system applicability of signature hardware acceleration. It effectively overcomes a series of technical problems existing in the background technology, such as the difficulty in optimizing random fluctuations in latency, the inability to locate performance bottlenecks, the waste of resources due to invalid computation, and the disruption of standard compatibility due to changes in algorithm rules.

[0024] Figure 4This demonstrates the signature retry control flow based on norm rejection determination. After a signature operation begins, the hardware first initializes the attempt count and rejection count. Then, a signature attempt is performed, along with a standard norm check. When a norm rejection determination is triggered, the hardware updates the norm rejection count, bypasses the MakeHint calculation path, and proceeds to the next signature attempt. When a norm rejection determination is not triggered, the hardware continues to perform MakeHint calculation and subsequent standard checks. If the subsequent check rejects the attempt, the next signature attempt is initiated; otherwise, the signature is output and the process ends.

[0025] In one embodiment, the norm rejection determination process of the norm checking module is generated after the hardware state for calculating or checking w0-cs2 is completed; the retry control module only performs the bypass operation of the calculation path of the MakeHint module after the norm rejection determination is completed.

[0026] Specifically, the norm check in the ML-DSA signature algorithm involves determining the norm of w0-cs2 related intermediate quantities. In this embodiment, the norm check module performs norm determination immediately after the intermediate quantity is calculated and generates a norm rejection signal. The retry control module only decides whether to bypass the MakeHint module's calculation path based on the norm rejection signal after the norm rejection determination is completed, ensuring that the determination logic is consistent with the standard algorithm flow. This setting ensures that the bypass decision of the retry control module is synchronized with the standard norm check result, avoiding incorrect skipping of the MakeHint calculation that should be executed due to timing deviations. While ensuring the compatibility of the standard algorithm, it accurately initiates path bypassing immediately after the norm rejection determination is completed, maximizing the efficiency of saving invalid calculations.

[0027] In one embodiment, when the norm rejection signal indicates that the current signature attempt will inevitably be rejected, the signature controller controls the MakeHint module to remain in a reset state or maintain the current local state, without initiating a new computation operation.

[0028] Specifically, when the norm rejection signal is triggered, the MakeHint module does not receive the start signal sent by the signature controller. Its internal state machine remains idle or in a reset state, and the relevant computation path is not activated. From the hardware control level, this completely avoids the MakeHint module consuming any computation cycles and dynamic power consumption in the currently rejected signature attempt.

[0029] In one embodiment, when the norm rejection signal does not indicate that the current signature attempt will necessarily be rejected, the signature controller keeps the original MakeHint module calculation path and subsequent signature check path unchanged, and performs calculation and check according to the ML-DSA standard process.

[0030] Specifically, when the norm rejection signal is not triggered, the signature controller sequentially starts the MakeHint module to perform calculations according to the ML-DSA standard algorithm flow, and continues to perform subsequent standard checks after the calculations are completed. It does not change any calculation path or check rules, ensuring that signature attempts that pass the norm check can completely execute the standard signature process and output correct signature results that conform to the ML-DSA standard.

[0031] In one embodiment, the hardware acceleration device further includes a cycle counter; when the signature operation is initiated, the signature controller triggers the cycle counter to start counting, and when the signature operation is completed, the cycle counter is triggered to stop counting, and the total number of cycles recorded by the cycle counter is stored in the corresponding cycle count register.

[0032] Specifically, the cycle counter is used to record the number of hardware clock cycles consumed from the start to the completion of a complete ML-DSA signature operation. When the signature controller receives the signature start command, it triggers the cycle counter to start counting. When the final signature result is output, it triggers the cycle counter to stop counting and stores the count value in the cycle count register (CYCLES). This provides the processing system side with accurate measurement data of hardware operation time, which is convenient for performance evaluation and optimization verification.

[0033] In one embodiment, the total number of cycles in the cycle counter register is converted into hardware operation time using a preset formula, which is:

[0034] in, The hardware operation time for a single signature operation. The total number of cycles recorded by the cycle counter. This refers to the operating clock frequency of the hardware acceleration device.

[0035] Specifically, by dividing the total number of cycles in the cycle counter register by the hardware clock frequency, the hardware execution time of a single signature operation can be obtained, enabling the processing system to directly obtain the time performance indicators of the signature operation, which facilitates performance comparison with software implementations or other hardware solutions.

[0036] In one embodiment, both the profile counter register group and the cycle counter register are connected to the external processing system via a storage mapping interface, allowing the processing system to read the count data.

[0037] Specifically, such as Figure 5 As shown, Figure 5The profile count and control register group of this application is illustrated. The processing system can access the control register, status register, cycle count register, and profile count register via a memory-mapped interface. One implementation of the register group is shown in Table 1 below: Table 1

[0038] The processing system can easily read various profile counts and cycle counts through a unified storage mapping interface for result verification and performance analysis, without the need for additional debugging interfaces or software overhead.

[0039] In one embodiment, if a subsequent standard check determines a rejection and the norm rejection signal is also valid, the signature controller updates the joint rejection count in the profile count register group; if a subsequent standard check determines a rejection and the norm rejection signal is invalid, the signature controller updates the MakeHint rejection count in the profile count register group.

[0040] Specifically, the joint rejection count records the number of times norm rejection and subsequent MakeHint-related rejections occur simultaneously. This count only increases when subsequent standard checks determine a rejection and the norm rejection signal is valid; the MakeHint rejection count only increases when subsequent standard checks determine a rejection and the norm rejection signal is invalid. This can accurately distinguish the types of failure reasons for signature attempts, helping designers determine whether the bottleneck in signature retry stems from norm rejection or MakeHint-related rejections, providing data support for hardware optimization.

[0041] In one embodiment, the hardware acceleration device exchanges signature input data and signature output data with the external processing system through an input FIFO, an output FIFO, or a storage mapping window.

[0042] Specifically, the processing system writes signature input data, including the message to be signed and private key materials, to the hardware acceleration device through the input FIFO. After the hardware acceleration device completes the signing, it outputs the signature result to the processing system through the output FIFO or storage mapping window.

[0043] Data exchange via FIFO or storage mapping window can adapt to the data interface requirements of different processing systems, improving the versatility and integration flexibility of hardware acceleration devices.

[0044] In a specific FPGA board-level embodiment, the hardware acceleration side operates at approximately 166.7. MHz All 100 consecutive complete process tests passed the correctness and status checks. The average number of cycles for the complete hardware process is approximately 54,524.1 cycles, corresponding to approximately 327.1 cycles. μs The dynamic power consumption is estimated to be approximately 4.2 kW. WIf the energy-delay product is used as an auxiliary evaluation metric, it can be calculated using the following formula: EDP ​​= P_dyn × T_total² in, P_dyn Dynamic power consumption, measured in watts (W). W ); T_total The complete hardware time is expressed in microseconds. μs The unit of EDP is... W·μs² .

[0045] The main hardware results of this embodiment are shown in Table 2 below: Table 2

[0046] The experimental data above demonstrates that, in this embodiment, signature retries are primarily caused by norm rejection. This application optimizes the process after the standard norm rejection determination has been established, reducing unnecessary hardware computations in common rejection paths. Each rejected retrieval saves approximately 296 cycles, without altering the ML-DSA signature acceptance rules. The above embodiments are merely illustrative of the implementability of this application and do not constitute a limitation on the scope of protection of this application. This application is also applicable to other security levels, other clock frequencies, other hardware platforms, or equivalent lattice-based signature hardware implementations.

[0047] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0048] In one embodiment, such as Figure 2 As shown, a hardware acceleration system for ML-DSA signature based on norm rejection is provided, including: a signature controller, a sampling and polynomial operation module, a norm checking module, a MakeHint module, a retry control module, and a parsing counter register group; The signature controller is used to control the state transitions and updates of the counter register for ML-DSA signature attempts; The sampling and polynomial operation module is used to generate the polynomial or vector intermediates required for signature attempts and output them to the norm checking module; The norm checking module is used to verify the received intermediate quantity according to the norm determination rules specified in the ML-DSA standard, generate a norm rejection signal and output it to the signature controller and retry control module. The retry control module is used to send a bypass control signal to the signature controller when the norm rejection signal indicates that the current signature attempt will inevitably be rejected, so that the signature controller bypasses the calculation path of the MakeHint module and jumps to the next signature attempt; The MakeHint module is used to receive the start signal from the signature controller and perform the corresponding calculation when the norm rejection signal does not indicate that the current signature attempt will necessarily be rejected. The profile counter register group is used to record the number of signature attempts and the corresponding count values ​​for various rejection reasons.

[0049] In one embodiment, the profile count register set includes a signature attempt count register, a norm rejection count register, a MakeHint rejection count register, a combined rejection count register, and a most recent rejection flag register. The hardware acceleration system also includes a cycle count register, a status register, an error register, an input count register, and an output count register.

[0050] In one embodiment, the ML-KEM acceleration peripheral on the hardware acceleration side supports KeyGen, Enc, and Dec operations, and the ML-DSA signature hardware acceleration system supports ML-DSAKeyGen, Sign, and Verify operations. The hardware acceleration side retains at least a portion of the key, ciphertext, shared secret, intermediate signature states, operation states, or cycle count information between multiple cryptographic operation stages. The hardware acceleration side is implemented in an FPGA, ASIC, SoC programmable logic, or cryptographic coprocessor.

[0051] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0052] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0053] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A hardware acceleration method for ML-DSA signature based on norm rejection, characterized in that, The method is executed based on a hardware acceleration device comprising a signature controller, a sampling and polynomial operation module, a norm checking module, a MakeHint module, a retry control module, and a profile counter register group, including: The signature controller receives a signature start command from an external input and performs initialization operations on the signature attempt count, norm rejection count, MakeHint rejection count, joint rejection count, and most recent rejection flag in the parsing count register group; The sampling and polynomial operation module performs sampling and polynomial operation processing for a single signature attempt, generates an intermediate quantity for norm checking, and transmits the intermediate quantity to the norm checking module. The norm checking module verifies the received intermediate quantity according to the norm determination rules specified in the ML-DSA standard, generates a norm rejection signal, and outputs the norm rejection signal to the signature controller and retry control module. If the norm rejection signal indicates that the current signature attempt will inevitably be rejected, the signature controller updates the norm rejection count and the most recent rejection flag in the parsing count register group, and bypasses the calculation path of the MakeHint module through the retry control module, jumps to the signature retry entry to start the next signature attempt; If the norm rejection signal does not indicate that the current signature attempt will necessarily be rejected, the signature controller starts the MakeHint module to perform the corresponding calculation. After the calculation is completed, the subsequent standard check is performed. If the subsequent standard check determines that it is a rejection, the corresponding rejection count in the profile count register group is updated and the next signature attempt is started. If the subsequent standard check determines that it is a pass, the final signature result is output.

2. The method of claim 1, wherein, The norm rejection determination process of the norm checking module is generated after the hardware state for calculating or checking w0-cs2 is completed; the retry control module only performs the bypass operation of the calculation path of the MakeHint module after the norm rejection determination is completed.

3. The method of claim 1, wherein, When the norm rejection signal indicates that the current signature attempt will inevitably be rejected, the signature controller controls the MakeHint module to remain in a reset state or maintain the current local state, without starting a new computation operation.

4. The method of claim 1, wherein, When the norm rejection signal does not indicate that the current signature attempt will necessarily be rejected, the signature controller keeps the original MakeHint module calculation path and subsequent signature check path unchanged, and performs calculation and check according to the ML-DSA standard process.

5. The method of claim 1, wherein, The hardware acceleration device also includes a cycle counter; when the signature operation is initiated, the signature controller triggers the cycle counter to start counting, and when the signature operation is completed, the cycle counter is triggered to stop counting. The total number of cycles recorded by the cycle counter is stored in the corresponding cycle count register.

6. The method of claim 5, wherein, The total number of cycles in the cycle counter register is converted into hardware operation time using a preset formula, which is: wherein, is the hardware operation time for a single signature operation, is the total number of cycles recorded by the cycle counter, is the operating clock frequency of the hardware acceleration device.

7. The method of claim 5, wherein, Both the analysis count register group and the period count register are connected to the external processing system via a storage mapping interface, allowing the processing system to read the count data.

8. The method of claim 1, wherein, The method further includes: If the subsequent standard check determines a rejection and the norm rejection signal is also valid, the signature controller updates the joint rejection count in the profile count register group; if the subsequent standard check determines a rejection and the norm rejection signal is invalid, the signature controller updates the MakeHint rejection count in the profile count register group.

9. The method according to claim 1, characterized in that, The hardware acceleration device exchanges signature input data and signature output data with the external processing system through an input FIFO, an output FIFO, or a storage mapping window.

10. A hardware acceleration system for ML-DSA signatures based on norm rejection, characterized in that, The system includes a signature controller, a sampling and polynomial operation module, a norm checking module, a MakeHint module, a retry control module, and a profile counter register group; The signature controller is used to control the state transitions of ML-DSA signature attempts and the updates of the counter register; The sampling and polynomial operation module is used to generate the polynomial or vector intermediate quantities required for the signature attempt and output them to the norm checking module; The norm checking module is used to verify the received intermediate quantity according to the norm determination rules specified in the ML-DSA standard, generate a norm rejection signal and output it to the signature controller and retry control module. The retry control module is used to send a bypass control signal to the signature controller when the norm rejection signal indicates that the current signature attempt will inevitably be rejected, so that the signature controller bypasses the calculation path of the MakeHint module and jumps to the next signature attempt. The MakeHint module is used to receive the start signal from the signature controller and perform the corresponding calculation when the norm rejection signal does not indicate that the current signature attempt will necessarily be rejected. The profile count register group is used to record the number of signature attempts and the count values ​​corresponding to various rejection reasons.

Images