Optimized algorithm of number theory transform for ml-kem standard and its fully asynchronous micro-architecture

Abstract

This invention belongs to the field of encryption and decryption technology, and discloses an optimized number-theory transformation algorithm for the ML-KEM standard. It includes parallel execution of four butterfly operations within the ML-KEM standard's number-theory transformation algorithm, storing four data points from each group of consecutive addresses in the same row of a memory block to reduce the number of data reads and writes, decreasing the total number of loops from 896 to 224. The modulo reduction stage of the butterfly operation uses the Shoup reduction algorithm. An IsNTT flag is added to ensure compatibility between forward and inverse number-theory transformations within the same butterfly unit. This invention also discloses a fully asynchronous microarchitecture for implementing the above algorithm. It employs an asynchronous micropipeline design to build a three-stage pipeline structure, divided into "read data - butterfly operation - write data" stages. This achieves full overlap between the read data, butterfly operation, and write data processes, solving the data throughput bottleneck, significantly improving computational efficiency, and greatly reducing data read / write redundancy.

Description

Technical Field

[0001] This invention belongs to the field of encryption and decryption operation technology, and specifically relates to a number theory transformation optimization algorithm for the ML-KEM standard and its fully asynchronous microarchitecture. Background Technology

[0002] As a core support for information security, cryptography uses mathematical methods to convert plaintext into ciphertext, ensuring the security, confidentiality, and integrity of information transmission and storage. Cryptography is a key component of information infrastructure in the era of big data and has become a research hotspot in both academia and industry, with its theoretical framework and application technologies continuously iterating and upgrading. Cryptographic algorithms can be categorized into symmetric and asymmetric encryption algorithms based on the characteristics of key usage. Among these, the Advanced Encryption Standard (AES) and Elliptic Curve Cryptography (ECC) have been used in the field of information security for many years, forming the core protection system of traditional information security.

[0003] However, the rapid development of quantum computers poses a disruptive threat to traditional cryptographic algorithms. With their superior processing power, quantum computers can significantly reduce the time required to break traditional cryptographic algorithms based on integer factorization or discrete logarithm problems, directly impacting the security foundation of data communication. Although general-purpose quantum computers are not yet mature, there is a consensus to proactively research post-quantum cryptography (PQC). The core objective of PQC is to resist attacks from both quantum and classical computing. Its security relies on the mathematical difficulties underlying the algorithm, rather than its implementation method, ensuring that even with the advent of practical quantum computers, it cannot be broken in polynomial time.

[0004] In August 2024, the National Institute of Standards and Technology (NIST) officially released the first official standard for post-quantum cryptography algorithms, ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism Standard), marking the entry of post-quantum cryptography algorithms into the standardized application stage. Polynomial multiplication is the core computational module of the ML-KEM standard, and number theory transformation algorithms are key technologies for improving the computational efficiency of polynomial multiplication, greatly affecting the overall performance of lattice cryptography algorithms. Currently, the main modular reduction algorithms in number theory transformations include Barrett reduction, Shoup reduction, and Montgomery reduction, with Barrett reduction becoming the mainstream choice due to its wide applicability.

[0005] Number theory transformations, as a core supporting technology of the ML-KEM standard, directly impact the practical application of post-quantum cryptography systems due to their computational efficiency and resource consumption. However, existing number theory transformation implementations suffer from significant performance bottlenecks, failing to meet the application requirements of low power consumption, high performance, and high security. Therefore, there is an urgent need to improve their overall performance through architectural optimization and algorithm improvements. Existing technologies have the following shortcomings:

[0006] 1. Low computational efficiency and redundant data read / write operations. The number-theoretic transformation algorithm in the ML-KEM standard includes seven large loops, each requiring 128 butterfly operations. In traditional serial implementations, this results in up to 896 loop iterations, leading to significant computational latency. Furthermore, the algorithm is not fully optimized for hardware storage mechanisms and does not consider the correlation between data from multiple butterfly operations. Multiple butterfly operations with related data addresses still require multiple separate data reads and writes, further reducing computational efficiency.

[0007] 2. High power consumption and insufficient security. Existing number theory transformation implementations mostly employ synchronous circuit designs. As the circuit size increases, the complexity of the clock network surges, not only occupying a large amount of hardware area but also leading to a significant increase in power consumption, making them unsuitable for low-power applications. The clock signal of the synchronous circuit also provides a usable clock reference for side-channel attacks, reducing system security.

[0008] 3. Modular reduction algorithms have poor adaptability and low resource utilization. Although the current mainstream Barrett reduction algorithm has strong versatility, in the specific scenario where the modulus q and parameter zeta are fixed in the ML-KEM standard, its algorithm structure has redundant design, resulting in a large area footprint and limited computing speed in hardware implementation. It cannot fully utilize hardware resources and has not achieved the optimal balance between area and performance. Summary of the Invention

[0009] One objective of this invention is to provide a number theory transformation optimization algorithm for the ML-KEM standard, comprising the following steps: performing four butterfly operations in parallel within the number theory transformation algorithm of the ML-KEM standard, storing four data from each group of consecutive addresses in the same row of a memory block to reduce the number of data read / write operations, thereby reducing the total number of loops from 896 to 224; employing the Shoup reduction algorithm for the modulo reduction stage of the butterfly operations; and adding a flag bit (IsNTT) to support both forward and inverse number theory transformations within the same butterfly unit.

[0010] Furthermore, the parallel execution of four butterfly operations and the storage of four data points from each group of consecutive addresses in the same row of the storage block are based on the following data address distribution pattern in number theory transformations:

[0011] When len≥4, len mod 4 = 0, j mod 4 = 0, and the 8 data addresses of 4 consecutive butterfly operations are (j+0) - (j+0)+len, (j+1) - (j+1)+len, (j+2) - (j+2)+len, and (j+3) - (j+3)+len;

[0012] When len=2, the 8 data addresses of 4 consecutive butterfly operations are (j+0) - (j+2), (j+1) - (j+3), (j+4) - (j+6), (j+5) - (j+7);

[0013] Regardless of the value of the outer loop length len of the number theory transformation, the 8 data required for 4 consecutive butterfly units can be divided into 2 groups, and the addresses of the 4 data in each group are consecutive.

[0014] Furthermore, the Shoup reduction algorithm requires two parameters, zeta and zetaPre. Zeta is provided in the ML-KEM standard, while zetaPre needs to be pre-calculated and stored. During number theory transformations, it can be directly called similarly to zeta, reducing real-time computation latency. The formula for calculating zetaPre is as follows:

[0015]

[0016] Where q represents the module in ML-KEM, with a value of 3329; k represents the bit width constant determined based on the module, which can be calculated to be 13; β is a calculation auxiliary constant, which can be calculated to be 8192; This indicates the floor operation, which takes the largest integer not greater than itself. This indicates the floor operation, which takes the smallest integer not less than itself.

[0017] Furthermore, when the flag bit (IsNTT) = 1, a positive number theory transformation is performed, and the data path is modular multiplication → modular addition + modular subtraction;

[0018] When the flag bit (IsNTT) is 0, the inverse number theory transformation is performed, and the data path is modular addition + modular subtraction → modular multiplication.

[0019] Another object of the present invention is to provide a fully asynchronous microarchitecture for implementing the above-mentioned number theory transformation optimization algorithm for the ML-KEM standard. The fully asynchronous microarchitecture employs an asynchronous micropipeline design method to build a three-stage pipeline structure, divided into "read data - butterfly operation - write data" stages. The asynchronous micropipeline includes the following asynchronous components:

[0020] Fifo: After receiving the request signal i_drive from the previous level, it generates a fire pulse signal to trigger the assignment of the register; at the same time, it generates an acknowledgment signal o_free to send to the previous level component, and generates a request signal o_drive to the next level component.

[0021] Merge: Responsible for receiving multiple events and their bound data, and combining them into one output; Merge includes MutexMerge, whose input multiple events are mutually exclusive, that is, only one event arrives at a time;

[0022] Splitter: Distributes one input event and data into multiple outputs, thereby enabling the simultaneous triggering of multiple parallel control paths;

[0023] Selector: Based on the valid signal in the input data, select one port from multiple output ports to output the event and corresponding data;

[0024] The Fifo and Selector components must meet the following condition: the components will only be activated to perform event and data transmission when the next level's response signal i_free has arrived and the previous level's request signal i_drive has arrived again.

[0025] Furthermore, the three-stage production line includes:

[0026] The first-level pipeline consists of asynchronous components including Fifo, MutexMerge, Splitter, and Selector. After the request event is merged by MutexMerge0, cFifo1 is started to update the len, start, i, and j parameters according to the event source and flag bit (IsNTT). Then, MutexMerge1 triggers the update of the read address, and after a delay, cFifo2 is started to read the stored data.

[0027] The second-level pipeline consists of asynchronous components including Fifo, MutexMerge, and Selector. The first-level event triggers cFifo3 to generate a fire signal to temporarily store data, address, and length. After a delay, the Selector selects the path. If it is the butterfly operation of the last loop of the number theory transformation, the lower event is generated. Otherwise, the upper event is generated. The two types of events are merged by MutexMerge to generate one event.

[0028] The third-level pipeline, with asynchronous components including Fifo, MutexMerge, and Selector, triggers an event in the second level. This event triggers cFifo4 to generate a fire signal, temporarily storing the data to be written and its corresponding write address. MutexMerge then updates the write address, write data, cycle flag r_flag_cycle, and counter count_9. After a delay, cFifo5 starts writing to memory. The write operation requires two cycles, and count_9 is updated only once. The cFifo event triggers the Selector to choose a path based on conditions.

[0029] When r_flag_cycle=0, the event is triggered again by MutexMerge to write to memory, and r_flag_cycle is updated to 1.

[0030] When r_flag_cycle=1, if it is not the last cycle of the number-theoretical transformation, the event is swallowed; if it is the last cycle, an output event is generated, indicating that the entire number-theoretical transformation has been completed.

[0031] Furthermore, in the first-level pipeline, the parallel four butterfly operations require reading two sets of data, which requires two loops. cFifo2 will trigger the temporary storage of one set of data (f_data_12mul8[47:0], zeta_12mul2[11:0], zetaPre_13mul2[12:0]), and start the Selector to choose a path based on the conditions:

[0032] If it is the first read event, the first feedback event is generated and then the MutexMerge is triggered to read the storage again;

[0033] If it is the second read event, a second event is generated to start the Splitter. The Splitter generates two events. One event triggers the second-level pipeline, and the other event enters the Selector. Based on the valid signal determined by comparing the current values ​​of len, start, and j with the expected next update value, the Selector selects the path to generate a feedback event to continue the loop read and store, or swallows the event in the last loop of the number theory transformation.

[0034] The present invention has the following beneficial effects:

[0035] The number theory transformation optimization algorithm for the ML-KEM standard provided by this invention addresses the problems of existing ML-KEM standards, which use serial implementation, resulting in 896 executions, lack of data read / write correlation optimization, and high computational latency. This invention improves upon these issues by combining a storage design of "four data items per row" with four parallel butterfly operations, significantly reducing the total number of loops from 896 to 224. Furthermore, this invention achieves full overlap between the data read, butterfly operation, and data write processes through a three-stage pipeline architecture, further resolving the data throughput bottleneck. Compared to existing technologies, the computational throughput is increased by approximately 7 times, significantly improving computational efficiency and greatly reducing data read / write redundancy.

[0036] The fully asynchronous microarchitecture provided by this invention offers strong security and low power consumption. Existing synchronous circuit designs suffer from high power consumption, large area footprint, and vulnerability to side-channel attacks due to high clock network complexity. This invention employs a fully asynchronous circuit microarchitecture, completely eliminating the global clock signal and controlling data flow through a handshake protocol. Its non-periodic characteristics effectively resist side-channel attacks such as clock-referenced energy analysis and electromagnetic analysis attacks. Furthermore, the asynchronous circuit flips only when data processing is required, exhibiting on-demand activation and no static clock flipping power consumption, significantly reducing overall power consumption.

[0037] This invention compares the Barrett, Shoup, and Montgomery algorithms and selects the Shoup reduction algorithm, which is specifically designed for scenarios where "one number in both the modular q and modular multiplication is fixed," thus improving resource utilization and performance. For the single modular multiplication operation involved in this invention, the Shoup reduction algorithm simplifies the modular operation through pre-calculated parameters, achieving a performance improvement of approximately 25% in computation latency (9 ns) compared to the Montgomery reduction algorithm (12 ns) and approximately 33% compared to the Barrett reduction algorithm (13.5 ns). Attached Figure Description

[0038] Figure 1 This is a diagram of the overall architecture of number theory transformation provided in an embodiment of the present invention.

[0039] Figure 2 This is a schematic diagram of the butterfly unit that is compatible with forward and inverse transformations of Algorithm 5 provided in the embodiments of the present invention.

[0040] Figure 3 This is a circuit structure diagram of the asynchronous component provided in an embodiment of the present invention.

[0041] Figure 4 This is a reference code diagram provided by an embodiment of the present invention for updating len, start, j, and i based on the source of the MutexMerge event.

[0042] Figure 5 This is a reference code diagram provided in an embodiment of the present invention for determining a valid signal based on a comparison between the current value and the expected value.

[0043] Figure 6 This is a fully asynchronous microarchitecture diagram provided in an embodiment of the present invention.

[0044] Figure 7 This is a diagram of the number-theoretic positive transform algorithm in the ML-KEM standard provided in this embodiment of the invention.

[0045] Figure 8 This is a diagram of the number-theoretic inverse transform algorithm in the ML-KEM standard provided in this embodiment of the invention.

[0046] Figure 9 This is a diagram of the butterfly operation algorithm based on the Shoup reduction algorithm corresponding to the number theory positive transformation provided in the embodiments of the present invention.

[0047] Figure 10 This is a diagram of the butterfly operation algorithm based on the Shoup reduction algorithm corresponding to the inverse number theory transform provided in this embodiment of the invention.

[0048] Figure 11 This is a diagram of a butterfly unit algorithm that supports both forward and inverse transformations, provided in an embodiment of the present invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0050] ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism Standard) is hereinafter referred to as the "ML-KEM standard".

[0051] The number-theoretic transform (NTT) is a type of forward transform. The number-theoretic inverse transform (NTT) is a type of inverse transform. -1 )".

[0052] The number-theoretic forward and inverse transform algorithms provided in the ML-KEM standard are as follows: Figure 7 The algorithm shown [1] and Figure 8 The algorithm shown is [2]. Whether it's the forward transform (NTT) or the inverse transform (NTT)... -1When implemented serially, it requires 7 × 128 = 896 loop operations (where len is the outer loop variable, which is executed 7 times; start and j together form the inner loop, which requires 128 butterfly operations), resulting in significantly low computational efficiency. Furthermore, algorithms [1] and [2] do not adequately consider the data address relationships between adjacent butterfly operation units, further limiting the performance improvement potential during hardware implementation.

[0053] This invention discloses a number theory transformation optimization algorithm for the ML-KEM standard. Through in-depth analysis of the original algorithm's operational logic and data address characteristics, an optimization scheme of parallel four butterfly operations is proposed. The specific data address distribution pattern is as follows:

[0054] When len≥4, len mod 4 = 0, j mod 4 = 0, and the 8 data addresses of 4 consecutive butterfly operations are (j+0) - (j+0)+len, (j+1) - (j+1)+len, (j+2) - (j+2)+len, and (j+3) - (j+3)+len;

[0055] When len=2, the addresses of the 8 data points of the 4 consecutive butterfly operations are (j+0) - (j+2), (j+1) - (j+3), (j+4) - (j+6), (j+5) - (j+7).

[0056] As can be seen from the above pattern (the specific data address distribution is shown in Table 1): regardless of the value of len, the 8 data required for 4 consecutive butterfly units can be divided into 2 groups, and the 4 data addresses in each group are continuous. Based on this characteristic, the 4 data from each group of consecutive addresses can be stored in the same row of the storage block, realizing the operation of "reading and writing 4 data at once", which greatly reduces the number of data read and write operations; at the same time, the overall number of loops is reduced from 896 times to 7×32=224 times, and both data read and write efficiency and computational efficiency are significantly improved.

[0057] To verify the optimality of "parallel four butterfly operations", this invention analyzes the feasibility of other parallel schemes:

[0058] Parallel butterfly operations: Although the four data to be read and written can be divided into two groups (two data in each group are stored in the same row), which can speed up the read and write efficiency to a certain extent, the overall number of loops is still as high as 7×64=448 times, which cannot meet the high performance requirements.

[0059] Parallelizing 8 butterfly operations requires reading and writing 16 data points (which can be divided into 2 groups of 8 data points each, stored in the same row). While this reduces the loop count to 7 × 16 = 112 times, it presents two major problems: First, when len ≤ 4, the control logic becomes significantly more complex, increasing the difficulty of hardware design. Specifically, compared to parallelizing 2 butterfly operations, the number of parameters zeta that need to be read in a single butterfly operation increases from a maximum of 2 to a maximum of 4, making the address update logic more complex. Second, butterfly operations require strict matching between the input address j and the data at j + len. When len equals 4 or 2, the two matching data points are stored in the same location. The data from the previous eight reads is very close together, causing it to be mixed in with the other eight data points. This prevents the hardware from directly extracting and using the data, requiring an additional complex set of data adjustment and rearrangement logic to send the correct data to the processing unit. Furthermore, the result of the operation also needs to be adjusted in reverse before being written back to storage. This significantly increases the design complexity and chip area. Although parallel four butterfly operations also require data adjustment when len equals 2, the level of mixing is low, and the processing logic is relatively simple. Secondly, eight butterfly operation units require more hardware resources, and the ML-KEM implementation includes multiple number theory transformation modules, leading to a multiple increase in overall resource consumption. More importantly, number theory transformation is only one of the key steps in the ML-KEM standard. When ML-KEM is implemented using a pipeline, the overall performance bottleneck depends on the "worst-case pipeline." Simply improving the performance of number theory transformation alone cannot improve the overall system performance.

[0060] Parallel 2n butterfly operations (7≥n≥4, requiring 2×2n data to be read and written): The problems of this type of scheme are similar to those of "parallel 8 butterfly operations", both of which have complex control logic and excessive resource consumption, which will not be elaborated here.

[0061] In summary, the scheme of parallelizing four butterfly operations achieves the optimal balance among "hardware resource consumption", "computational performance" and "implementation complexity", and is the optimal parallel strategy for adapting to the ML-KEM standard number theory transformation.

[0062] Table 1. Eight data addresses corresponding to four consecutive butterfly operations.

[0063]

[0064] In the table, different background colors of the data addresses represent different groups, with the 8 data addresses divided into 2 groups.

[0065] In the modulus reduction stage of the butterfly unit, considering the fixed modulus q and parameter zeta in the ML-KEM standard, this invention compares and analyzes three mainstream modulus reduction algorithms: Barrett, Shoup, and Montgomery. Ultimately, it is decided to replace the traditional Barrett reduction algorithm with the Shoup reduction algorithm to reduce redundant design, improve hardware resource utilization, and achieve an optimal balance between resources and performance. The specific selection criteria are as follows:

[0066] The core application scenario of Barrett's reduction algorithm is modular multiplication with only the modulus q known. In scenarios where both the modulus q and one of the multipliers are fixed, the algorithm structure is redundant, and hardware implementation is prone to problems such as excessive area occupation and limited operation speed.

[0067] Shoup's reduction algorithm is an extended and optimized version of Barrett's reduction algorithm, specifically adapted to scenarios where "one of the numbers in the modulo q and the modulo multiplication is known". It is highly compatible with the parameter characteristics of the ML-KEM standard and can directly simplify redundant calculation steps.

[0068] While the Montgomery reduction algorithm is suitable for scenarios where "modulo q is known" and is highly efficient in a large number of loop operations with a small amount of data, number theory transformations require processing 256 different data points. The algorithm requires the data to first enter the Montgomery field, perform the operation, and then exit the Montgomery field. These two field transformations consume a lot of extra time, thus reducing the overall efficiency.

[0069] In addition to the theoretical analysis described above, this invention also conducted single-modular multiplication tests based on three modular reduction algorithms. In the experiments, Xilinx Vivado 2019.1 was used as the EDA tool, and xc7vx485tffg1157-1 was used as the hardware verification platform. The resource consumption and timing simulation results after synthesis are shown in Table 2. The experimental results show that the Shoup reduction algorithm performs optimally in terms of both hardware resource consumption and computational performance, making it the optimal modular reduction scheme for the butterfly unit of the ML-KEM standard number-theoretic transformation.

[0070] Table 2. Resource usage and timing simulation results after modular multiplication based on three modular reduction algorithms.

[0071]

[0072] In terms of performance: If a serial implementation is used, the number theory transformation requires 7 × 128 = 896 iterations. In this case, the Shoup reduction algorithm saves (13.5 - 9) × 896 = 4032 ns compared to the Barrett reduction algorithm, and (12 - 9) × 896 = 2688 ns compared to the Montgomery reduction algorithm. If the parallel optimization strategy proposed in this invention is used, it requires 7 × 32 = 224 iterations. The Shoup reduction algorithm saves (13.5 - 9) × 224 = 1008 ns compared to the Barrett reduction algorithm, and (12 - 9) × 224 = 672 ns compared to the Montgomery reduction algorithm (Note: The Montgomery reduction algorithm actually requires additional input and output operations; this is a rough quantitative analysis, and this time consumption is ignored). Experiments have shown that although the performance difference in a single modular multiplication operation is small, the algorithm scheme selected in this invention has significant advantages after a large number of iterative cycles in number theory transformations.

[0073] In terms of resources: If a serial implementation is adopted, the number-theoretic transformation circuit requires at least 3 modular multiplication units (1 butterfly unit and 2 units for the inverse transformation × 3303 mod q). In this case, the Shoup and Montgomery reduction algorithms save 3 DSP resources compared to the Barrett reduction algorithm. If the parallel optimization strategy proposed in this invention is adopted, at least 12 modular multiplication units are required (4 butterfly units and 8 units for the inverse transformation × 3303 mod q). The Shoup and Montgomery reduction algorithms save 12 DSP resources compared to the Barrett reduction algorithm. In actual chip design, circuits typically integrate multiple number-theoretic transformation modules, resulting in even greater resource savings over time.

[0074] The butterfly operations based on the Shoup reduction algorithm corresponding to the forward and inverse transformations in number theory are respectively (e.g.) Figure 9 Algorithm [3] and (shown) Figure 10 Algorithm [4] is shown. By decomposing the operational logic of the two algorithms, it is found that both the forward and inverse transformation butterfly operations include one modular multiplication, one modular addition, and one modular subtraction, with only the order of operations differing. Based on this characteristic, this invention adopts the design concept of a 'shared butterfly unit'. The shared butterfly unit integrates basic operator units such as modular addition, modular subtraction, and modular multiplication, and adds a 1-bit 'whether it is a forward transformation' flag (IsNTT). Specifically, the selection of the internal multiplexer is controlled by the level state of this flag (high level indicates forward transformation, low level indicates inverse transformation), thereby dynamically switching the data flow direction and connection order between the basic operator units. In this way, the same set of operator hardware can be compatible with and support different butterfly operation logics in number theory forward and inverse transformations, realizing a high degree of hardware resource reuse.

[0075] Flag (IsNTT) = 1 (NTT): The data path is "modular multiplication → modular addition + modular subtraction". First, zeta is multiplied by the input data (based on the Shoup reduction algorithm), and then the results are sent to the modular addition and modular subtraction modules for operation.

[0076] Flag (IsNTT) = 0 (NTT) -1 The data path is “modular addition + modular subtraction → modular multiplication”. First, the input data is processed by the modular addition and modular subtraction modules, and then the result is sent to the modular multiplication module to perform modular operation with zeta.

[0077] The Shoup reduction algorithm requires two parameters, zeta and zetaPre. Zeta is provided in the ML-KEM standard, while zetaPre needs to be pre-calculated and stored. During number-theoretic transformations, it can be directly called similarly to zeta, reducing real-time computation latency. The formula for calculating zetaPre is as follows:

[0078]

[0079] Where q represents the module in ML-KEM, with a value of 3329; k represents the bit width constant determined based on the module, which can be calculated to be 13; β is a calculation auxiliary constant, which can be calculated to be 8192; This indicates the floor operation, which takes the largest integer not greater than itself. This indicates the floor operation, which takes the smallest integer not less than itself.

[0080] The butterfly unit algorithm, which supports both forward and inverse transformations, is as follows: Figure 11 As shown in the figure, the algorithm [5] is implemented using pure combinational logic. The line numbers are for convenience only and do not represent the actual execution order. To more clearly show the differences in data flow, a schematic diagram is designed to accompany the algorithm [5], as shown in the figure. Figure 2 As shown in the figure, the solid lines correspond to the data transmission path during the forward number theory transformation (first modular multiplication, then modular addition and subtraction), and the dashed lines correspond to the data transmission path during the inverse number theory transformation (first modular addition and subtraction, then modular multiplication).

[0081] Further analysis ( Figure 7 Algorithm [1] and (shown) Figure 8As shown in the algorithm [2], the overall logical framework of the forward and inverse number theory transformations is basically the same, and the butterfly unit is shared by "adjusting the data flow by the flag bit". Therefore, this invention merges the control logic and operation flow of the forward and inverse number theory transformations, adopts the compatible butterfly unit described in the algorithm [5], and combines it with the "parallel operation of 4 butterfly operations" strategy proposed above, and finally forms the number theory transformation optimization algorithm of this invention for the ML-KEM standard as shown in Table 3, that is, the integrated algorithm that supports both forward and inverse number theory transformations.

[0082] Table 3. Number Theory Transformation Optimization Algorithm for ML-KEM Standard

[0083]

[0084] The core execution steps of this number-theoretic transformation optimization algorithm for the ML-KEM standard are as follows:

[0085] 1. Initialization (steps 1-3): First, the input array is assigned to the copy. Subsequent operations are performed on the copy. The variables are initialized according to the state of the IsNTT flag (1 indicates forward transformation, 0 indicates inverse transformation).

[0086] When IsNTT=1, the index i is initially 1, and the outer loop length len is initially 128;

[0087] When IsNTT=0, the initial value of i is 127 and the initial value of len is 2.

[0088] 2. Outer loop control (step 4): The termination condition of the outer loop is dynamically adjusted according to the IsNTT state to meet the computation round requirements of the ML-KEM standard;

[0089] When IsNTT=1, len decreases to a value not less than 2; otherwise, it increases to a value not greater than 128. If len exceeds the range, jump to step 37 and return the result array, indicating that the number theory transformation is complete.

[0090] 3. Inner loop 0 control (step 5): Check if the variable start is less than 256. If it exceeds the range (greater than or equal to 256), exit the inner loop 0 to step 35, update the variable len and start a new round of the outer loop.

[0091] 4. Parameter Pre-calculation and Update (Steps 6-10): Update parameters zeta0, zeta1, zetaPre0, and zetaPre1 based on the current len, and update variable i simultaneously. Zeta is provided in the ML-KEM standard; the calculation formula for zetaPre is as follows. Except for i, all other parameters are known parameters:

[0092]

[0093] Where q represents the module in ML-KEM, with a value of 3329; k represents the bit width constant determined based on the module, which can be calculated to be 13; β is a calculation auxiliary constant, which can be calculated to be 8192; This indicates the floor operation, which takes the largest integer not greater than itself. This indicates the floor operation, which rounds up to the smallest integer not less than itself.

[0094] When len! = 2, zeta0 = zeta1, zetaPre0 = zetaPre1 (the value of i is the same when calculating zeta0 and zeta1).

[0095] When len=2, if zeta0 is calculated using i, then zeta1 is calculated using i+1. In this case, zeta0 != zeta1, and zetaPre0 != zetaPre1. Note that zeta and zetaPre can also be pre-calculated and stored, and read directly through address index during operation (synchronized with steps 12-13) to further reduce real-time calculation latency. Then, update the variable i: when len=2, i=i+2; otherwise, i=i+1.

[0096] 5. Inner loop 1 control (step 11): Check if variable j is less than start + len. If it is outside the range (greater than or equal to start + len), jump to step 33 to update variable start, and then enter the next round of inner loop 0.

[0097] 6. Read storage (steps 12-13): Continuing the storage design of "4 data items stored in the same row of the storage block", the 8 data items to be read are divided into two groups and read in two loops.

[0098] 7. Parallel Butterfly Operation (Steps 14-25): The butterfly operation requires that the data at input address j and j+len be strictly matched. When len=2, the data address distribution has special characteristics (as shown in Table 1). The two matching data are too close to each other in the storage location and will be mixed in the same group of 4 data to be read, so that the hardware cannot directly extract and use them. Therefore, the data selector is controlled according to the current len ​​value to rearrange the data to adapt to the input requirements of the 4 butterfly units (Steps 14-17). The data is then sent to the butterfly unit for parallel operation (Steps 18-21). Finally, the output data format of the butterfly unit is adjusted to adapt to the write storage logic (Steps 22-25).

[0099] 8. Correction of inverse transformation results (steps 26-30): In the last outer loop of the inverse number theory transformation, perform the operation "×3303 mod q" on the operation result of the butterfly unit.

[0100] 9. Write to storage (step 31): Write the calculation results back to the storage block in two loops.

[0101] 10. End of inner loop 1 (step 32): Jump back to inner loop 1 control (step 11).

[0102] 11. Inner loop 0 variable update (step 33): Update start according to the current len. When len=2, start=start+4×len; otherwise, start=start+2×len.

[0103] 12. End of inner loop 0 (step 34): Jump back to inner loop 0 control (step 5).

[0104] 13. Outer loop variable update (step 35): Update len according to the IsNTT state:

[0105] When IsNTT=1, len=len / 2;

[0106] When IsNTT=0, len=2×len.

[0107] 14. One outer loop cycle ends (step 36): Jump back to outer loop control (step 4).

[0108] 15. The outer loop ends, the number theory transformation is completed, and the calculation result array is returned (step 37).

[0109] Based on the number-theoretic transformation optimization algorithm for the ML-KEM standard described above, this invention also discloses a fully asynchronous microarchitecture, such as... Figure 6 As shown, a three-stage pipeline structure is adopted, consisting of three parts: "read data - butterfly operation - write data". It is compatible with number theory forward and inverse transformations, supports the "parallel four butterfly operations" strategy, and the butterfly unit adopts the Shoup reduction algorithm.

[0110] First, it's necessary to clarify the asynchronous components used in the asynchronous micropipeline design. These components are all based on the "Sender-Relay-Receiver" model, including FIFO, Merge, Splitter, and Selector components (such as...). Figure 3 (As shown). These components consist of one or more of Sender, Relay, ConTap, and Receiver. Sender, Receiver, and ConTap are as follows: Figure 3 The section shown in the dashed box consists of triggers that toggle the level upon receiving a pulse signal. The Relay is actually a Click asynchronous controller; the specific circuit details of the Click asynchronous controller are as follows... Figure 3As shown in the upper left corner, it consists of an XOR gate, a NAND gate, an AND gate, a flip-flop, and a delay unit.

[0111] Fifo (basic component): After receiving the request signal i_drive from the previous level, it generates a fire pulse signal to trigger the assignment of the register; at the same time, it generates an acknowledgment signal o_free to send to the previous level component and a request signal o_drive to the next level component.

[0112] Merge (fusion component): Responsible for receiving multiple events and their bound data, and combining them into a single output. MutexMerge is one type, where the multiple events at the input are mutually exclusive, meaning only one event arrives at a time.

[0113] Splitter: Distributes one input event and data into multiple outputs, thereby enabling the simultaneous triggering of multiple parallel control paths.

[0114] Selector (path selection component): Based on the valid signal in the input data, select one port from multiple output ports to output the event and corresponding data.

[0115] The Fifo and Selector components must satisfy the following condition: the component will only be activated to execute events and transmit data when the next level's response signal i_free has arrived and the previous level's request signal i_drive has arrived again. If the next level's response signal i_free has not arrived, the component will not be activated even if the previous level's request signal i_drive arrives again. This is the key to implementing pipelines for asynchronous components.

[0116] based on Figure 3 The asynchronous components shown in this invention complete the fully asynchronous microarchitecture design of number-theoretic transformations (such as...). Figure 6 As shown), this microarchitecture design is consistent with... Figure 1 The overall architecture diagram corresponds to this. (For simplicity, the diagram is omitted.) Figure 6The interface primarily contains only the request signal `i_drive`. The default response signal `free` is provided by the adjacent component. For `free` response signals provided by non-adjacent components, they are additionally marked with dashed lines and labels (as shown in dashed lines 1-4). It's important to note that number theory transformations involve multiple loops. During a number theory transformation, the initial data must remain unchanged. Only after the current number theory transformation is completed and the data is passed to the next module is the next data and event allowed to be sent to the number theory transformation module again. Therefore, the interface needs to temporarily store the initial data using a Fifo component, and the received response signal `free` (dashed line 1) originates from the next-level external module. Each level of the pipeline has a design similar to the interface section. At the beginning of the first-level pipeline, a Fifo component is set up to temporarily store data. The response signal `free` (dashed lines 2-4) received by this component always originates from the next-level pipeline. This design is used to implement asynchronous pipelines. Specifically, as shown... Figure 6 As shown:

[0117] First, the input event is sent to the interface section, triggering cFifo0 to generate a fire pulse signal, then triggering the D flip-flop to temporarily store the initial data, and at the same time generating a response signal to the previous level external module and a request signal to be sent to the first level pipeline.

[0118] The first-level pipeline consists of four asynchronous components: Fifo, MutexMerge, Splitter, and Selector. Within this pipeline, request events from the interface are merged by MutexMerge0 and then cFifo1 is started based on the event source (interface event or...). Figure 6 Internal feedback events (② / ③ / ④), and the forward and inverse transformation flags IsNTT update parameters such as len, start, i, j (e.g. Figure 4 (As shown). The event is then triggered by MutexMerge1 to update the read address, and after a certain delay, cFifo2 is started to read the storage (f_data_12mul4, zeta_12, zetaPre_13). Note that, as mentioned above, parallel butterfly operations require reading two sets of data, which requires two loops. Therefore, cFifo2 will trigger the temporary storage of one set of data (f_data_12mul8[47:0], zeta_12mul2[11:0], zetaPre_13mul2[12:0]), and start the Selector to choose the path based on the conditions:

[0119] If this is the first read event, then the first feedback event is generated. Figure 6 Event ①) triggers a second read from memory again via MutexMerge1;

[0120] If it is the second read event, a second event is generated to start the Splitter. The Splitter generates two events: one event triggers the second-level pipeline, and the other event enters the Selector to determine the valid signal based on the comparison of the current values ​​of len, start, and j with the expected next update value. Figure 5 The `w_validOfSelector4_2` method generates a feedback event during path selection. Figure 6 Events ② / ③ / ④ trigger MutexMerge0 to continue looping and reading the memory, or swallow the event during the last loop (the 224th iteration) of the number theory transformation.

[0121] The second-stage pipeline consists of three asynchronous components: Fifo, MutexMerge, and Selector. Events from the first stage trigger cFifo3 to generate a fire signal, temporarily storing the read data, address (passed to the third-stage pipeline for write storage), and len (used to adjust the input of the butterfly unit). Then, after a certain delay, the Selector initiates path selection: if it's the butterfly operation of the last loop in number theory transformations, the generated event enters the MutexMerge component after a certain delay; otherwise, the generated event directly enters the MutexMerge component. MutexMerge merges the events and generates a single event to trigger the third-stage pipeline. For example... Figure 6 As shown, the modules such as "adjust butterfly unit input", "BU_0-BU_3", "×3303 mod q", and "adjust butterfly unit output" in this pipeline are all pure combinational logic, and the delay between asynchronous components is adjusted according to the delay of these combinational logics.

[0122] The third-level pipeline consists of three asynchronous components: Fifo, MutexMerge, and Selector. This third-level pipeline is responsible for writing the computation results from the second-level pipeline to storage. Similar to the first-level read-to-storage operation, it also requires two write cycles. An event from the second level triggers cFifo4 to generate a fire signal, temporarily storing the data to be written and its corresponding write address. MutexMerge then triggers updates to the write address, write data, cycle flag r_flag_cycle, and counter count_9. After a certain delay, cFifo5 starts writing to storage. Note that while the write cycle is repeated twice, count_9 is only updated once (i.e., count_9+1 is executed once). Finally, cFifo5 generates an event to start the Selector, which selects a path based on conditions: if it's the first cycle of the current write operation (r_flag_cycle=0), a feedback event is generated (…). Figure 6Event ⑤) triggers a write-to-store again via MutexMerge, simultaneously updating r_flag_cycle to 1; when this is the second cycle of the write-to-store (r_flag_cycle=1), if the current cycle is not the last cycle of the number theory transformation (not the 224th cycle, i.e., count_9 != 223), then the event is swallowed. Figure 6 If the event occurs in the middle of the path, it indicates that the entire number theory transformation has been completed and an output event is generated.

[0123] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A number-theoretic transformation optimization algorithm for the ML-KEM standard, characterized in that, The process includes the following steps: performing four butterfly operations in parallel within the number theory transformation algorithm of the ML-KEM standard, storing the four data from each group of consecutive addresses in the same row of the memory block to reduce the number of data reads and writes, thus reducing the total number of loops from 896 to 224; using the Shoup reduction algorithm for the modulo reduction stage of the butterfly operation; and adding a flag bit (IsNTT) to support both forward and inverse number theory transformations within the same butterfly unit.

2. The number-theoretic transformation optimization algorithm for the ML-KEM standard as described in claim 1, characterized in that, The parallel execution of four butterfly operations, and the storage of four consecutive data points from each group of addresses in the same row of the memory block, is based on the following data address distribution pattern in number theory transformations: When len≥4, len mod 4 = 0, j mod 4 = 0, and the 8 data addresses of 4 consecutive butterfly operations are (j+0)-(j+0)+len, (j+1)-(j+1)+len, (j+2)-(j+2)+len, and (j+3)-(j+3)+len; When len=2, the 8 data addresses of 4 consecutive butterfly operations are (j+0) - (j+2), (j+1) - (j+3), (j+4) - (j+6), (j+5) - (j+7); Regardless of the value of the outer loop length len of the number theory transformation, the 8 data required for 4 consecutive butterfly units can be divided into 2 groups, and the addresses of the 4 data in each group are consecutive.

3. The number-theoretic transformation optimization algorithm for the ML-KEM standard as described in claim 2, characterized in that, The Shoup reduction algorithm requires two parameters, zeta and zetaPre. Zeta is provided in the ML-KEM standard, while zetaPre needs to be pre-calculated and stored. During number theory transformations, it can be called directly, similar to zeta, reducing real-time computation latency. The formula for calculating zetaPre is as follows: Where q represents the module in ML-KEM, with a value of 3329; k represents the bit width constant determined based on the module, which can be calculated to be 13; β is a calculation auxiliary constant, which can be calculated to be 8192; This indicates the floor function; This indicates the rounding up operation.

4. The number-theoretic transformation optimization algorithm for the ML-KEM standard as described in claim 2, characterized in that, When the flag bit (IsNTT) is 1, a positive number theory transformation is performed, and the data path is modular multiplication → modular addition + modular subtraction; When the flag bit (IsNTT) is 0, an inverse number theory transformation is performed, and the data path is modular addition + modular subtraction → modular multiplication.

5. A fully asynchronous microarchitecture for implementing the number-theoretic transformation optimization algorithm for the ML-KEM standard as described in any one of claims 1-4, characterized in that, The fully asynchronous microarchitecture employs an asynchronous micropipeline design method to build a three-stage pipeline structure, divided into "read data - butterfly operation - write data" three-stage pipeline. The asynchronous micropipeline includes the following asynchronous components: Fifo: After receiving the request signal i_drive from the previous level, it generates a fire pulse signal to trigger the assignment of the register; at the same time, it generates an acknowledgment signal o_free to send to the previous level component, and generates a request signal o_drive to the next level component. Merge: Responsible for receiving multiple events and their bound data, and combining them into one output; Merge includes MutexMerge, whose input multiple events are mutually exclusive, that is, only one event arrives at a time; Splitter: Distributes one input event and data into multiple outputs, thereby enabling the simultaneous triggering of multiple parallel control paths; Selector: Based on the valid signal in the input data, select one port from multiple output ports to output the event and corresponding data; The Fifo and Selector components must meet the following condition: the components will only be activated to perform event and data transmission when the next level's response signal i_free has arrived and the previous level's request signal i_drive has arrived again.

6. The fully asynchronous microarchitecture of the number-theoretic transformation optimization algorithm for the ML-KEM standard as described in claim 5, characterized in that, The three-stage production line includes: The first-level pipeline consists of asynchronous components including Fifo, MutexMerge, Splitter, and Selector. After the request event is merged by MutexMerge0, cFifo1 is started to update the len, start, i, and j parameters according to the event source and flag bit (IsNTT). Then, MutexMerge1 triggers the update of the read address, and after a delay, cFifo2 is started to read the stored data. The second-level pipeline consists of asynchronous components including Fifo, MutexMerge, and Selector. The first-level event triggers cFifo3 to generate a fire signal to temporarily store data, address, and length. After a delay, the Selector selects the path. If it is the butterfly operation of the last loop of the number theory transformation, the lower event is generated. In other cases, the upper event is generated. The two types of events are merged by MutexMerge to generate one event. The third-level pipeline, with asynchronous components including Fifo, MutexMerge, and Selector, triggers an event in the second level, causing cFifo4 to generate a fire signal. This temporarily stores the data to be written and its corresponding write address. MutexMerge then triggers updates the write address, write data, cycle flag r_flag_cycle, and counter count_9. After a delay, cFifo5 starts writing to memory. The write operation requires two cycles, and count_9 is updated only once. The cFifo event triggers the Selector to choose a path based on conditions. When r_flag_cycle=0, the event is triggered again by MutexMerge to write to memory, and r_flag_cycle is updated to 1. When r_flag_cycle=1, if it is not the last cycle of the number-theoretical transformation, the event is swallowed; if it is the last cycle, an output event is generated, indicating that the entire number-theoretical transformation has been completed.

7. The fully asynchronous microarchitecture of the number-theoretic transformation optimization algorithm for the ML-KEM standard as described in claim 6, characterized in that, In the first-level pipeline, the four parallel butterfly operations need to read two sets of data, requiring two loops. cFifo2 will trigger the temporary storage of one set of data (f_data_12mul8[47:0], zeta_12mul2[11:0], zetaPre_13mul2[12:0]), and start the Selector to choose a path based on the conditions: If it is the first read event, the first feedback event is generated and then the MutexMerge is triggered to read the storage again; If it is the second read event, a second event is generated to start the Splitter. The Splitter generates two events. One event triggers the second-level pipeline, and the other event enters the Selector. Based on the valid signal determined by comparing the current values ​​of len, start, and j with the expected next update value, the Selector selects the path to generate a feedback event to continue the loop read and store, or swallows the event in the last loop of the number theory transformation.

Images