Method and apparatus for scheduling execution of hash chains

Abstract

This application provides a method and apparatus for scheduling and executing hash chains. The method includes: when at least one target hash core completes a hash operation on a currently allocated hash chain, storing the hash value obtained from the hash operation into a hash result according to the chain index corresponding to the currently allocated hash chain; the chain index is used to determine the storage location of the hash value in the hash result; based on the updated value of the queue head pointer and the hash chain queue, continuing to allocate hash chains to at least one target hash core, and updating the updated value of the queue head pointer; the updated value of the queue head pointer represents the first hash chain to be allocated in the hash chain queue when the next hash chain allocation occurs; performing a hash operation on the newly allocated hash chain based on at least one target hash core, until all hash chains in the hash chain queue are allocated and hash operations are completed on all hash chains, and obtaining a hash result.

Description

Technical Field

[0001] This application relates to cryptographic techniques, and more particularly to a method and apparatus for scheduling and executing hash chains. Background Technology

[0002] The signing and verification processes of hash-based post-quantum signature algorithms involve iterative calculations of multiple hash chains. Since the hash chains are independent of each other and the calculation process has no data dependency, they are suitable for being distributed to multiple hash cores for parallel execution.

[0003] In related technologies, p hash chains are divided into several batches, with each batch containing N hash chains (N being the number of hash cores). Hash operations are initiated simultaneously, and the next batch is started only after all hash chains in that batch have been processed. Alternatively, the p hash chains are distributed among N hash cores, with each core handling p / N hash chains. However, these technologies suffer from low hardware utilization and long hash chain computation times. Summary of the Invention

[0004] This application provides a method and apparatus for scheduling and executing hash chains, which can improve hardware utilization and reduce hash chain computation time.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a method for scheduling and executing a hash chain, the method including: When at least one target hash kernel completes the hash operation on the currently assigned hash chain, the hash value obtained from the hash operation is stored in the hash result according to the chain index corresponding to the currently assigned hash chain; the chain index is used to determine the storage location of the hash value in the hash result. Based on the updated value of the queue head pointer and the hash chain queue, continue to allocate hash chains for at least one target hash core, and update the updated value of the queue head pointer; the updated value of the queue head pointer represents the first hash chain to be allocated in the hash chain queue when the hash chain is allocated next. Hash operations are performed on newly allocated hash chains based on at least one target hash kernel until all hash chains in the hash chain queue have been allocated and hash operations have been completed on all hash chains, at which point the hash result is obtained.

[0006] This application provides a hash chain scheduling and execution device, the device comprising: A storage unit is used to store the hash value obtained from the hash operation into the hash result according to the chain index corresponding to the currently allocated hash chain when at least one target hash kernel completes the hash operation on the currently allocated hash chain; the chain index is used to determine the storage location of the hash value in the hash result; The first processing unit is used to continue allocating hash chains for at least one target hash kernel based on the updated value of the queue head pointer and the hash chain queue, and to update the updated value of the queue head pointer; the updated value of the queue head pointer represents the first hash chain to be allocated in the hash chain queue when the hash chain is allocated next. A generation unit is used to perform hash operations on newly allocated hash chains based on at least one target hash kernel until all hash chains in the hash chain queue have been allocated and hash operations have been completed on all hash chains, and a hash result is obtained.

[0007] This application provides an electronic device, which includes: a memory for storing computer-executable instructions or computer programs; and a processor for executing the computer-executable instructions or computer programs stored in the memory to implement the hash chain scheduling and execution method provided in this application.

[0008] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the hash chain scheduling and execution method provided in this application when executed by a processor.

[0009] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the hash chain scheduling and execution method provided in this application.

[0010] The embodiments of this application have the following beneficial effects: When at least one target hash core completes the hash operation on the currently allocated hash chain, the hash value is stored in the hash result according to the storage location determined by the chain index corresponding to the currently allocated hash chain. In addition, since the updated value of the queue head pointer represents the first hash chain to be allocated in the next hash chain allocation, the hash chain can continue to be allocated to at least one target hash core based on the updated value of the queue head pointer and the hash chain queue, and the hash operation can be performed on the newly allocated hash chain based on at least one target hash core. The steps of storing hash value, allocating new hash chains, and performing hash operation on new hash chains are executed in a loop until all hash chains are allocated and the hash operation is completed on all hash chains, and the hash result is obtained. There is no need to wait for all hash chains in this batch to complete the hash operation before re-allocation, which can achieve the effect of allocation upon completion. Therefore, hardware utilization can be improved and the hash chain calculation time can be reduced. Attached Figure Description

[0011] Figure 1 This is an iterative diagram of a hash operation provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a hash chain scheduling and execution method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a product architecture provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the steps of the initialization and allocation phase proposed in an embodiment of this application; Figure 5 This is a flowchart illustrating the steps of a dynamic scheduling loop proposed in an embodiment of this application; Figure 6 This is a schematic diagram of the state transition of a hash kernel provided in an embodiment of this application; Figure 7 This is a schematic diagram of the concurrent execution timing of multiple hash cores provided in an embodiment of this application; Figure 8 This is a schematic diagram of a scheduler data structure provided in an embodiment of this application; Figure 9 This is a schematic diagram of a hash chain allocation and switching process provided in an embodiment of this application; Figure 10 This is a comparative schematic diagram of various scheduling methods provided in the embodiments of this application; Figure 11 This application provides a hash chain scheduling and execution device. Figure 12 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of the application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] In the following description, the terms "first," "second," and "third" are used only to distinguish different objects and do not represent a specific order of objects or have any chronological limitation. It is understood that "first," "second," and "third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0015] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0016] The following is an explanation of the non-common abbreviations or custom terms used in this application.

[0017] LMS: Leighton-Micali Signature, a hash-based stateful digital signature algorithm defined in RFC 8554.

[0018] LM-OTS: Leighton-Micali One-Time Signature, a one-time signature scheme used in the LMS algorithm. Each LMS leaf node corresponds to an LM-OTS key pair.

[0019] Merkle tree: A complete binary tree structure in which each leaf node stores the hash value of an LM-OTS public key, and is the core data structure of the LMS algorithm.

[0020] RFC 8554: A standard document published by the IETF that defines the complete specifications for the LMS and LM-OTS algorithms.

[0021] SP 800-208: A NIST recommendation that approves LMS (RFC 8554) and XMSS (RFC 8391) for digital signatures and adds a parameter set of n=24 (such as SHA-256 / 192 and SHAKE256 / 192 variants) to RFC 8554.

[0022] W: The Winternitz parameter, a core parameter of the LM-OTS algorithm, determines the number of hash chains and the maximum number of iterations per hash chain. RFC 8554 defines four possible values ​​for W: 1, 2, 4, and 8.

[0023] n: Hash output length (bytes), determining the byte length of each component of the private key / signature / public key. LM-OTS defines two values ​​for n: 32 (SHA-256) and n=24 (SHA-256 / 192, SHAKE256 / 192). In WOTS+, n is determined by the XMSS or SLH-DSA parameter set, and can be n=16, 24, or 32.

[0024] W1: The set of parameters in the LM-OTS algorithm where the Winternitz parameter is 1. For N32 (e.g., LMOTS_SHA256_N32_W1), p=265; for N24 (e.g., LMOTS_SHA256_N24_W1 or LMOTS_SHAKE_N24_W1), p=200. Each hash chain iterates a maximum of 1 time (2^1-1).

[0025] W2: The parameter set in the LM-OTS algorithm where the Winternitz parameter is 2. For N32 (e.g., LMOTS_SHA256_N32_W2), p=133; for N24 (e.g., LMOTS_SHA256_N24_W2 or LMOTS_SHAKE_N24_W2), p=101. Each hash chain iterates a maximum of 3 times (2^2-1).

[0026] W4: The parameter set in the LM-OTS algorithm where the Winternitz parameter is 4. For N=32 (e.g., LMOTS_SHA256_N32_W4), p=67; for N=24 (e.g., LMOTS_SHA256_N24_W4 or LMOTS_SHAKE_N24_W4), p=51. Each hash chain iterates a maximum of 15 times (2^4-1).

[0027] W8: The parameter set in the LM-OTS algorithm where the Winternitz parameter is 8. When N = 32 (e.g., LMOTS_SHA256_N32_W8), p = 34; when N = 24 (e.g., LMOTS_SHA256_N24_W8 or LMOTS_SHAKE_N24_W8), p = 26. Each hash chain undergoes a maximum of 255 iterations (2^8-1).

[0028] p: The total number of hash chains, determined by the W parameter and n. When N = 32: p = 265 when W1, p = 133 when W2, p = 67 when W4, p = 34 when W8. When N = 24: p = 200 when W1, p = 101 when W2, p = 51 when W4, p = 26 when W8.

[0029] coef(i): The coefficient of the i-th hash chain extracted from the message digest in LM-OTS, with a value range of [0, 2^w-1]. Signing is performed by iterating coef(i) times, and verification is performed by iterating (2^w-1)-coef(i) times.

[0030] `base_2b`: A function in FIPS 205 that converts a message into a base-w representation. When w=16, it extracts a number every 4 bits (0~15); when w=256, it extracts a number every 8 bits (0~255). Functionally equivalent to the `coef` function in LM-OTS.

[0031] Iteration count: The number of hash calculations required for the i-th hash chain. For LM-OTS: coef(i) for signing and (2^w-1)-coef(i) for verification. For WOTS+: msg[i] for signing and (w-1)-msg[i] for verification.

[0032] SLH-DSA: Stateless Hash-Based Digital Signature Algorithm, a stateless hash signature algorithm standardized by NIST (FIPS 205), based on SPHINCS+.

[0033] SPHINCS+: A stateless hash-based post-quantum digital signature scheme, the prototype algorithm of SLH-DSA, selected by NIST as one of the post-quantum cryptography standards.

[0034] WOTS+: One-time signature component used in Winternitz One-Time Signature Plus, XMSS (RFC 8391), and SLH-DSA / SPHINCS+ (FIPS 205). Similar to LM-OTS, it is based on a hash chain structure, where the number of iterations for signing and verification is determined by the message and the hash chains are unbalanced.

[0035] FIPS 205: The Federal Information Processing Standard released by NIST, which defines the complete specification of SLH-DSA (based on SPHINCS+), was officially released in August 2024.

[0036] XMSS: eXtended Merkle Signature Scheme, another hash-based stateful signature algorithm (RFC 8391), also uses WOTS+ as a one-time signature component.

[0037] Hash hardware accelerator: A hardware module dedicated to performing hash operations, multiple of which can be deployed in parallel to improve computational throughput.

[0038] Dynamic scheduling: An embodiment of this application proposes a task allocation strategy that immediately allocates a new task after any hash core completes its current task, thus avoiding idle waiting.

[0039] Task queue: A data structure that stores hash chain tasks to be executed, arranged in a specific order, for the scheduler to allocate to idle hash cores.

[0040] Post-quantum cryptography refers to cryptographic algorithms that are resistant to attacks by quantum computers. LMS, XMSS, and SLH-DSA are all NIST-recommended post-quantum signature algorithms.

[0041] len: The total number of hash chains in WOTS+, equivalent to p in LM-OTS. It is determined by the w parameter and n, len = len1 + len2, where len1 is the number of hash chains generated by message encoding and len2 is the number of hash chains generated by checksum encoding.

[0042] F(PK.seed, ADRS, tmp): A hash chaining function in WOTS+ (defined in FIPS 205), which takes the public key seed PK.seed, the address structure ADRS, and the current hash value tmp as input and outputs an n-byte hash value. Functionally equivalent to H(I‖q‖i‖j‖tmp) in LM-OTS.

[0043] PRF: Pseudo-Random Function. In WOTS+, it is used to generate a private key component from a seed. PRF(PK.seed, SK.seed, ADRS) outputs an n-byte private key component.

[0044] T_len: The L-tree compression function in WOTS+ (defined in FIPS 205) compresses len n-byte public key components into an n-byte WOTS+ public key.

[0045] D_MESG: A field-separating constant in LM-OTS (value 0x8181) used for message hash calculation, distinguishing between message hash and public key hash.

[0046] D_PBLC: A field-separating constant in LM-OTS (value 0x8080) used for public key hash calculation.

[0047] ‖: Cascade operation.

[0048] With the rapid development of quantum computing, traditional digital signature algorithms, such as the Rivest-Shamir-Adleman (RSA), Elliptic Curve Digital Signature Algorithm (ECDSA), and Elliptic Curve Public-Key Cryptography (SM2), face the threat of being broken by quantum computers. Hash-based post-quantum signature algorithms have become an important alternative due to their high security, algorithmic simplicity, and ease of hardware implementation. NIST has standardized two classes of hash-based post-quantum signature algorithms: the stateful schemes LMS and XMSS (SP 800-208, corresponding to RFC 8554 and RFC 8391 respectively), and the stateless scheme SLH-DSA (FIPS 205, based on SPHINCS+).

[0049] RFC 8554 defines the complete specifications for the LMS and LM-OTS algorithms. NIST SP 800-208, building upon this, approved LMS and XMSS (RFC 8391) for digital signatures, supplementing it with an n=24 parameter set. FIPS 205 defines the complete specifications for the SLH-DSA (based on SPHINCS+) algorithm. LMS uses LM-OTS as the one-time signature component, while XMSS and SLH-DSA both use WOTS+ as the one-time signature component. These algorithms share a core computational structure—hash chain iteration—and possess the same structural characteristics: multiple hash chains iterate independently with uneven iteration counts. Therefore, they can share the same dynamic scheduling framework. See also... Figure 1 SK represents the private key, PK represents the public key, and X1-X CS2 This represents the initial value of each of the multiple hash chains, and H() represents the hash operation, H(X1) - H(X2). CS2 H represents the hash value obtained after one hash operation. 2 (X1)-H 2 (X) CS2 H represents the hash value obtained after two hash operations. 3 (X1)-H 3 (X) CS2 X1-X represents the final hash value obtained after three hash operations. CS2 The corresponding hash chain is iterated independently.

[0050] Whether it's LM-OTS in LMS, or WOTS+ in XMSS and SLH-DSA, the signing and verification processes require iterative calculations on multiple hash chains, and the number of iterations for each hash chain is determined by the message digest, resulting in significant differences. For example, in LM-OTS hash chains (RFC 8554): during signing: the i-th hash chain iterates coef(i) times (range 0 ~ 2^w-1); during verification: the i-th hash chain iterates (2^w-1) - coef(i) times (range 0 ~ 2^w-1); taking W8 as an example, there are 34 hash chains, each iterating 0 to 255 times, with significant differences between the hash chains. For example, WOTS+ hash chains (SP 800-208 XMSS / FIPS 205 SLH-DSA): During signing: the i-th hash chain iterates msg[i] times (range 0 ~ w-1); During verification: the i-th hash chain iterates (w-1)-msg[i] times (range 0 ~ w-1); XMSS standard parameters use w=16, with 67 hash chains when n=32, 51 hash chains when n=24, and 35 hash chains when n=16, each iterating 0~15 times; SLH-DSA standard parameters also use w=16; when w=256, it is equivalent to LM-OTS W8.

[0051] Because hash chains are independent of each other, the input to each hash chain depends only on the corresponding private key component (or seed) and message coefficients. The computation process of each hash chain has no data dependency, making it naturally suitable for distribution across multiple hash hardware accelerators, i.e., the hash kernels mentioned above, for parallel execution. Related hash chain parallelization implementations typically employ two strategies: batch synchronous parallelism and fixed-allocation parallelism. These two strategies are described in detail below: Batch synchronous parallelism: Divide the p hash chains into p / N In a batch-by-batch architecture, N hash chains are started in parallel for computation, and the next batch is processed only after all hash chains in the batch have completed. However, due to the significant differences in the number of iterations among the hash chains, hash cores that finish first will be idle while waiting for other hash cores, resulting in a large waste of computing resources and low hardware utilization. Taking W8 parameters as an example, suppose there are 3 hash cores processing 34 hash chains: Batch 1: Hash chain 0 (3 iterations), hash chain 1 (200 iterations), and hash chain 2 (50 iterations) start simultaneously. Hash chain 0 completes first (3 iterations), but must wait for hash chain 1 to complete (200 iterations). During this waiting period, the hash core processing hash chain 0 is idle for 197 iterations, and similarly, the hash core processing hash chain 2 is idle for 150 iterations. This waiting occurs in every batch, accumulating to cause a large waste of computing resources.

[0052] Hardware utilization is defined as the proportion of effective computation time of all hash cores to the total time, which is the sum of the actual iterations of each hash chain divided by (number of hash cores N × number of iterations of the longest hash chain in the batch). Since the number of iterations of each hash chain is determined by the message digest and is approximately uniformly distributed in the range [0, M] (M = 2^w - 1), the time taken for each batch is determined by the longest hash chain in that batch.

[0053] The following derivation of the average utilization rate of a single batch is given: Assume that the iteration counts of the N hash chains in a batch are independent and uniformly distributed on [0, M]. The probability that the maximum number of iterations in the N hash chains does not exceed x is equal to the probability that the number of iterations of each hash chain does not exceed x, i.e., (x / M)^N; the probability density function of the maximum value obtained by taking its derivative with respect to x is N•x^(N-1) / M^N. Therefore, the expected value of the longest hash chain iteration count in a single batch can be calculated:

[0054] The expected sum of the effective computational cost of N hash cores in a single batch is N•M / 2, while the total consumption is the time for each of the N hash cores to run its longest hash chain, with an expected value of N • MN / (N+1). Therefore, the utilization rate R of a single batch is approximately:

[0055] When N=4, the utilization rate is approximately 62.5%, and when N=8, it is approximately 56.3%. Considering various parameter sets and core configurations, the average hardware utilization rate of the batch synchronization method is approximately 53%-60%. The above theoretical values ​​are based on an approximation of a continuous uniform distribution in a single batch. The actual simulation results are lower than 62.5% due to reasons such as the last batch not having N hash chains, resulting in idle hash cores, and the discrete distribution of small parameters such as W1 / W2 deviating from the continuous uniform assumption.

[0056] Fixed-distribution parallelism: p hash chains are statically allocated to N hash cores, with each hash core responsible for processing p / N hash chains (executed sequentially). This method avoids batch waiting but cannot dynamically balance the load; waiting still exists when the total number of tasks allocated to each hash core is uneven. For example, 34 hash chains are allocated to 3 hash cores: hash core 0 processes hash chains 0-11, hash core 1 processes hash chains 12-22, and hash core 2 processes hash chains 23-33. Each hash core executes all allocated hash chains sequentially.

[0057] Since the number of iterations for each hash chain is determined by the message content (randomly distributed), some cores may receive a much larger total number of hash chain iterations than others, causing some cores to finish early and then wait idle. Similar to batch synchronous parallelism, the total time is determined by the core with the heaviest load. However, the above derivation has shown that the expected maximum value of N random variables, M•N / (N+1), is always greater than the mean M / 2. Therefore, no static allocation method can eliminate the waiting overhead caused by uneven load.

[0058] In summary, the related technologies suffer from low hardware utilization and long hash chain computation time.

[0059] This application provides a method for scheduling and executing hash chains. The method includes: when at least one target hash core completes a hash operation on a currently allocated hash chain, storing the hash value obtained from the hash operation into a hash result according to the chain index corresponding to the currently allocated hash chain; the chain index is used to determine the storage location of the hash value in the hash result; based on the updated value of the queue head pointer and the hash chain queue, continuing to allocate hash chains to at least one target hash core, and updating the updated value of the queue head pointer; the updated value of the queue head pointer represents the first hash chain to be allocated in the hash chain queue at the next hash chain allocation; and obtaining a hash result after completing a hash operation on all hash chains in the hash chain queue.

[0060] In this embodiment, when at least one target hash core completes a hash operation on the currently allocated hash chain, the hash value is stored in the hash result according to the storage location determined by the chain index corresponding to the currently allocated hash chain. In addition, since the updated value of the queue head pointer represents the first hash chain to be allocated in the next hash chain allocation, hash chains can continue to be allocated for at least one target hash core based on the updated value of the queue head pointer and the hash chain queue, without waiting. This achieves the effect of allocation upon completion, thus improving hardware utilization and reducing the hash chain calculation time.

[0061] Figure 1 This is a flowchart illustrating a hash chain scheduling and execution method provided in an embodiment of this application. See also... Figure 1 The scheduling and execution methods for this hash chain include: S101, when at least one target hash kernel completes the hash operation on the currently allocated hash chain, the hash value obtained from the hash operation is stored in the hash result according to the chain index corresponding to the currently allocated hash chain.

[0062] In this context, a hash chain refers to a unidirectional iterative data chain formed through multiple consecutive iterations of a one-way hash function. The currently assigned hash chain is the one scheduled and put into computation at the current moment in the signature or verification process. The chain index is a unique sequential number and identifier assigned to all hash chains to distinguish them. The hash value is a fixed-length digest data output by the hash chain after a specified number of unidirectional iterations; it represents the result of a single hash chain's computation. The hash result is formed by summarizing and integrating all hash values ​​output from multiple hash chains according to rules, and is used to generate signature data or private key data.

[0063] In one possible implementation, each hash core is configured with an independent completion flag. After at least one target hash core completes the hash iteration operation of the current hash chain, its corresponding completion flag is automatically set. By polling or sampling the flags of all hash cores in parallel, the completion of a target hash core is detected as soon as any flag is set. In another implementation, a completion signal is actively output after at least one target hash core has completed its hash operation. The completion signal is captured via an interrupt listening interface, indicating that a target hash core has completed its hash operation.

[0064] The chain index is used to determine the storage location of the hash value in the hash result. In some embodiments, the storage location of the hash value in the hash result can be determined based on the chain index corresponding to the currently allocated hash chain, and the hash value can be stored in the hash result according to the storage location.

[0065] The storage location is used to distinguish the storage areas for different hash values, thereby achieving ordered isolation and precise read / write of hash values. In some embodiments, the storage location can be the storage index of the hash value. In other embodiments, the storage location can be the address offset of the hash value.

[0066] In one possible implementation, the chain index corresponding to the currently allocated hash chain is determined as the storage index of the hash value in the hash result, and the position corresponding to this storage index is determined as the storage location of the hash value in the hash result. In another possible implementation, a fixed-byte or bit-width storage space can be allocated to each hash value. When determining the storage location of the hash value in the hash result, the address offset is obtained by multiplying the chain index corresponding to the currently allocated hash chain by the fixed-byte or bit-width storage space, and this address offset is determined as the storage location.

[0067] In one possible implementation, the hash value is directly written to the location corresponding to the storage index. In another possible implementation, the storage address is determined based on the starting address and the address offset, and the hash value is written to that storage address.

[0068] S102, based on the updated value of the queue head pointer and the hash chain queue, continue to allocate hash chains for at least one target hash core, and update the updated value of the queue head pointer.

[0069] The hash chain queue is used to store hash chains. In some embodiments, the hash chain queue is an unsorted hash chain queue or a hash chain queue sorted in descending order.

[0070] The descending-order hash chain queue is obtained by sorting all hash chains in the unsorted hash chain queue in descending order based on the number of iterations of each hash chain. For example, arranging p hash chains in the hash chain queue in descending order of iteration count ensures that the most computationally intensive tasks are assigned priority for execution. Sorting can be performed using conventional sorting algorithms such as insertion sort or quicksort. Since p is at most 2^65, the time overhead of sorting is far less than the hash calculation itself and can be ignored. This further ensures that hash chains with more iterations begin execution as early as possible, while hash chains with fewer iterations are used to fill idle hash cores at the end, thus balancing the workload across hash cores and reducing tail waiting time.

[0071] The queue head pointer is a pointer set for the hash chain queue. The updated value of the queue head pointer indicates the first hash chain to be allocated in the hash chain queue during the next hash chain allocation. In other words, the queue head pointer always points to the first hash chain to be allocated in the next hash chain allocation.

[0072] In some embodiments, based on the updated value of the queue head pointer and the hash chain queue, hash chains are sequentially allocated to at least one target hash core according to the arrangement order of at least one target hash core, and the updated value of the queue head pointer is updated accordingly. In another embodiment, based on the updated value of the queue head pointer and the hash chain queue, hash chains are allocated to at least one target hash core simultaneously, and the updated value of the queue head pointer is updated accordingly.

[0073] In one possible implementation, starting from the updated value of the queue head pointer, hash chains are sequentially extracted from the hash chain queue, and hash chains are allocated to target hash kernels in order to at least one target hash kernel, while updating the updated value of the queue head pointer. In another possible implementation, starting from the updated value of the queue head pointer, a specified number of hash chains are continuously extracted from the hash chain queue, simultaneously allocated to at least one target hash kernel, and updating the updated value of the queue head pointer.

[0074] S103, perform hash operations on the newly allocated hash chains based on at least one target hash kernel, until all hash chains in the hash chain queue have been allocated and hash operations have been completed on all hash chains, and then obtain the hash result.

[0075] In some embodiments, performing hash operations on all hash chains in the hash chain queue indicates that all hash chains in the hash chain queue have been allocated, meaning the hash chain queue is empty. Alternatively, performing hash operations on all hash chains indicates that each hash chain has a corresponding hash value, at which point the hash result can be obtained.

[0076] In this embodiment, when at least one target hash core completes the hash operation on the currently allocated hash chain, the hash value is stored in the hash result according to the storage location determined by the chain index corresponding to the currently allocated hash chain. Furthermore, since the updated value of the queue head pointer represents the first hash chain to be allocated in the next hash chain allocation, hash chains can continue to be allocated for at least one target hash core based on the updated value of the queue head pointer and the hash chain queue. The process of storing hash values, allocating new hash chains, and performing hash operations on new hash chains is repeated cyclically until all hash chains are allocated and hash operations are completed on all hash chains, at which point the hash result is obtained. This eliminates the need to wait for all hash chains in the batch to complete their hash operations before reallocation, achieving the effect of allocation upon completion. Therefore, it can improve hardware utilization and reduce the hash chain computation time.

[0077] In some embodiments, S102, based on the updated value of the queue head pointer and the hash chain queue, continues to allocate hash chains for at least one target hash core and updates the updated value of the queue head pointer, including: S111, for each target hash core, based on the updated value of the queue head pointer, determine the first hash chain to be allocated from the hash chain queue, and allocate the first hash chain to be allocated to the target hash core.

[0078] In some embodiments, the updated value of the queue head pointer is used as the chain index of the first hash chain to be allocated. That is, the hash chain pointed to by the updated value of the queue head pointer is the first hash chain to be allocated.

[0079] In some embodiments, if the first hash chain to be allocated meets a preset condition, the first hash chain to be allocated is allocated to the target hash core. If the first hash chain to be allocated does not meet the preset condition, the update value of the queue head pointer is incremented by one, and the first hash chain to be allocated is determined based on the incremented update value until the first hash chain to be allocated meets the preset condition.

[0080] S112, increment the value of the queue head pointer by one.

[0081] In some embodiments, since the updated value of the queue head pointer represents the first hash chain to be allocated in the hash chain queue during the next hash chain allocation, after allocating the first hash chain to be allocated to the target hash core, the updated value of the queue head pointer needs to be incremented by one so that the updated value of the queue head pointer points to the first hash chain to be allocated in the next hash chain allocation.

[0082] Based on the above technical means, the first hash chain to be allocated is determined based on the updated value of the queue head pointer, and the first hash chain to be allocated is allocated to the target hash core. There is no need to wait, and the effect of allocation upon completion can be achieved. Therefore, hardware utilization can be improved and the calculation time of hash chain can be reduced.

[0083] In some embodiments, the hash chain has a corresponding number of iterations; the scheduling and execution method of the hash chain further includes: S121, if the number of iterations of the first hash chain to be assigned is the same as the preset value, obtain the initial hash value of the first hash chain to be assigned.

[0084] The number of iterations in the hash chain is the total number of times the hash operation is repeated, starting from the initial hash value of the hash chain. In some embodiments, the calculation process for the number of iterations of the hash chain is as follows:

[0085] The aforementioned preset condition could be that the number of iterations of the first hash chain to be allocated is different from a preset value.

[0086] Here, the preset value indicates that the hash chain does not undergo hash iteration. In some embodiments, the preset value can be 0 for signing scenarios, or 2^w – 1 for signature verification scenarios. That is to say, when the iteration number T_i of the first hash chain to be assigned is 0 (i.e., coef(i) = 2^w - 1 for signature verification, or coef(i) = 0 for signing), the initial value corresponding to the first hash chain to be assigned is directly the output result, without any hash operation.

[0087] In some embodiments, in a signature verification scenario, the initial value is loaded from the signature y[idx], and in a signature scenario, the initial value is loaded from the private key x[idx].

[0088] S122, according to the chain index of the first hash chain to be allocated, the initial hash value is stored in the hash result, and the update value of the queue head pointer is incremented by one, and the step of determining the first hash chain to be allocated from the hash chain queue based on the update value of the queue head pointer is entered.

[0089] In some embodiments, if the iteration count of the first hash chain to be allocated is detected to be the same as a preset value, the storage location of the initial value in the hash result is directly determined based on the chain index of the first hash chain to be allocated, and the initial value is stored at that storage location. After storing the initial value, the update value of the queue head pointer is incremented by one so that the queue head pointer points to the next hash chain to be allocated, and the first hash chain to be allocated is determined from the hash chain queue based on the update value of the queue head pointer. This method can further improve scheduling efficiency by skipping zero-iteration tasks and not consuming hash core resources.

[0090] In S112, the first hash chain to be allocated is determined for the target hash core, including: S123, if the number of iterations of the first hash chain to be allocated is different from the preset value, allocate the first hash chain to be allocated to the target hash core.

[0091] If the number of iterations of the first hash chain to be allocated is different from the preset value, it means that the first hash chain to be allocated needs to perform hash operation. At this time, the first hash chain to be allocated needs to be allocated to the target hash core so that the target hash core can perform the corresponding hash operation.

[0092] Based on the above technical means, when the number of iterations of the first hash chain to be allocated is the same as the preset value, the initial value of the first hash chain to be allocated is directly stored in the hash result according to the chain index of the first hash chain to be allocated. When the number of iterations of the first hash chain to be allocated is different from the preset value, the first hash chain to be allocated is allocated to the target hash core. By skipping the zero-iteration task, the hash core resources are not occupied, and the scheduling efficiency can be further improved.

[0093] In some embodiments, S102, based on the updated value of the queue head pointer and the hash chain queue, continues to allocate hash chains for at least one target hash core and updates the updated value of the queue head pointer, including: S131, based on the number of at least one target hash core and the number of remaining hash chains in the hash chain queue, determine at least one second hash chain to be allocated from the hash chain queue.

[0094] In this approach, when at least one target hash kernel completes its hash chain's hash operation simultaneously or within a very short time interval, at least one second hash chain to be allocated can be determined from the hash chain queue. For example, in each round of detection, all hash kernels are traversed first, the target hash kernel numbers that have completed hash operations are collected, and a set F = {k | target hash kernel k has completed} is generated. Then, for each target hash kernel in F, the operations of saving the hash value, allocating a new hash chain, and starting a new hash operation are performed sequentially. This batch processing avoids the overhead of repeated traversal caused by processing one by one.

[0095] In some embodiments, if the number of at least one target hash core is less than or equal to the number of remaining hash chains in the hash chain queue, the number of hash chains to be allocated is the number of at least one target hash core, indicating that there are still remaining hash chains after this hash chain allocation is completed; if the number of at least one target hash core is greater than the number of remaining hash chains in the hash chain queue, the number of hash chains to be allocated is the number of remaining hash chains in the hash chain queue, indicating that there are no remaining hash chains after this hash chain allocation is completed.

[0096] In this embodiment, at least one second chain index is a set of hash chain numbers allocated in this instance. In some embodiments, after determining the number of hash chains to be allocated, at least one second hash chain to be allocated is determined based on the updated value of the queue head pointer and the number of hash chains to be allocated. For example, starting with the updated value of the queue head pointer as the starting index, consecutive numbers are generated by incrementing by 1 until the number of hash chains to be allocated is met, resulting in at least one second hash chain to be allocated.

[0097] S132, assign at least one second hash chain to be assigned for at least one target hash core.

[0098] In some embodiments, at least one second hash chain to be assigned is used as a whole and simultaneously assigned to at least one target hash core.

[0099] S133, based on the updated value of the queue head pointer and the number of at least one second unassigned hash chain, update the updated value of the queue head pointer.

[0100] In some embodiments, the updated value of the queue head pointer is updated based on the sum of the updated value of the queue head pointer and the number of at least one second hash chain to be assigned, that is, the updated value of the queue head pointer is updated to the sum, so that the updated value of the queue head pointer points to the next hash chain to be assigned.

[0101] Based on the above technical means, when at least one target hash kernel completes the hash operation of its respective hash chain at the same time or within a very short time interval, the batch processing method of simultaneously allocating at least one second hash chain to be allocated to at least one target hash kernel can avoid the repeated traversal overhead caused by processing one by one and reduce scheduling overhead.

[0102] In some embodiments, after storing the hash value obtained from the hash operation into the hash result according to the chain index corresponding to the currently allocated hash chain in S101, the hash chain scheduling and execution method further includes: S141, update the count value of the initialized completion counter based on the number of hash values.

[0103] The completion counter is used to count in real time the number of hash operations completed and the number of hash values ​​stored in the hash result hash chain. In some embodiments, the count value of the completion counter after initialization can be 0.

[0104] In some embodiments, the count value of the initialized completion counter can be updated to the number of hash values.

[0105] In S103, after performing hash operations on all hash chains in the hash chain queue, the hash result is obtained, including: S142, after hashing all hash chains in the hash chain queue has been hashed, obtain the updated count value of the completion counter.

[0106] In some embodiments, after performing a hash operation on the hash chain and storing the hash value obtained from the hash operation in the hash result, the count value of the completion counter is incremented by one; after all hash chain operations are completed and the hash values ​​obtained from the hash operation are stored in the hash result, the updated count value of the completion counter is read directly.

[0107] S143, if the updated completion counter count is the same as the number of all hash chains, obtain the hash result.

[0108] When the updated completion counter value is the same as the total number of hash chains, all hash operations on all hash chains have been completed, and a complete hash result can be obtained.

[0109] Based on the above technical means, by introducing a completion counter during the hash operation and updating the count value of the completion counter, the hash result can be obtained when the updated count value of the completion counter is the same as the number of all hash chains. This ensures that all hash chain hash values ​​are calculated and stored, thereby improving the reliability of the operation and the integrity of the data.

[0110] In some embodiments, the hash chain scheduling and execution method further includes: S151 initializes the queue head pointer to obtain the initial value corresponding to the queue head pointer.

[0111] In some embodiments, the initial value of the queue head pointer can be 0, pointing to the first hash chain of the hash chain queue.

[0112] S152, with the initial allocation of each hash core based on the hash chain queue, the initial value corresponding to the queue head pointer is updated based on the number of hash cores and the number of all hash chains to obtain the updated value of the queue head pointer.

[0113] The initial allocation involves taking min(N, p) hash chains from the head of the hash chain queue and assigning them to hash cores numbered 0, 1, ..., min(N, p)-1, respectively, where N is the number of hash cores and p is the total number of hash chains.

[0114] In some embodiments, the initial value corresponding to the queue head pointer can be updated based on the minimum value among the number of hash kernels and the number of all hash chains. For example, first determine the minimum value among the number of hash kernels and the number of all hash chains, then determine the sum of the initial value corresponding to the queue head pointer and the minimum value, and update the initial value corresponding to the queue head pointer based on the sum to obtain the updated value of the queue head pointer.

[0115] Among them, when the number of hash cores is less than the total number of hash chains, the minimum value is the number of hash cores, indicating that there are still remaining hash chains after the initial allocation; when the number of hash cores is greater than or equal to the total number of hash chains, the minimum value is the total number of hash chains, indicating that only the initial allocation is needed, and there are no remaining hash chains after the initial allocation.

[0116] The sum of the initial and minimum values ​​corresponding to the queue head pointer represents the number of hash chains initially allocated.

[0117] In some embodiments, the initial value corresponding to the queue head pointer is updated based on the summation result to obtain the updated value of the queue head pointer, that is, the updated value of the queue head pointer is the summation result.

[0118] Based on the above technical means, after the initial allocation is completed, the initial value corresponding to the queue head pointer is updated so that the queue head pointer always points to the first hash chain to be allocated in the next hash chain allocation. In the next hash chain allocation, there is no need to wait, which can improve hardware utilization.

[0119] In some embodiments, the hash chain scheduling execution method further includes: when an initial allocation is performed for each hash core based on the hash chain queue, and there is a target hash chain in the hash chain queue with the same number of iterations as a preset value, skipping the target hash chain and determining the corresponding currently allocated hash chain for each hash core.

[0120] The target hash chain with the same number of iterations as the preset value indicates that the number of iterations of the target hash chain is 0 in the signature scenario and 2^w – 1 in the signature verification scenario.

[0121] For example, if the hash chain queue is Q[0..p-1], and the number of iterations of hash chain 1 and hash chain 3 is the same as the preset value, then when initial allocation value is made for each hash core, hash chain 1 and hash chain 3 are skipped, and the current allocated hash chain is determined for each hash core based on hash chain 0, hash chain 2, hash chain 4 to hash chain p-1.

[0122] In some embodiments, for the signature scenario, during the initial allocation phase, if the iteration count of the target hash chain is detected to be 0, its input value is directly copied as the result z[i], and the counter value is incremented by 1. In other embodiments, for the signature verification scenario, during the initial allocation phase, if the iteration count of the target hash chain is detected to be 2^w - 1, its input value is directly copied as the result z[i], and the counter value is incremented by 1.

[0123] Based on the above technical means, during the initial allocation, the target hash chain with the same number of iterations as the preset value is skipped, which does not occupy hash core resources and can further improve scheduling efficiency.

[0124] In some embodiments, the hash chain scheduling and execution method further includes: S161, initialize the kernel state corresponding to each hash kernel to obtain the initialization state.

[0125] The kernel state is used to record the execution status of the hash kernel. In some embodiments, the kernel state may include a busy flag, a current task pointer, and a result cache. The busy flag B_k indicates whether the k-th kernel is currently executing a hash chain (0 = idle, 1 = busy); the current task pointer C_k points to the hash chain that the hash kernel is currently processing; and the result cache Z_k is n bytes, storing the hash value calculated by the hash kernel.

[0126] In some embodiments, the busy state of a hash kernel can include: Idle, Busy, and Finished. Idle indicates that the hash kernel is not executing any hash chain and is waiting to be allocated a hash chain. After the kernel state of the hash kernel is initialized, all hash kernels are in this state. When a hash kernel is in the Idle state, its busy flag is 0. Busy indicates that the hash kernel is performing a hash operation, executing T_i hash operations consecutively (LM-OTS: tmp = H(I‖q‖i‖j‖tmp); WOTS+: tmp = F(PK.seed, ADRS, tmp)). Finished indicates that the hash kernel has completed the hash operation of the current hash chain and is waiting to store the hash value and decide on the next operation. It should be noted that when a hash kernel is in the Busy or Finished state, its busy state is 1.

[0127] In some embodiments, the kernel state corresponding to each hash kernel is initialized, which may be by initializing the busy flag corresponding to the hash kernel to 0, the current task pointer to 0, and the result cache to 0.

[0128] S162, after initial allocation of each hash core based on the hash chain queue, update the core state.

[0129] In some embodiments, upon completion of the initial allocation, the busy flag is updated to 1, and the current task pointer is updated to the chain index of the currently allocated hash chain. After the hash operation is completed, the result cache is updated to the hash value.

[0130] S163, when at least one target hash kernel completes the hash operation on the currently allocated hash chain and the hash chain queue is empty, update the kernel state corresponding to at least one target hash kernel to the initialization state.

[0131] In some embodiments, when at least one target hash core completes the hash operation on the currently allocated hash chain and the hash chain queue is not empty, hash chains continue to be allocated to at least one target hash core, and the updated value of the queue head pointer is updated. This continues until the hash chain queue is empty, at which point the core state corresponding to at least one target hash core is updated to the initialization state.

[0132] Based on the above technical means, the core status of hash cores can be recorded in real time, and the working status of each hash core can be known at any time, which can provide an accurate basis for the dynamic allocation of hash chains.

[0133] The scheduling and execution method of the hash chain provided in this application embodiment will be described in detail below with reference to specific application scenarios.

[0134] Figure 3This is a schematic diagram of a product architecture provided in an embodiment of this application. See also... Figure 3 , Figure 3 The software side includes a main controller, and the hardware side includes a hash hardware accelerator IP. The main controller includes a dynamic scheduler, which performs pre-calculation of iteration counts, task sorting (e.g., descending order, Longest Processing Time First (LPT) scheduling algorithm), task queue management (i.e., the hash chain queue mentioned above), and status monitoring and allocation. The hash hardware accelerator IP includes multiple hash cores, from hash core 0 to hash core N-1. The dynamic scheduler allocates tasks (i.e., the hash chain mentioned above) to the multiple hash cores, and after a hash core completes its hash operation on a task, it sends a completion signal.

[0135] This application primarily applies to cryptographic chips or security processors equipped with multi-core hash hardware accelerators (multi-hash cores). Typical application scenarios include: high-performance cryptographic cards / hardware security modules (HSMs) equipped with multiple parallel hash acceleration cores (hash cores) requiring high throughput processing of LMS, XMSS, and SLH-DSA signature and verification requests. The dynamic scheduling scheme of this application can fully leverage the advantages of multi-core processors, improving signature and verification throughput, especially significantly enhancing verification performance; and secure system-on-chip (SoC) chips, which integrate multiple hash acceleration cores for use in IoT gateways, industrial controllers, and other scenarios. This application's embodiments help maximize the signature verification performance of LMS / XMSS / SLH-DSA under limited hardware resources. Field Programmable Gate Array (FPGA) cryptographic accelerators implement multiple parallel hash computation units on the FPGA. The scheduling strategy of this application's embodiments can be directly applied without modifying the hash core design. For post-quantum cryptography migration, when related technologies such as RSA / ECDSA hardware platforms equipped with multi-core hash accelerators migrate to post-quantum algorithms, this application's embodiments provide efficient LMS, XMSS, and SLH-DSA signature verification acceleration solutions, fully covering both SP 800-208 and FIPS 205 standards. For firmware secure boot and code signing, in secure boot scenarios, firmware signature verification needs to be quickly verified after the device powers on. When the secure boot chip is equipped with multiple hash acceleration cores, LMS, XMSS, and SLH-DSA are all candidate solutions for post-quantum secure boot. The dynamic scheduling scheme of this application's embodiments can fully utilize multi-core parallel capabilities to shorten boot verification time. On the signature side, code distribution servers equipped with multi-core hash accelerators can use this solution to accelerate batch signing.

[0136] 1. Hash chain iteration mechanism The hash chain iteration mechanisms involved in the embodiments of this application include two types: LM-OTS (RFC 8554) in the LMS algorithm and WOTS+ (FIPS 205) in the XMSS / SLH-DSA algorithm. Both share the same structural characteristics—multiple hash chains iterate independently with uneven iteration counts, thus allowing them to share the same dynamic scheduling framework. It should be noted that SP 800-208 covers both LMS and XMSS stateful signature schemes: LMS uses LM-OTS, and XMSS uses WOTS+. Therefore, the dynamic scheduling scheme in the embodiments of this application fully covers all computational scenarios involving hash chain iteration in the SP 800-208 standard.

[0137] 1.1 LM-OTS Hash Chain Iteration Mechanism (RFC 8554) Both the signing and verification processes of LM-OTS involve hash chain iteration, and the number of iterations is determined by the message, resulting in an imbalance among the hash chains.

[0138] 1.1.2 LM-OTS Signature Process (Algorithm 3) The core of LM-OTS signature is to generate a signature value y[i] by iterating coef(i) times over each hash chain starting from the private key x[i].

[0139] Key observation: During signing, the i-th hash chain iterates coef(i) times. The number of iterations for each hash chain is determined by the message, ranging from 0 to 2^w-1, with significant differences. The computation of the p hash chains is independent and can be executed in parallel.

[0140] 1.1.2 LM-OTS Verification Process (Algorithm 4b) The core of LMS signature verification is to reconstruct the LM-OTS public key Kc and then verify it through a Merkle tree path. According to RFC 8554, the LM-OTS public key reconstruction process is as follows (refer to the lm_ots_verify_internal function):

[0141] Key observation: During signature verification, the i-th hash chain iterates (2^w-1)-coef(i) times, which is complementary to the coef(i) times during signature verification, and the sum is always equal to 2^w-1. The computation of the p hash chains is independent of each other and can be executed in parallel.

[0142] 1.1.3 Comparison of Hash Chain Iterations for LM-OTS Signature and Verification The hash chain iteration mechanisms for signing and verification are symmetrical and complementary, and the dynamic scheduling scheme applies to both. Table 1 below shows a comparison of the hash chain iterations for LM-OTS signing and verification. Referring to Table 1, LM-OTS hash chain (RFC 8554): For signing: the i-th hash chain iterates coef(i) times (range 0 - 2^w-1). For verification: the i-th hash chain iterates (2^w-1) - coef(i) times (range 0 ~ 2^w-1).

[0143] Table 1

[0144] Taking W8 as an example, suppose the coef values ​​of the first 6 hash chains of a message are [3, 200, 50, 180, 10, 255]: the signature iteration count is [3, 200, 50, 180, 10, 255], which is significantly different; the signature verification iteration count is [252, 55, 205, 75, 245, 0], which is also significantly different; there is an imbalance problem between hash chains in both scenarios, and both can benefit from dynamic scheduling.

[0145] 1.2 WOTS+ Hash Chain Iteration Mechanism (RFC 8391 XMSS / FIPS 205 SLH-DSA) Both RFC 8391 (XMSS) and FIPS 205 (SLH-DSA) use WOTS+ as a one-time signature component. The following details its core hash chain iteration structure based on the algorithm description of FIPS 205.

[0146] 1.2.1 WOTS+ Signing Process (FIPS 205 Algorithm 7: wots_sign) The core of WOTS+ signing is to generate a signature value sig[i] by iterating msg[i] times for each hash chain, starting from the private key sk[i].

[0147] As can be seen, similar to LMOTS, during signing, the i-th hash chain iterates msg[i] times, and the number of iterations for each hash chain is determined by the message, ranging from 0 to w-1, with significant differences. The computation of len hash chains is independent and can be executed in parallel.

[0148] 1.2.2 WOTS+ Verification Process (FIPS 205 Algorithm 8: wots_pkFromSig) The core of WOTS+ signature verification is to start from the signature value sig[i] and iterate (w-1)-msg[i] times for each hash chain to recover the public key component tmp[i].

[0149] It can be seen that during signature verification, the i-th hash chain iterates (w-1)-msg[i] times, which is complementary to the msg[i] times during signature verification, and the sum is always equal to w-1. The calculations of len hash chains are independent of each other and can be executed in parallel.

[0150] 1.2.3 Comparison of Hash Chain Iterations for WOTS+ Signature and Verification Similar to LM-OTS, WOTS+'s signature and verification hash chain iteration mechanisms are symmetrical and complementary, and the dynamic scheduling scheme applies to both. Table 2 below shows a comparison of the hash chain iterations for WOTS+ signature and verification. See Table 2 below, WOTS+ hash chain (SP800-208 XMSS / FIPS 205 SLH-DSA): For signing: the i-th hash chain iterates msg[i] times (range 0 ~ w-1). For verification: the i-th hash chain iterates (w-1)-msg[i] times (range 0 ~ w-1).

[0151] Table 2

[0152] 1.3 Correspondence between LM-OTS and WOTS+ Table 3 below shows the correspondence between LM-OTS and WOTS+. Referring to Table 3, the XMSS standard uses w=16. With n=32, there are 67 hash chains; with n=24, there are 51 hash chains; and with n=16, there are 35 hash chains. Each chain undergoes 0-15 iterations. Similarly, the SLH-DSA standard also uses w=16; w=256 is equivalent to LM-OTS W8.

[0153] Table 3

[0154] Since the hash chain structures of the two are completely equivalent, the dynamic scheduling scheme of this application (pre-calculation of iteration count, descending order sorting, and allocation upon completion) can be directly applied to WOTS+ in XMSS and SLH-DSA, requiring only the following: 1) Replace the coef function with the base_2b function; 2) The hash function H(I‖q‖i‖j‖tmp) is replaced with WOTS+ hash chain function F(PK.seed,ADRS,tmp); 3) The task queue length of the scheduler is changed from p to len; 4) For XMSS: The WOTS+ parameter is determined by the XMSS parameter set, and the standard parameter set uses w=16; 5) For SLH-DSA: The WOTS+ parameter is determined by the SLH-DSA parameter set, and the standard parameter set also uses w=16.

[0155] 2. Analysis of Hash Chain Characteristics with Different W Parameters 2.1 LM-OTS Parameter Set (RFC 8554 / SP 800-208) RFC 8554 defines four W parameters, corresponding to different hash chain configurations (the p value is related to n). Table 4 below analyzes the hash chain characteristics of different W parameters based on the LM-OTS parameter set (RFC 8554 / SP 800-208). See Table 4 below: W1: Each hash chain iterates at most once, with minimal differences between hash chains (0 or 1), and minimal waste in batch synchronization; W2: Each hash chain iterates at most three times, with still relatively small differences between hash chains; W4: Each hash chain iterates at most 15 times, and significant differences begin to appear; W8: Each hash chain iterates at most 255 times, with the most significant differences, and the most severe waste in batch synchronization.

[0156] Table 4

[0157] analyze: W1: Each hash chain iterates at most once, with minimal differences between hash chains (0 or 1), resulting in less waste in batch synchronization; W2: Each hash chain iterates a maximum of 3 times, and the differences between hash chains are still relatively small; W4: Each hash chain iterates a maximum of 15 times, at which point significant differences begin to appear; W8: Each hash chain can iterate a maximum of 255 times, with the most significant differences, and the batch synchronization method is the most wasteful.

[0158] The dynamic scheduling scheme in this application is effective for all W parameters, but the effect is most significant with W4 and W8 parameters. The above analysis applies to both signature and verification because their iteration number distribution characteristics are the same (the complementary relationship does not affect the degree of imbalance).

[0159] 2.2 WOTS+ Parameter Set (RFC 8391 XMSS / FIPS 205 SLH-DSA) Table 5 below analyzes the hash chain characteristics of different W parameters based on the WOTS+ parameter set (RFC 8391 XMSS / FIPS 205 SLH-DSA). See Table 5 below. WOTS+ in XMSS (RFC 8391) and SLH-DSA (FIPS 205) also have different parameter configurations, and its imbalance characteristics are equivalent to LM-OTS.

[0160] Table 5

[0161] The SLH-DSA standard parameter set primarily uses w=16, corresponding to an imbalance level equivalent to LM-OTS W4 (iteration range 0~15), and dynamic scheduling can bring a moderate performance improvement. If the future parameter set adopts w=256, the effect will be as significant as LM-OTS W8.

[0162] 3. Detailed Design of Dynamic Scheduling Scheme 3.1 Data Structure Definition This application involves three core data structures: (1) Description of hash chain task Each hash chain task contains the following information: A) Chain index idx: The original hash chain number corresponding to this task, with a value range of [0, p-1]; B) Number of iterations T_i: The total number of hash iterations required for this hash chain (coef(i) for signing, (2^w-1)-coef(i) for verification); C) Current iteration position j_i: indicates the iteration progress, with an initial value of 0 when signing or coef(i) when verifying the signature; D) Current hash value V_i: n bytes (n=16, 24 or 32), storing intermediate hash results during the iteration process.

[0163] (2) Hash kernel state Each hash hardware acceleration core maintains the following state: A) Busy flag B_k: Indicates whether the kth hash kernel is currently executing a task (0 = idle, 1 = busy); B) Current task pointer C_k: points to the hash chain task that the hash kernel is currently processing; C) Result cache Z_k: n bytes, storing the hash result calculated by the hash kernel.

[0164] (3) Scheduling Manager Unified management of task allocation and progress tracking: A) Task queue Q[0..p-1]: Stores all p hash chain tasks, which can be sorted by the number of iterations; B) Queue head pointer H: points to the position of the next task to be assigned, with an initial value of 0, and incremented by 1 for each task assigned; C) Completion Counter D: Records the number of hash chains that have been calculated, with an initial value of 0; D) Kernel state array S[0..N-1]: records the current state of N hash kernels; E) Result array z[0..p-1]: Stores the final calculation results of each hash chain, stored according to the original hash chain index.

[0165] 3.2 Pre-calculation of Iteration Count At the start of signing or verification, the iteration count of all p hash chains is calculated at once. The specific steps are as follows:

[0166] 3.3 Task Sequencing Sort the p hash chain tasks in the task queue in descending order of iteration number T_i, so that the task with the largest computational cost is assigned to be executed first.

[0167] Sorting method: Conventional sorting algorithms such as insertion sort or quicksort can be used. Since p is at most 2^65, the time cost of sorting is much smaller than that of hash calculation itself and can be ignored.

[0168] The purpose of sorting is to ensure that long tasks (hash chains with many iterations) start executing as early as possible, while short tasks (hash chains with few iterations) are used to fill idle cores at the end, thereby balancing the workload of each core and reducing tail waiting time.

[0169] Sorting example (W8, assuming the number of iterations of the first 6 hash chains): Before sorting: [3, 200, 50, 180, 10, 255]; After sorting: [255, 200, 180, 50, 10, 3].

[0170] 3.4 Core Algorithm for Dynamic Scheduling The dynamic scheduling algorithm consists of two phases: initial allocation and dynamic loop. Phase 1: Initial Allocation

[0171] Phase Two: Dynamic Scheduling Loop

[0172] The core feature of this algorithm is that it assigns tasks immediately upon completion: once a hash core is completed, it immediately receives a new task without waiting for other hash cores, thereby maximizing the utilization of all hash cores.

[0173] 3.4.1 Overall Dynamic Scheduling Process Figure 4 This is a flowchart illustrating the steps of the initialization and allocation phase proposed in an embodiment of this application. See also... Figure 4 Specifically, it can include: S401, Pre-calculate the iteration counts iter_counts[0..p-1] of all p hash chains according to the message digest Q and the checksum.

[0174] S402, Initialize the queue head pointer queue_head = 0.

[0175] S403, Initialize the completion counter completed_count = 0.

[0176] S404, Initialize the status of all hash cores to idle.

[0177] S405, Obtain the identifier of the hash core, that is, the first hash core, core_id = 0.

[0178] S406, Determine whether the identifier of the hash core and the queue head pointer meet the conditions, that is, whether core_id < N and queue_head < p are satisfied. If satisfied, jump to S407; otherwise, continue to execute this step.

[0179] S407, Take out the hash chain to be allocated task_queue[queue_head] from the hash chain queue.

[0180] S408, Allocate the hash chain to be allocated to the hash core core_id and start the hash core to start computing.

[0181] S409, Update the identifier of the hash core and the queue head pointer, queue_head++; core_id++.

[0182] S410, Perform dynamic scheduling, and continue Figure 5 with S501.

[0183] Figure 5 is the step flowchart of a dynamic scheduling loop proposed in an embodiment of the present application. Refer to Figure 5 , and specifically may include: S501, Determine whether the count value of the completion counter is less than the number of hash chains, completed_count < p. If satisfied, jump to S502; otherwise, jump to S510.

[0184] S502, Traverse all hash cores core_id (from 0 to N-1).

[0185] S503, Determine whether it is detected that the target hash core core_id has completed the current hash operation. If completed, jump to S505; otherwise, jump to S504.

[0186] S504, Continue to detect the next hash core.

[0187] S505. Save the calculation result. chain_idx = the original hash chain index of the current task, and z_array[chain_idx] = the calculation result.

[0188] S506. Update the count value of the completion counter, completed_count++.

[0189] S507. Determine whether the queue head pointer meets the condition, that is, whether queue_head < p is satisfied. If it is satisfied, the queue is not empty, and jump to S508; otherwise, the queue is empty, and jump to S509.

[0190] S508. Immediately allocate a new task, that is, take out task_queue[queue_head], allocate it to the core id, start the Hash core calculation, and queue_head++.

[0191] S509. Update the status of the Hash core to idle, that is, core_state[core_id] = IDLE, and the core becomes idle.

[0192] S510. The calculation results of all hash chains have been completed, and z[0], z[1],..., z2[p - 1] have been completed.

[0193] S511. Summarize the final result according to the algorithm specification and operation type, and verify the signature: calculate the candidate one-time public key (LM-OTS → Kc, WOTS+ → pk_sig), and sign: assemble the signature components.

[0194] 3.4.2 Single-core State Transition Each hash core undergoes the following state transitions during the dynamic scheduling process: IDLE (idle) - The hash core is not performing any tasks and is waiting to be assigned by the scheduler. All cores are in this state after system initialization.

[0195] BUSY (calculating) - The hash core is performing hash chain iterative calculations and continuously performing T_i hash operations (LM-OTS: tmp = H(I‖q‖i‖j‖tmp); WOTS+: tmp = F(PK.seed, ADRS, tmp)).

[0196] FINISHED (completed) - The hash core has completed all iterations of the current task and is waiting for the scheduler to take away the results and decide the next operation.

[0197] State transition paths (a total of 5):

[0198] Figure 6 It is a schematic diagram of the state transition of a hash kernel provided by an embodiment of the present application. Refer to Figure 6 , after the system is initialized, the hash kernel state is idle. When queue_head < p, the scheduler allocates a hash chain, and the hash kernel state is in computing. After the hash calculation is completed, the hash kernel state is completed. If queue_head < p, a new hash chain is immediately allocated and the calculation is started. If queue_head >= p, the hash kernel state is marked as idle, waiting for all hash kernels to complete the calculation.

[0199] 3.4.3 Multi-core Concurrent Execution Timing Taking the example of 3 hash kernels processing 6 hash chains, with the iteration counts being [50, 200, 30, 180, 10, 100], it shows the specific execution process of dynamic scheduling and the task switching moments of each core.

[0200] Figure 7 It is a schematic diagram of the multi-hash kernel concurrent execution timing provided by an embodiment of the present application. Refer to Figure 7 , and the key event timeline is explained.

[0201] T = 0: The scheduler allocates hash chain 0, hash chain 1, and hash chain 2 to hash kernel 0, hash kernel 1, and hash kernel 2 respectively, and the three hash kernels start the calculation simultaneously.

[0202] T = 30: Hash kernel 2 finishes hash chain 2 (only 30 iterations) first. The scheduler immediately takes out hash chain 3 (180 iterations) from the hash chain queue and allocates it to hash kernel 2, and hash kernel 2 seamlessly starts the new task.

[0203] T = 50: Hash kernel 0 finishes hash chain 0 (50 iterations). The scheduler allocates hash chain 4 (10 iterations), and hash kernel 0 continues to work.

[0204] T = 60: Hash kernel 0 finishes hash chain 4 (only 10 iterations). The scheduler allocates hash chain 5 (100 iterations), and hash kernel 0 continues to work.

[0205] T = 160: Hash kernel 0 finishes hash chain 5. At this time, the task queue is empty (all 6 hash chains have been allocated), and hash kernel 0 enters the IDLE state.

[0206] T = 200: Hash kernel 1 finishes hash chain 1 (200 iterations). The queue is empty, and core 1 enters IDLE.

[0207] T = 210: Hash kernel 2 finishes hash chain 3 (180 iterations). All 6 hash chains are completed, completed_count = 6 = p.

[0208] Timing Analysis: Actual workload of each hash core: Core 0: 50+10+100=160 times, Core 1: 200 times, Core 2: 30+180=210 times.

[0209] Total effective iterations = 50 + 200 + 30 + 180 + 10 + 100 = 570 times.

[0210] Hardware utilization rate = 570 / (3×210) = 570 / 630 ≈ 90.5%.

[0211] Hash core 0 is idle for 50 cycles after T=160, hash core 1 is idle for 10 cycles after T=200, and hash core 2 runs at full capacity until T=210. If the hash chain is allocated in descending order of iteration count, the utilization rate can be further increased to over 95%.

[0212] The core advantage of dynamic scheduling is clearly evident from the timeline: hash chain 2 requires only 30 iterations, and hash chain 4 requires only 10 iterations. If batch synchronization is used, the hash kernels processing these short hash chains must wait in vain until the longest hash chain in the batch is completed before starting the next batch of tasks. However, under dynamic scheduling, the hash kernels immediately receive new tasks after completing a short hash chain, and the idle time is compressed to the very short tail of the final stage.

[0213] 3.4.4 Scheduler Data Structure Figure 8 This is a schematic diagram of a scheduler data structure provided in an embodiment of this application. See also... Figure 8 Data structure description (where p is the total number of hash chains, N is the number of hash cores, and n is the hash output length (bytes)): 1) task_queue[p]: The task queue, also known as the hash chain queue, stores all p hash chain tasks to be processed. Each hash chain task contains the chain index chain and the iteration number iter; 2) queue_head: The head pointer of the queue, pointing to the next hash chain task to be assigned, initially set to 0; 3) completed_count: A completion counter that records the number of hash chains that have been computed and is used to determine whether all hash chains have been completed. 4) cores[N]: Records the current busy (busy / idle) status of N hash cores and the hash chain task being processed (task_ptr); 5) z_array[p][n]: Stores the calculation results z of each hash chain (p hash chains, each with n bytes), stored according to the original chain index.

[0214] 3.4.5 Task Assignment and Switching Figure 9 It is a schematic flow diagram of hash chain allocation and switching provided by an embodiment of the present application. Refer to Figure 9 , specifically, it may include: S901, the hash core K completes the current task.

[0215] S902, obtain the current task information chain_idx = cores[k].current_task.chain_idx, that is, obtain the original hash chain number (chain index) corresponding to this task.

[0216] S903, save the calculation result z_array[chain_idx]= cores[k].result, and write the result to the corresponding position in the result array regardless of the execution order.

[0217] S904, update the count value of the completion counter, completed_count++.

[0218] S905, determine whether the task queue is non-empty (queue_head<p). If it is empty, jump to S907; otherwise, jump to S906.

[0219] S906, immediately allocate a new hash chain, take out task_queue[queue_head] and allocate it to this core, configure the hash core parameters (hash chain index, starting hash value, number of iterations), start the calculation, and queue_head++.

[0220] S907, set the busy flag of this hash core to 0, cores[k].busy = 0, and this hash core enters the idle state, waiting for all tasks to be completed S908, return and continue polling other hash cores.

[0221] 3.5 Timing schematic diagram Taking the processing of W8 parameters (34 hash chains) by 3 hash cores as an example, assume that the number of iterations of 9 of these hash chains (in the original order) is: [50, 200, 30, 180, 10, 255, 100, 80, 150], and after descending order sorting, it is: [255, 200,180, 150, 100, 80, 50, 30, 10], Figure 10 It is a comparison schematic diagram of various scheduling methods provided by an embodiment of the present application. Refer to Figure 10 , Figure 10 Respectively show the execution processes of three scheduling methods.

[0222] Define the following performance indicators to quantify the efficiency differences of the three scheduling methods: Total iterations: The sum of the number of iterations across all hash chains, representing the total amount of work actually required. This value is independent of the scheduling method and represents a fixed amount of effective computation. In the example, the total number of iterations for 9 hash chains = 50 + 200 + 30 + 180 + 10 + 255 + 100 + 80 + 150 = 1055.

[0223] Total completion time: The time from the start of scheduling to the completion of computation for all hash chains (i.e., the moment when the last hash core completes the last hash chain). Total completion time for batch synchronization T_batch = 605; total completion time for fixed allocation T_fixed = 445; total completion time for dynamic scheduling T_dynamic = 360.

[0224] Hardware utilization: The proportion of actual effective computation to total available computing resources. Utilization = Total iterations / (Number of hash cores × Total completion time) × 100%; where the denominator "Number of hash cores × Total completion time" represents the total number of computation cycles available for all hash cores throughout the process. Utilization reflects how many of these cycles are used for effective hash computation, and the unutilized portion is the idle waiting time of the hash cores. Batch synchronization utilization = 1055 / (3 × 605) = 1055 / 1815 ≈ 58.1%; Fixed allocation utilization = 1055 / (3 × 445) = 1055 / 1335 ≈ 79.0%; Dynamic scheduling utilization = 1055 / (3 × 360) = 1055 / 1080 ≈ 97.7%. Speedup: The ratio of the total completion time of each method to the total completion time of dynamic scheduling, measuring the performance advantage of dynamic scheduling. The relative batch synchronization speedup = T_batch / T_dynamic = 605 / 360 ≈ 1.68x; the relative fixed allocation speedup = T_fixed / T_dynamic = 445 / 360 ≈ 1.24x; the theoretical optimal time = total number of iterations / number of hash cores = 1055 / 3 ≈ 352. The dynamic scheduling result (360) of this application embodiment is very close to the theoretical limit.

[0225] 3.6 Simulation Comparison of Three Scheduling Methods To quantify the performance advantages of dynamic scheduling over batch synchronization and fixed allocation schemes, extensive simulation tests were conducted for various combinations of W parameters.

[0226] Test conditions: N=4 hash kernels, 100,000 message samples are randomly generated for each group of W parameters, and the coef values ​​of each hash chain follow a uniform distribution in [0, 2^w-1] (covering both signature and signature verification scenarios). The simulation logic for the three scheduling methods is as follows: Batch synchronous parallelism: Divide p hash chains into p hash chains in their original order. p / N Each batch starts N hash chains, and the next batch starts only after the slowest hash chain in the batch has completed.

[0227] Fixed-allocation parallelism: p hash chains are distributed to N hash cores in their original order (the i-th hash chain is assigned to the i-th mod N-th hash core). Each hash core executes all the hash chains it is assigned to sequentially. The total completion time is determined by the hash core with the heaviest load.

[0228] Dynamic scheduling (unordered): The task queue is maintained in the original order, and the next task in the queue is assigned to the earliest idle hash core each time, that is, the task is assigned as soon as it is completed.

[0229] Utilization rate = Total effective iterations / (N × Total completion time).

[0230] For a comparison of hardware utilization (n=32), please refer to Table 6 below.

[0231] Table 6

[0232] For a comparison of hardware utilization (n=24), please refer to Table 7 below.

[0233] Table 7

[0234] Note: W1 / W2 / W4 / W8 in the table are the parameter names for LM-OTS. WOTS+ (XMSS / SLH-DSA) uses different w definitions, but the iteration behavior is equivalent: the iteration range of WOTS+ w=16 (the values ​​of all standard parameter sets of XMSS and SLH-DSA) is 0~15. When n=32, the number of hash chains is 67; when n=24, the number of hash chains is 51 (the same as the number of hash chains in LM-OTS W4 for the corresponding n value); when n=16, the number of hash chains is 35 (unique to SLH-DSA, LM-OTS does not have this n value). You can directly refer to the conclusion of row W4.

[0235] Simulation results show that dynamic scheduling significantly outperforms batch synchronization and fixed allocation schemes under both hash lengths (n=32 and n=24) and all W parameters. a) Compared to batch synchronous parallelism: dynamic scheduling improves hardware utilization from 53-60% to 92-99%. Batch synchronization wastes a lot of computing resources in each batch due to the slowest hash chain waiting, while dynamic scheduling completely eliminates batch waiting through the "as soon as it's completed" mechanism.

[0236] b) Compared to fixed allocation in parallel processing: Dynamic scheduling improves hardware utilization from 80-89% to 92-99%. While fixed allocation eliminates batch waiting, static round-robin allocation cannot guarantee balanced load across cores; the core with the heaviest load determines the total completion time. Dynamic scheduling naturally achieves load balancing through on-demand allocation.

[0237] c) The advantages of dynamic scheduling over fixed allocation become more significant as the W parameter increases: under W8, dynamic scheduling improves utilization by about 11 percentage points compared to fixed allocation, and under W4, it improves by about 10 percentage points, demonstrating the advantage of dynamic scheduling in load balancing when the number of iterations differs greatly.

[0238] d) When n=24, the p value is smaller (e.g., W8 has only 26 hash chains). The p / N ratio decreases, resulting in a smaller scheduling space. However, dynamic scheduling can still maintain a utilization rate of over 91%, far exceeding the 59% of batch synchronization and the 80% of fixed allocation.

[0239] e) SLH-DSA's unique feature is that when n=16, the number of hash chains is further reduced (WOTS+ has only 35 hash chains when w=16), the p / N ratio is the lowest, and the advantage of dynamic scheduling is still significant. See the conclusion in line W4 for reference.

[0240] f) Even with the W1 parameter having the smallest difference in the number of iterations, dynamic scheduling can still improve the utilization rate to over 98%, proving the universality of the solution.

[0241] 4. Sorting Optimization Analysis Building upon the dynamic scheduling mechanism, a task sorting optimization strategy can be further introduced, namely, arranging the task queue in descending order of iteration count. This section analyzes the significance and benefits of sorting optimization based on dynamic scheduling.

[0242] 4.1 Necessity Analysis of Sorting Optimization Dynamic scheduling solves the batch waiting problem, but the total completion time is still limited by the total workload of the last hash core to complete. Without sorting, the following situation may occur: a core is assigned a long task (with many iterations) later in the process, while other cores have completed all their tasks, but the core is still processing the long task, causing tail waiting and reducing overall efficiency.

[0243] The core idea of ​​sorting optimization is to prioritize long tasks (with more iterations) to start them as early as possible, and use short tasks (with fewer iterations) to fill the gaps at the end, so that the workload of each core tends to be balanced and they are completed almost simultaneously.

[0244] 4.2 Marginal Revenue Analysis of Ranking Optimization To quantify the actual benefits of sorting optimization in dynamic hash chain scheduling, extensive local simulation tests were conducted for each combination of W parameters: For each parameter group (W1 / W2 / W4 / W8), 100,000 message samples were randomly generated, and the coef values ​​of each hash chain for each message followed a uniform distribution on [0, 2^w-1] (covering both signature and signature verification scenarios). Under the configuration of N=4 hash cores, two dynamic scheduling strategies, namely unsorted (original order) and descending order, were simulated, and the average hardware utilization was statistically analyzed.

[0245] Referring to Tables 8 and 9 below, the test results show that the marginal benefit of sorting optimization based on dynamic scheduling mainly depends on the following two factors: 4.2.1 Ratio of task quantity to core quantity (p / N) Table 8

[0246] 4.2.2 Degree of difference in the number of iterations Table 9

[0247] 4.2.3 Simulation Verification and Comprehensive Benefit Estimation Test conditions: N = 4 hash kernels, 100,000 message samples are randomly generated for each group of W parameters, and the coef values ​​of each hash chain follow a uniform distribution in [0, 2^w-1]. Two dynamic scheduling strategies, unsorted and descending sorted, are simulated respectively. Utilization = Total effective iterations / (N × Total completion time).

[0248] Note: W1 / W2 / W4 / W8 in Table 10 are the parameter names for LM-OTS. WOTS+ (XMSS / SLH-DSA) uses different w definitions, but the iteration behavior is equivalent: the iteration range of WOTS+ w=16 (the values ​​of all standard parameter sets of XMSS and SLH-DSA) is 0~15. When n=32, the number of hash chains is 67; when n=24, the number of hash chains is 51 (the same as the number of hash chains in LM-OTS W4 at the corresponding n value); when n=16, the number of hash chains is 35 (unique to SLH-DSA, LM-OTS does not have this n value). You can directly refer to the conclusion of row W4.

[0249] Table 10

[0250] Table 10 above shows the simulation results for n=32. When n=24, the number of hash chains p for each parameter set is smaller (W1:200, W2:101, W4:51, W8:26). The lower p / N ratio makes the task allocation order have a greater impact on the final completion time. Therefore, the marginal benefit of sorting optimization is slightly higher than that for the corresponding parameter set when n=32, and the overall trend is consistent. SLH-DSA uniquely features a further decrease in the number of hash chains when n=16 (WOTS+ has only 35 hash chains when w=16), the lowest p / N ratio, and the most significant marginal benefit of sorting optimization.

[0251] 4.3 Implementation Cost Analysis Time complexity: Simple sorting algorithms (such as insertion sort): O(p²), p is at most 2^65, and in the worst case, it takes about p(p-1) / 2 ≈ 34980 comparisons. Efficient sorting algorithms (such as quicksort): O(p log p), p is at most 2^65, and it takes about p•log2(p) ≈ 2133 comparisons. Since the number of comparisons in sorting is much smaller than the total computation of hash chain iteration (thousands to tens of thousands of hash operations), the sorting overhead is negligible compared to the total time spent on signature verification.

[0252] Space complexity: Insertion sort: O(1) extra space, quick sort: O(log p) recursive stack space, only need to swap task structures, no extra array required.

[0253] Code complexity: Adding sorting code does not affect the structure of the original dynamic scheduling logic.

[0254] 4.4 Suggestions for Sorting Optimization Based on the above analysis, the following implementation suggestions are proposed: Sorting optimization is enabled by default: Sorting has a very low implementation cost and will not degrade performance even in the worst case, so it is recommended to enable it by default.

[0255] Configurable sorting switch: Provides configuration options to allow sorting to be turned off in the following scenarios: W1 / W2 parameter sets: applications with small differences in the number of iterations, limited sorting benefits, and sensitivity to initialization latency: although sorting takes very little time, some real-time systems may need to minimize initialization time.

[0256] Sorting algorithm selection: Insertion sort: software implementation, simple code, performance is sufficient when p is small; Quick sort: software implementation, used when p is large or when sorting time is sensitive.

[0257] Synergy with dynamic scheduling: Sorting optimization and dynamic scheduling are complementary: For dynamic scheduling, solving the batch waiting problem is the main source of performance improvement (+33-46% utilization); for sorting optimization, solving the tail long task problem is a supplementary optimization (+0-6% utilization). The combination of the two can make hardware utilization reach more than 99%, close to the theoretical limit.

[0258] 4.5 Summary of Performance Improvements Table 11

[0259] As shown in Table 11 above, dynamic scheduling is the core optimization, contributing the main performance improvement, while sorting optimization is the icing on the cake, providing additional performance benefits at a very low cost. In actual products, using both optimization strategies simultaneously can achieve the best performance.

[0260] 5 Other implementation optimizations 5.1 Rapid processing of zero-iteration tasks When the number of iterations T_i of a hash chain is 0 (i.e., when verifying a signature, coef(i) = 2^w - 1, or when signing, coef(i) = 0), the input value is directly the output result, without any hash calculation.

[0261] Solution: During the initial allocation phase, if a task's iteration count is detected to be 0, its input value is directly copied as the result z[i], and the counter D is incremented by 1. This task does not occupy hash kernel resources. By skipping the zero-iteration task, scheduling efficiency can be further improved.

[0262] 5.2 Batch Status Detection and Task Allocation When multiple hash cores complete their tasks at the same time or within a very short time interval, batch processing can be used to reduce scheduling overhead. Processing method: In each round of detection, the scheduler first traverses all N cores to collect the set of completed core IDs F = {k | core k has completed}, and then sequentially performs the following operations for each core in F: save the result → assign a new task → start the computation. This batch processing avoids the overhead of repeated traversal caused by processing one core at a time, and is particularly effective when the number of cores N is large.

[0263] 5.3 Scheduling Overhead Analysis Each time a task switches, the scheduler needs to perform the following: check the kernel completion status, save the calculation results, load the new task parameters, and start the calculation, totaling software overhead of approximately several clock cycles. For W4 / W8 parameters (each hash chain iterates tens to hundreds of times), the overhead of a single scheduling operation is negligible compared to the hash chain computation time. However, for W1 parameters (each hash chain iterates only 0 or 1 times), the overhead of a single scheduling operation may approach or even exceed the hash chain computation itself. Therefore, for extremely short hash chain scenarios such as W1, it is necessary to evaluate the ratio of scheduling overhead to computation time, and if necessary, batch synchronization or direct sequential execution can be used to avoid the additional overhead caused by frequent scheduling.

[0264] 6. Complete algorithm flow of dynamic scheduling + sorting optimization Taking LM-OTS signature verification as an example (the signature process is similar, only the calculation method of the number of iterations and the source of the initial value are different), the complete algorithm flow of multi-core dynamic scheduling is as follows:

[0265] For the signature scenario, the number of iterations in step 2 is changed to T_i = a_i, and in step 5, each hash chain iterates from the private key x[i] to obtain the signature component y[i].

[0266] For the WOTS+ (SP 800-208 XMSS / FIPS 205 SLH-DSA) scenario, in step 2, the base_2b function is used to replace the coef function to extract the coefficient msg[i]. In step 5, the hash function is replaced with the hash chain function F(PK.seed, ADRS, tmp) of WOTS+. In step 6, the public key calculation is replaced with the compression function pk = T_len(PK.seed, ADRS, tmp[0]‖tmp[1]‖...‖tmp[len-1]). The rest of the scheduling logic is exactly the same.

[0267] 7. Calling Scenarios in XMSS and SLH-DSA 7.1 Frequency of WOTS+ calls in XMSS and SLH-DSA A single signature / verification operation in XMSS involves one WOTS+ call, while XMSS^MT (a multi-tree variant) involves d WOTS+ calls (where d is the tree level). Taking the XMSS^MT parameter XMSSMT-SHA2_20 / 4_256 as an example, d=4, a single signature / verification operation involves 4 WOTS+ calls. Each of these calls independently presents a hash chain imbalance problem, amplifying the benefits of dynamic scheduling.

[0268] A single signature / verification of an SLH-DSA involves multiple WOTS+ calls: (1) During signing: WOTS+ signing is performed once at each level of the hypertree XMSS tree, for a total of d WOTS+ signings (d is the hypertree level). The message signed by the bottom-level WOTS+ is the FORS public key, and the message signed by the upper-level WOTS+ is the root of the lower-level XMSS tree. FORS itself does not use WOTS+.

[0269] (2) When verifying the signature: public key recovery needs to be performed on each WOTS+ signature in the signature, d times in the same way.

[0270] Each WOTS+ call independently presents a hash chain imbalance problem, thus the benefits of dynamic scheduling are amplified by a factor of d in SLH-DSA. Taking SLH-DSA-SHA2-128s as an example, d=7, a single signature / verification involves 7 WOTS+ calls, each benefiting from dynamic scheduling.

[0271] 7.2 SLH-DSA Whole-Process Visa Application and Dynamic Scheduling Functions The SLH-DSA verification process (FIPS 205 Algorithm 22: slh_verify) includes the following main steps:

[0272] In the above process, step (3a) is the most computationally intensive part, involving parallel iterations of len hash chains at each layer, with uneven iteration counts for each chain. The dynamic scheduling scheme of this application applies to the WOTS+ public key recovery process at each layer, accelerating d independent hash chain parallel computations.

[0273] 8. Beneficial effects of the embodiments of this application This application's embodiments optimize task allocation for multi-core hash hardware accelerators through a dynamic scheduling mechanism. Referring to Table 12, the following significant beneficial effects are achieved in signature and verification scenarios of LMS, XMSS, and SLH-DSA: (1) Hardware utilization rate has been greatly improved (Taking n=32 and 4 cores as an example, 10,000 sets of random samples were used for simulation verification. When n=24, the p-values ​​were different but the pattern was the same.) Table 12

[0274] (2) Signature and verification performance has been significantly improved. The utilization data shows that the performance improvement (ratio of utilization) of dynamic scheduling + sorting compared to batch synchronization is: approximately 1.86x for W1, approximately 1.75x for W2, approximately 1.65x for W4, and approximately 1.65x for W8. Significant improvements are achieved under all W parameters.

[0275] The number of hash chain iterations in the signing process is complementary to that in the verification process (the sum is always equal to 2^w-1), and the degree of imbalance is the same. Therefore, the improvement factor of dynamic scheduling on signing is the same as that on verification.

[0276] (3) Wide applicability Multiple Algorithm Support: Applicable to all parameter sets (W1 / W2 / W4 / W8) of LM-OTS (LMS, RFC 8554) and all parameter sets (w=4 / 16 / 256) of WOTS+ (XMSS, RFC 8391 / SLH-DSA, FIPS 205); Universal Signature and Verification: The same scheduling scheme is applicable to hash chain computation in both the signing and verification processes; Scalable Cores: Applicable with 2, 4, 8, and 16 cores, with more cores resulting in better performance; Hardware Independence: Requires only a standard hash accelerator interface and no special hardware support; Software and Hardware Collaboration: The scheduling logic can be implemented in software or hardware, flexibly adapting to different platforms; Cross-Standard Coverage: Unified coverage of the two major post-quantum signature standards, NIST SP 800-208 (LMS / XMSS) and FIPS 205 (SLH-DSA).

[0277] (4) Controllable implementation complexity Low pre-computation overhead: The iteration count only requires traversing the extended message once, with a complexity of O(p); negligible sorting overhead: p is at most 265, and simple sorting is sufficient, with an overhead far less than that of hash calculation; simple state management: the scheduler only needs to maintain a small amount of state information for each hash core, with a memory usage of approximately 100 bytes / core; no complex synchronization: completion is detected by polling or interruption, without the need for complex locking mechanisms.

[0278] (5) Facilitate the deployment of post-quantum cryptography This application enables the LMS, XMSS, and SLH-DSA algorithms to achieve near-theoretical performance on multi-core hardware acceleration platforms, alleviating performance concerns regarding the deployment of post-quantum cryptography algorithms. In particular, SLH-DSA, as a stateless scheme, has a wider range of applications. The embodiments in this application help promote the widespread application of post-quantum signature algorithms in high-performance signature and verification scenarios (such as CA certificate issuance and verification, secure firmware boot, blockchain nodes, security gateways, code signing, etc.).

[0279] This application primarily employs a dynamic scheduling + descending order sorting scheme. In addition, the following alternative or supplementary schemes are also available: (1) Work Stealing Scheme Idle cores actively "steal" tasks from the task queues of busy cores: Each core maintains a local task queue and takes tasks from the tail of other cores' queues when idle, resulting in natural load balancing, which is suitable for distributed systems, multi-CPU systems, or distributed computing environments.

[0280] (2) Parallel pipeline scheme Decomposing the hash chain computation into multiple pipeline stages: multiple iterations of a hash chain are distributed across multiple cores and executed in a pipelined manner. Data dependencies between iterations (the input of each iteration is the output of the previous iteration) cause pipeline bubbles. This approach is suitable for scenarios where the number of iterations of a single hash chain is extremely large and the number of cores is sufficient.

[0281] (3) Batch + Dynamic Hybrid Scheme The first few batches use batch synchronization (reducing scheduling overhead), and the later batches use dynamic scheduling (improving tail efficiency): when the number of remaining tasks is less than the threshold, switch to dynamic scheduling mode to achieve a balance between scheduling overhead and efficiency. This is suitable for software implementations where scheduling overhead cannot be ignored.

[0282] (4) Hardware scheduler scheme By fully hardwareizing the scheduling logic and designing dedicated scheduling or sorting circuits, task allocation with minimal overhead and scheduling latency can be achieved, resulting in maximum efficiency. This approach is suitable for dedicated ASIC chips with extremely high performance requirements.

[0283] The dynamic scheduling + descending order sorting scheme of this application achieves an optimal balance between complexity, versatility, and efficiency improvement, making it particularly suitable for general-purpose cryptographic chips equipped with multiple hash cores. This scheme covers signature and verification scenarios for both LM-OTS and WOTS+ hash chain structures. Depending on the specific application scenario, it can be optimized and extended by combining with the aforementioned alternative schemes. Furthermore, this scheduling framework is universal and can be applied to any new hash chain iteration-based signature algorithms that emerge in the future.

[0284] This application provides a hash chain scheduling and execution device 110, such as... Figure 11 As shown, the hash chain scheduling execution device 110 includes...

[0285] in: Storage unit 1101 is used to store the hash value obtained from the hash operation into the hash result according to the hash chain index corresponding to the currently allocated hash chain when at least one target hash kernel completes the hash operation on the currently allocated hash chain; the hash chain index is used to determine the storage location of the hash value in the hash result; The first processing unit 1102 is used to continue allocating hash chains for at least one target hash kernel based on the updated value of the queue head pointer and the hash chain queue, and to update the updated value of the queue head pointer; the updated value of the queue head pointer represents the first hash chain to be allocated in the hash chain queue when the hash chain is allocated next. The generation unit 1103 is used to perform hash operations on the newly allocated hash chains based on at least one target hash kernel until all hash chains in the hash chain queue have been allocated and hash operations have been completed on all hash chains, and then obtains the hash result.

[0286] In some embodiments, the first processing unit is further configured to, for each target hash core, determine a first hash chain to be allocated from the hash chain queue based on the updated value of the queue head pointer, and allocate the first hash chain to be allocated to the target hash core; and increment the updated value of the queue head pointer by one.

[0287] In some embodiments, the hash chain has a corresponding number of iterations; the hash chain scheduling and execution device further includes: The acquisition unit is used to acquire the initial value of the first hash chain to be allocated when the number of iterations of the first hash chain to be allocated is the same as the preset value; the preset value indicates that the hash chain does not undergo hash iteration. The second processing unit is used to store the initial value into the hash result according to the hash chain index of the first hash chain to be allocated, and to increment the update value of the queue head pointer by one, and enter the step of determining the first hash chain to be allocated from the hash chain queue based on the update value of the queue head pointer; The first processing unit is also used to allocate the first hash chain to the target hash core when the number of iterations of the first hash chain to be allocated is different from the preset value.

[0288] In some embodiments, the first processing unit is further configured to determine at least one second hash chain to be allocated from the hash chain queue based on the number of at least one target hash core and the number of remaining hash chains in the hash chain queue; allocate at least one second hash chain to be allocated for at least one target hash core; and update the update value of the queue head pointer based on the update value of the queue head pointer and the number of at least one second hash chain to be allocated.

[0289] In some embodiments, the hash chain scheduling and execution apparatus further includes: The first update unit is used to update the count value of the initialized completion counter based on the number of hash values. The generation unit is also used to obtain the updated count value of the completion counter when the hash operation has been completed on all hash chains in the hash chain queue; and to obtain the hash result when the updated count value of the completion counter is the same as the number of all hash chains.

[0290] In some embodiments, the hash chain scheduling and execution apparatus further includes: The first initialization unit is used to initialize the queue head pointer and obtain the initial value corresponding to the queue head pointer; The second update unit is used to update the initial value corresponding to the queue head pointer based on the number of hash cores and the total number of hash chains, after the initial allocation is completed for each hash core based on the hash chain queue, so as to obtain the updated value of the queue head pointer.

[0291] In some embodiments, the hash chain has a corresponding number of iterations; the hash chain scheduling and execution device further includes: The determination unit is used to skip the target hash chain and determine the currently assigned hash chain for each hash core when the initial allocation is performed for each hash core based on the hash chain queue and there is a target hash chain in the hash chain queue with the same number of iterations as the preset value; the preset value indicates that the hash chain does not undergo hash iteration.

[0292] In some embodiments, the hash chain scheduling and execution apparatus further includes: The second initialization unit is used to initialize the kernel state corresponding to each hash kernel to obtain the initialization state; The third update unit is used to update the kernel state after the initial allocation of each hash kernel is completed based on the hash chain queue; The fourth update unit is used to update the kernel state corresponding to at least one target hash kernel to the initialization state when at least one target hash kernel has completed the hash operation on the currently allocated hash chain and the hash chain queue is empty.

[0293] In some embodiments, the hash chain queue is an unsorted hash chain queue or a hash chain queue sorted in descending order; the hash chain queue sorted in descending order is obtained by sorting all hash chains in the unsorted hash chain queue in descending order based on the number of iterations of each hash chain in the unsorted hash chain queue.

[0294] It should be noted that the units included in the hash chain scheduling and execution device provided in this application embodiment can be implemented by a processor in an electronic device; of course, they can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP), or a field-programmable gate array (FPGA), etc.

[0295] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0296] It should be noted that, in the embodiments of this application, if the above-described hash chain scheduling and execution method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0297] This application provides an electronic device that can implement the hash chain scheduling and execution device described above.

[0298] In one example, reference Figure 12 As shown, the electronic device 120 includes: a processor 1201, at least one communication bus 1202, a user interface 1203, at least one external communication interface 1204, and a memory 1205. The communication bus 1202 is configured to enable communication between these components. The user interface 1203 may include a display screen, and the external communication interface 1204 may include standard wired and wireless interfaces.

[0299] The memory 1205 is configured to store instructions and applications executable by the processor 1201, and can also cache data to be processed or already processed by the processor 1201 and various modules in the electronic device (e.g., image data, audio data, voice communication data and video communication data), which can be implemented by flash memory or random access memory (RAM).

[0300] This application provides a storage medium, namely a computer-readable storage medium, on which a computer program or instructions are stored. When the computer program or instructions are executed by a processor, they implement the steps in any of the polynomial-based acceleration devices provided in the above embodiments.

[0301] This application provides a computer program product, which includes a computer program or instructions. When the computer program or instructions are executed by a processor, they implement the steps in any of the polynomial-based acceleration devices provided in the above embodiments.

[0302] It should be noted that the descriptions of the above embodiments of storage media, devices, apparatuses, and program products are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of storage media, devices, apparatuses, and program products of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0303] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0304] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0305] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0306] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0307] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0308] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0309] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0310] The above are merely embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for scheduling and executing a hash chain, characterized in that, The method includes: When at least one target hash kernel completes a hash operation on the currently assigned hash chain, the hash value obtained from the hash operation is stored in the hash result according to the chain index corresponding to the currently assigned hash chain; the chain index is used to determine the storage location of the hash value in the hash result. Based on the updated value of the queue head pointer and the hash chain queue, hash chains continue to be allocated for the at least one target hash core, and the updated value of the queue head pointer is updated; the updated value of the queue head pointer represents the first hash chain to be allocated in the hash chain queue at the next hash chain allocation. Hash operations are performed on the newly allocated hash chains based on the at least one target hash core until all hash chains in the hash chain queue have been allocated and hash operations have been completed on all hash chains, at which point the hash result is obtained.

2. The method based on claim 1, characterized in that, The queue head pointer-based update value and hash chain queue continue to allocate hash chains for the at least one target hash core, and update the queue head pointer update value, including: For each target hash core, based on the updated value of the queue head pointer, a first hash chain to be allocated is determined from the hash chain queue, and the first hash chain to be allocated is allocated to the target hash core; Increment the value of the queue head pointer by one.

3. The method based on claim 2, characterized in that, The hash chain has a corresponding number of iterations; the method further includes: If the number of iterations of the first hash chain to be assigned is the same as the preset value, the initial value of the first hash chain to be assigned is obtained; the preset value indicates that the hash chain does not undergo hash iteration. According to the chain index of the first hash chain to be allocated, the initial value is stored in the hash result, and the updated value of the queue head pointer is incremented by one, and then the step of determining the first hash chain to be allocated from the hash chain queue based on the updated value of the queue head pointer is entered. The step of allocating the first hash chain to be allocated to the target hash core includes: If the number of iterations of the first hash chain to be allocated is different from the preset value, the first hash chain to be allocated is assigned to the target hash core.

4. The method based on claim 1, characterized in that, The queue head pointer-based update value and hash chain queue continue to allocate hash chains for the at least one target hash core, and update the queue head pointer update value, including: Based on the number of the at least one target hash core and the number of remaining hash chains in the hash chain queue, at least one second hash chain to be allocated is determined from the hash chain queue; Assign the at least one second hash chain to be assigned to the at least one target hash core; The update value of the queue head pointer is updated based on the updated value of the queue head pointer and the number of the at least one second unassigned hash chain.

5. The method according to claim 1, characterized in that, After storing the hash value obtained from the hash operation into the hash result according to the chain index corresponding to the currently allocated hash chain, the method further includes, The count value of the initialization completion counter is updated based on the number of hash values. The step of obtaining the hash result after performing hash operations on all hash chains in the hash chain queue includes: If the hash operation has been completed for all hash chains in the hash chain queue, obtain the updated count value of the completion counter; The hash result is obtained when the updated completion counter value is the same as the number of all hash chains.

6. The method according to claim 1, characterized in that, The method further includes: The queue head pointer is initialized to obtain the initial value corresponding to the queue head pointer; After initial allocation is completed for each hash core based on the hash chain queue, the initial value corresponding to the queue head pointer is updated based on the number of hash cores and the number of all hash chains to obtain the updated value of the queue head pointer.

7. The method according to claim 1, characterized in that, The hash chain has a corresponding number of iterations; the method further includes: If an initial allocation is performed for each hash core based on the hash chain queue, and there is a target hash chain in the hash chain queue with the same number of iterations as the preset value, the target hash chain is skipped, and the currently allocated hash chain is determined for each of the hash cores; the preset value indicates that the hash chain does not undergo hash iteration.

8. The method according to claim 1, characterized in that, The method further includes: Initialize the kernel state corresponding to each hash kernel to obtain the initialization state; The state of the cores is updated after the initial allocation of each hash core is completed based on the hash chain queue. When the at least one target hash core completes the hash operation on the currently allocated hash chain and the hash chain queue is empty, the core state corresponding to the at least one target hash core is updated to the initialization state.

9. The method according to any one of claims 1-8, characterized in that, The hash chain queue is either an unsorted hash chain queue or a hash chain queue sorted in descending order. The hash chain queue sorted in descending order is obtained by sorting all hash chains in the unsorted hash chain queue in descending order based on the number of iterations of each hash chain in the unsorted hash chain queue.

10. A scheduling and execution device for a hash chain, characterized in that, The device includes: A storage unit is used to store the hash value obtained by the hash operation into the hash result according to the chain index corresponding to the currently allocated hash chain when at least one target hash kernel completes the hash operation on the currently allocated hash chain; the chain index is used to determine the storage location of the hash value in the hash result; The first processing unit is used to continue allocating hash chains for the at least one target hash core based on the updated value of the queue head pointer and the hash chain queue, and to update the updated value of the queue head pointer; the updated value of the queue head pointer represents the first hash chain to be allocated in the hash chain queue at the next hash chain allocation. A generation unit is used to perform hash operations on newly allocated hash chains based on the at least one target hash core until all hash chains in the hash chain queue have been allocated and hash operations have been completed on all hash chains, and then obtain the hash result.

Images