Message signing method

Abstract

The application provides a message signature method applied to a chip, comprising: initializing a T context of a tree hash function T function; the T context comprising: a cache field value, a data size field value, and an iteration field value; dividing the initialized cache field value and a plurality of node hash values according to a predefined data block size to obtain a plurality of data blocks, and updating the initialized cache field value and the initialized data size field value in the dividing process; in the case that the updated cache field value is empty and the updated data size field value is equal to a total data size, performing a hash iteration operation on the plurality of data blocks, and updating the initialized iteration field value in the hash iteration operation process; and determining a first signature value based on the updated iteration field value.

Description

Technical Field

[0001] This application relates to digital signature algorithm technology, and more particularly to a message signing method. Background Technology

[0002] With the development of quantum computing, post-quantum signature algorithms, which do not require complex mathematical structures and possess strong resistance to quantum attacks, are widely used. For example, stateless hash-based digital signature algorithms... Based DigitalSignature Algorithm, SLH-DSA).

[0003] When determining message signatures based on the SLH-DSA algorithm, the relevant technology stores the hash values ​​of the root nodes of k FORS trees, which contains k*n bytes of data, and also needs to store the hash values ​​of 2n+3 hash chains, which contains (2n+3)*n bytes of data, requiring a significant amount of memory. Summary of the Invention

[0004] This application provides a message signature method that can save memory.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a message signature method applied to a chip, the method comprising: Initialize the T context of the tree hash function T; the T context includes: cache field value, data size field value, and iteration field value; According to the predefined data block size, the initialized cache field value and multiple node hash values ​​are divided to obtain multiple data blocks, and the initialized cache field value and initialized data size field value are updated during the division process. If the updated cache field value is empty and the updated data size field value is equal to the total data size, perform hash iteration operation on multiple data blocks and update the initialized iteration field value during the hash iteration operation. The first signature value is determined based on the updated iterative field value.

[0006] This application provides a message signature device applied to a chip, the device comprising: The first initialization unit is used to initialize the T context of the tree hash function T; the T context includes: cache field value, data size field value, and iteration field value; The first partitioning unit is used to partition the initialized cache field value and multiple node hash values ​​according to the predefined data block size to obtain multiple data blocks, and to update the initialized cache field value and the initialized data size field value during the partitioning process; The first operation unit is used to perform hash iteration operations on multiple data blocks when the updated cache field value is empty and the updated data size field value is equal to the total data size, and to update the initialized iteration field value during the hash iteration operation. The first determining unit is used to determine the first signature value based on the updated iterative field value.

[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 message signature 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 message signature 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, which, when executed by a processor, implements the message signature method provided in this application.

[0010] The embodiments of this application have the following beneficial effects: First, initializing the T context of the T function ensures that all field values ​​in the T context are in their initial state, thus providing a unified foundation for subsequent processing. Second, the initialized cached field values ​​and multiple node hash values ​​are divided according to a predefined data block size, enabling segmented processing of data. This avoids resource waste caused by loading large volumes of data at once and avoids length limitations due to one-time input. Simultaneously, the cached field values ​​and data size field values ​​are dynamically updated to reflect the current processing status. Finally, when specific conditions are met, hash iteration operations are performed to progressively calculate the final iterative field value, which is then output as the first signature value. This method, by introducing the T context of the T function, eliminates the need for temporary storage of large amounts of intermediate results; signature calculation can be completed by maintaining only a small-scale context, thereby saving memory. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the message signature method provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the application of the message signature method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the hash function provided in the embodiments of this application; Figure 4 This is a schematic diagram of the calculation process for the segmented hash calculation function provided in the embodiments of this application; Figure 5 This is a schematic diagram illustrating the acquisition of parameter initialization provided in an embodiment of this application; Figure 6 This is a flowchart illustrating the implementation method of the PRFmsg function provided in the embodiments of this application; Figure 7 This is a flowchart illustrating the implementation method of the Hmsg function provided in the embodiments of this application; Figure 8 This is a flowchart illustrating the FORS tree public key calculation method provided in this application embodiment; Figure 9 This is a flowchart illustrating the WOTS+ public key calculation method provided in the embodiments of this application; Figure 10 This is a schematic diagram of the structure of the message signature device provided in the embodiments of this application; Figure 11 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application.

[0012] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0013] 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.

[0014] 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.

[0015] 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, nor are they constituting a chronological order. 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.

[0016] 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.

[0017] This application provides a message signing method, apparatus, electronic device, storage medium, and computer program product. In practical applications, the message signing method can be implemented by a message signing apparatus, and the functional entities in the message signing apparatus can be collaboratively implemented by the hardware resources of the electronic device (such as computing resources like processors and communication resources).

[0018] The following describes various embodiments of the message signature method, apparatus, electronic device, storage medium, and computer program product provided in the embodiments of this application.

[0019] This application provides a message signature method. The function implemented by this method can be achieved by an electronic device on a resource-constrained device calling program code. Of course, the program code can be stored in a computer storage medium. It can be seen that the electronic device includes at least a processor and a processor.

[0020] The message signature method provided in the embodiments of this application will be described in detail below. The embodiments of this application can be executed by a resource-constrained device, which refers to electronic devices with limited storage space, memory capacity, and computing power, such as embedded systems, microcontrollers, and IoT terminals. These devices have high requirements for the code size, memory usage, and execution efficiency of the software algorithm; therefore, the algorithm implementation needs to be specially optimized to meet actual deployment needs. (Reference) Figure 1 The process may include, but is not limited to, S101 to S104 described below.

[0021] S101 initializes the T context of the tree hash function T.

[0022] The Tree Hash (T) function is a function built on a hash algorithm and is used in a key calculation step in the SLH-DSA digital signature algorithm. Its function includes receiving input data and outputting a fixed-length message digest, i.e., the signature value, after multiple hash iterations.

[0023] In some embodiments, the T context of the T function can be initialized by calling the first interface of the T function.

[0024] In hash operations, the context is a data structure used to record the current computation state. In some implementations, the context includes cache field values, data size field values, and iteration field values. The cache field value refers to a field in the T context used to temporarily store intermediate data; for example, in the SLH-DSA algorithm, the cache field value might be used to store currently unprocessed message blocks. The data size field value records the total number of bytes of the currently input message. The iteration field value records the iteration result of the current hash operation. The T context is updated each time the T function interface is called to maintain the continuity and consistency of computation. By designing a reasonable context structure, the use of temporary memory can be significantly reduced, improving the applicability of algorithms on resource-constrained devices.

[0025] In some implementations, initializing the T context can be done by restoring the T context to its default state or by creating a new T context.

[0026] S102, according to the predefined data block size, divide the initialized cache field value and multiple node hash values ​​to obtain multiple data blocks, and update the initialized cache field value and the initialized data size field value during the division process.

[0027] The predefined data block size refers to the smallest unit into which each segmented message is divided during processing. The predefined data block size determines the maximum length of each input message; messages exceeding this maximum length will be split into multiple data blocks for processing. Properly setting the data block size helps improve the efficiency of hash operations and reduce memory usage. In some implementations, the data block size can be dynamically adjusted based on the performance and resource availability of the target device to optimize overall computational speed and resource utilization. In other implementations, the data block size is defined by the algorithm. For example, the SHAKE256 algorithm defines a data block size of 136, the SHA256 algorithm defines a data block size of 64, and the SHA512 algorithm defines a data block size of 128.

[0028] Updating the cache field value means storing the remaining unprocessed portion of the message in the cache, while updating the data size field value indicates the total length of the accumulated input messages. For example, when the current cache contains 30 bytes of unprocessed content and a 60-byte input block is received, the first 30 bytes of the input block will be processed first, then the remaining 30 bytes will be saved to the cache field, and the data size field value will be increased by 90 bytes to reflect the total amount of newly added data.

[0029] In some embodiments, the node hash value can be the root node hash value of the FORS tree. In other embodiments, the node hash value can also be the end hash value of the hash chain in the WOTS+ signature.

[0030] In some embodiments, the second interface of function T can be called to divide the initialized cache field value and multiple node hash values ​​according to a predefined data block size, resulting in multiple data blocks. During the division process, the initialized cache field value and the initialized data size field value are updated. Specifically, the second interface of function T is used to segment the initialized cache field value and multiple node hash values ​​according to a predefined data block size.

[0031] S103, when the updated cache field value is empty and the updated data size field value is equal to the total data size, perform hash iteration operation on multiple data blocks, and update the initialized iteration field value during the hash iteration operation.

[0032] In this case, the updated cache field value is empty and the updated data size field value is equal to the total data size, indicating that the hash values ​​of all nodes have been fully processed. At this point, the third interface of function T is called to start the hash iteration operation, and the iteration field value is continuously updated during this process to reflect the result of each round of hash operation.

[0033] In some embodiments, the third interface of function T can be called to perform hash iteration operations on multiple data blocks and update the initialized iteration field values ​​during the hash iteration operation.

[0034] S104, determine the first signature value based on the updated iterative field value.

[0035] The first signature value, used to verify the authenticity or integrity of a message, is a core component of the SLH-DSA digital signature algorithm. For example, in SLH-DSA, the first signature value could be a FORS tree public key or a WOTS+ public key.

[0036] In some embodiments, the iteration field value after the last update can be determined as the first signature value, or a fixed length of field value can be truncated from the iteration field value after the last update to obtain the first signature value.

[0037] First, initializing the T context of the T function ensures that all field values ​​within the T context are in their initial state, providing a unified foundation for subsequent processing. Second, the initialized cached field values ​​and multiple node hash values ​​are divided into predefined data block sizes, enabling segmented processing. This avoids resource waste caused by loading large amounts of data at once and avoids length limitations imposed by single inputs. Simultaneously, the cached field values ​​and data size field values ​​are dynamically updated to reflect the current processing status. Finally, when specific conditions are met, hash iteration is performed to progressively calculate the final iterative field value, which is then output as the first signature value. This method, by introducing the T context of the T function, eliminates the need for temporary storage of large amounts of intermediate results, requiring only the maintenance of a small-scale context to complete signature calculations, thus saving memory.

[0038] The process of initializing the T context of the tree hash function T in S101 is described below. This process may include, but is not limited to, S111 to S113 below.

[0039] S111 performs a zeroing operation on the cache field value, data size field value, and iteration field value.

[0040] The first interface of the T function can be the T_init interface, which is called to initialize the T context. In some implementations, initializing the T context can involve clearing the values ​​of each field of the T context to zero.

[0041] In this step, the cache field value is initialized to zero by calling the T_init interface to ensure that the state of the cache field value is consistent each time it is initialized, and to avoid the data residue from the previous calculation affecting the result of the current calculation. The data size field value is cleared to zero so that a new calculation process can be started. The iteration field value is cleared to zero to ensure that all calculation parameters return to the initial state and to prepare for the subsequent hash iteration process.

[0042] By performing a zeroing operation, it is ensured that each call to the T_init interface starts from a clean state, thereby improving the accuracy and consistency of calculations. The zeroing operation prevents erroneous calculations caused by residual state, thus guaranteeing the versatility of the T function across different modes and enabling flexible switching between various SLH-DSA modes.

[0043] S112, with the preset rule being the first rule, the public key seed and address are determined as the initialized cache field value, the total size of the public key seed and address is determined as the initialized data size field value, and the default iteration value is determined as the initialized iteration field value.

[0044] The public key seed PK.seed is part of the user's public key and is used to generate the relevant hash values ​​during the signature and verification processes. In the SLH-DSA algorithm, the public key seed PK.seed is typically used as one of the inputs to the calculation of multiple hash functions. The address ADRS is an identifier used to uniquely identify the current calculation process of function T. For example, the address can contain information about the tree structure, node positions, etc., to ensure that different calculation paths do not interfere with each other.

[0045] Taking the first rule of the SHAKE256 algorithm as an example, the public key seed PK.seed and the address ADRS are combined as the value of the initialized cache field, that is, PK.seed||ADRS is written into the cache in the T context. This combination method is adopted to adapt to the SHAKE256 algorithm. At the same time, the total size of the public key seed PK.seed and the address ADRS is used as the value of the initialized data size field, that is, the length of the public key seed PK.seed and the address ADRS is recorded as n+32 bytes, ensuring that subsequent processing can correctly determine the length of the input data. The default iteration value is a fixed initial value, which is usually pre-calculated and stored by the hardware accelerator to improve computational efficiency.

[0046] S113, under the premise that the preset rule is the second rule, the address is determined as the value of the cache field after initialization, the size of the address is determined as the value of the data size field after initialization, and the initial iteration value is determined as the value of the iteration field after initialization.

[0047] The first rule is different from the second rule. The second rule can be a rule defined by the SHA256 algorithm or a rule defined by the SHA512 algorithm.

[0048] Taking the second rule, which defines the SHA256 algorithm, as an example, the initial iteration value is obtained by hashing the padded public key seed. Since PK.seed||00…00 is exactly one data block, it can trigger one SHA256 compression iteration calculation. This calculation result (i.e., the initial iteration value sha256_iv) can be pre-calculated and written into the hash accelerator.

[0049] Taking the second rule as an example, which is defined by the SHA256 algorithm, the address ADRS c As the value of the cached field after initialization, that is, ADRS c Write it to the cache in the T context. This combination method is used to accommodate the SHA256 algorithm. Simultaneously, the public key seed PK.seed, padding values ​​00…00, and address ADRS are also included. cThe total size is used as the value of the initialized data size field, which records the public key seed PK.seed, the padding value 00…00, and the address ADRS. c The length is 86 (64+22) bytes. This ensures that subsequent processing can correctly determine the length of the input data. The initial iteration value is the initial value calculated above, which is usually pre-calculated and stored by the hardware accelerator to improve computational efficiency.

[0050] In this embodiment of the application, in order to improve efficiency, the initial iteration value can be obtained by pre-computation and stored in the global parameter area.

[0051] Based on the above technical means, by selecting different initialization methods according to preset rules, the T function context can be flexibly configured, and multiple SLH-DSA modes can be dynamically switched, thereby reducing code redundancy and significantly reducing storage and memory consumption, thus enabling the post-quantum cryptography algorithm to run efficiently on resource-constrained devices.

[0052] The following describes the process in S102 of dividing the initialized cache field value and multiple node hash values ​​according to the predefined data block size to obtain multiple data blocks, and updating the initialized cache field value and the initialized data size field value during the division process. This process may include, but is not limited to, S121 to S125 below.

[0053] S121, determine the sum of the size of the initialized cache field value and the size of the first node hash value in the node hash values.

[0054] The second interface of the T function can be the T_update interface, which processes the current node hash value with the current context state to update the internal state for subsequent processing. In some embodiments, the T_update interface can be called to determine the sum of the initialized cache field value and the first node hash value in the node hash values.

[0055] S122, if the summation result is less than the data block size, update the initialized cache field value to the initialized cache field value and the hash value of the first node.

[0056] When the sum of the initialized cache field value and the hash value of the first node is less than the predefined data block size, it indicates that the initialized cache field value still has enough space to accommodate more data. In this case, the hash value of the first node is appended to the initialized cache field value, generating an updated cache field value, which will be used as the cache field value for the next T_update interface processing.

[0057] S123, if the summation result is equal to the data block size, determine the first data block by the initialized cache field value and the hash value of the first node, and update the initialized cache field value to empty.

[0058] When the sum of the initialized cache field value and the hash value of the first node is exactly equal to the predefined data block size, it means that the sum of the initialized cache field value and the hash value of the first node constitutes a complete data block. At this time, the method merges the initialized cache field value with the hash value of the first node, processes it as the first data block, and clears the initialized cache field value to receive the next input data.

[0059] S124, if the summation result is greater than the data block size, determine the first data block by the initialized cache field value and the hash value of the first node, and update the initialized cache field value to the part of the initialized cache field value and the hash value of the first node that exceeds the data block size.

[0060] When the sum of the initialized cache field value and the hash value of the first node exceeds the predefined data block size, it indicates that the sum of the initialized cache field value and the hash value of the first node exceeds the processing range. In this state, the first portion of the data is divided into the first data block for processing, while the remaining portion is retained in the initialized cache field value, awaiting processing in the next iteration.

[0061] S125 updates the initialized data size field value to the summation result until multiple node hash values ​​are analyzed and multiple data blocks are obtained.

[0062] The initialized data size field is used to record the total length of the current cumulative input data. After each data block is divided and processed, the initialized data size field is updated according to the latest summation result until all node hash values ​​have been processed, resulting in multiple data blocks.

[0063] Based on the aforementioned technical methods, this method generates multiple data blocks by processing the initialized cache field values ​​and the hash values ​​of multiple nodes one by one, thus achieving block-based data management. Secondly, when the summation result is less than the data block size, the next node hash value is added. When the summation reaches or exceeds the data block size, a complete data block is formed, and the cache field value and data size field value are updated, thereby achieving efficient data organization. This method avoids the memory pressure caused by reading all data at once, making it particularly suitable for long message processing scenarios on resource-constrained devices. Furthermore, it eliminates the need for temporary storage of large amounts of intermediate results, requiring only the maintenance of a small-scale context to complete signature calculations, thereby saving memory.

[0064] The following describes the process in S103 of performing hash iteration operations on multiple data blocks and updating the initialized iteration field value during the hash iteration operation. This process may include: performing a hash operation on the initialized iteration field value and the first data block among the multiple data blocks to obtain the first iteration value, and updating the initialized iteration field value to the first iteration value; the following describes the process in S104 of determining the first signature value based on the updated iteration field value. This process may include: determining the updated iteration field value as the first signature value after all hash operations on the multiple data blocks have been completed.

[0065] The third interface of the T function can be the T_final interface, which is an interface used to perform hash operations and is typically called after all data blocks have been input. By calling the T_final interface, a hash operation is performed on the initialized iteration field value and the first data block among multiple predefined data blocks to generate the first iteration value. The initialized iteration field value is then updated to this first iteration value, thereby ensuring the integrity and consistency of the hash operation.

[0066] In some embodiments, when the node hash value is the root node hash value of the FORS tree, the first signature value can be the FORS tree public key FORS_PK; when the node hash value is the end hash value of the hash chain in the WOTS+ signature, the first signature value can be the WOTS+ public key.

[0067] The first iteration value refers to the intermediate result obtained after processing the first data block, and it serves as the starting point for processing subsequent data blocks. After calculating the first iteration value, a hash operation is performed on the first iteration value and the second data block from a predefined set of data blocks to generate the second iteration value. This process continues until all data blocks have been hashed, resulting in the first signature value. By maintaining a smaller context space, memory consumption can be significantly reduced, enabling resource-constrained devices to run the SLH-DSA algorithm efficiently.

[0068] Based on the aforementioned techniques, by sequentially performing hash iteration operations on each data block and progressively updating the iteration field values, the final iteration value is output as the first signature value, ensuring the consistency and integrity of the entire signature process. Compared to processing all data at once, this method not only reduces the need for temporary memory but also improves computational efficiency, making it particularly suitable for running on resource-constrained devices. Furthermore, since the iteration field values ​​are updated immediately after each iteration, additional storage of intermediate results is avoided, saving memory.

[0069] In some embodiments, the message signing method further includes the generation of a second signature value. The process of generating the second signature value is described below, and this process may include, but is not limited to, S131 to S134 below.

[0070] S131, if the size of the message to be processed is greater than a preset threshold, or if the message to be processed is received multiple times, determine multiple segmented messages in the message to be processed.

[0071] When the size of a message to be processed exceeds a preset threshold, the message is split into multiple segments for processing. Furthermore, in some scenarios, even if a single message does not exceed the preset threshold, if the message to be processed is received multiple times (e.g., arriving intermittently during network transmission), it will also be treated as multiple segments. This design effectively handles large messages or segmented inputs, ensuring the algorithm can efficiently process messages of arbitrary length.

[0072] S132 initializes the HMAC context of the message-oriented pseudo-random function PRFmsg.

[0073] The Pseudorandom Function for Message (PRFmsg) is a function that generates a hash-based Message Authentication Code (HMAC) in the SLH-DSA algorithm to process user-input messages and generate intermediate state values. Through multiple interfaces, this function enables segmented input, allowing for the input of longer messages in chunks, thus improving flexibility and adaptability.

[0074] The first interface of the PRFmsg function is responsible for initializing the HMAC context required by the PRFmsg function. This initialization process lays the foundation for subsequent segmented processing, enabling flexible input processing while maintaining security. In some embodiments, the first interface of the PRFmsg function can be called to initialize the HMAC context of the PRFmsg function.

[0075] The HMAC context is a data structure used to store intermediate state information required during the execution of the PRFmsg function, such as the current hash state and cache. Maintaining the HMAC context ensures that the processing results of each segment of the message are correctly concatenated, ultimately generating a consistent output. In some implementations, the HMAC context may include a cache (buf) and a first hash context (hash context).

[0076] In some implementations, initializing the HMAC context can be done by restoring the HMAC context to its default state or by creating a new HMAC context.

[0077] S133, according to the data block size, divide the initialized PRFmsg function context and multiple segmented messages to obtain multiple first message data.

[0078] The second interface of the PRFmsg function can be the PRFmsg_update interface, which is used to combine the initialized PRFmsg function context with each segmented message according to a predefined data block size to generate a series of first message data that can be processed independently. In some embodiments, the second interface of the PRFmsg function can be called to divide the initialized PRFmsg function context and multiple segmented messages according to the data block size to obtain multiple first message data.

[0079] In some implementations, the `hash_update` interface can be nested within the second interface of the `PRFmsg` function. By calling the `hash_update` interface, the initialized `PRFmsg` function context and multiple segmented messages are divided according to the data block size, resulting in multiple second message data. For example, the `hash_update` interface fills the initialized `PRFmsg` function context and multiple segmented messages so that the length of the filled message is an integer multiple of the data block size, and then divides the filled message into multiple data blocks according to the data block size, i.e., multiple first message data. In other implementations, the second interface of the `PRFmsg` function is called to determine the sum of the sizes of the first segmented message among the multiple segmented messages. If the sum equals the data block size, the initialized `PRFmsg` function context and the first segmented message are determined as the first first message data, and this process continues until all multiple segmented messages have been analyzed, resulting in multiple first message data.

[0080] S134, perform a hash operation on multiple first message data to obtain the second signature value.

[0081] The third interface of the PRFmsg function is used to perform a final hash operation on all processed first message data to generate a unified second signature value. In some embodiments, the third interface of the PRFmsg function can be called to perform a hash operation on multiple first message data to obtain the second signature value. The second signature value not only contains information from all segmented messages but also incorporates the key material provided during the initialization phase, thereby ensuring that the second signature value has sufficient security and integrity.

[0082] The second signature value, as the final output, can be used to generate multiple node hash values. These multiple node hash values ​​play a crucial role in the SLH-DSA algorithm, for example, in constructing the Merkle tree structure and verifying the validity of the signature.

[0083] Based on the above technical means, when the message to be processed is too large or cannot be received at once, it can be divided into multiple segmented messages, and the processing process of multiple segmented messages can be recorded through the HMAC context of the PRFmsg function, thereby generating a second signature value used to generate the node hash value, thus realizing support for large messages or segmented messages.

[0084] The process of initializing the HMAC context of the message-oriented pseudo-random function PRFmsg in S132 is described below. This process may include, but is not limited to, S141 and S142 below.

[0085] S141, store the first value in the cache of the HMAC context.

[0086] The first value is obtained by XORing the preprocessed key and the first padding constant. The preprocessed key refers to the key data that has undergone specific formatting or expansion to adapt to the input requirements of the hash function. For example, in HMAC calculation, the original key may be smaller than a data block size. Zeros are padded to the end of the original key to the size of the data block, resulting in a zero-padded result. The XOR operation performs a bitwise logical XOR operation on the preprocessed key and the second padding constant, which are of the same length, to generate a new binary number. This effectively obfuscates the key information, thereby enhancing its security.

[0087] The first interface of the PRFmsg function can be the PRFmsg_init interface, which is used to XOR the preprocessed key with a first padding constant (such as iPad) to generate an intermediate value, and store this intermediate value as the initial state in the HMAC context of the PRFmsg function. The introduction of the PRFmsg_init interface makes subsequent message segmentation processing possible, avoiding the overhead caused by recalculating the key and padding constant every time a message is processed. In some embodiments, the PRFmsg_init interface can be called to store the first value in the HMAC context cache.

[0088] S142, initialize the first hash context in the HMAC context, and input the first value into the first hash context.

[0089] The first hash context of the PRFmsg function refers to the internal data structure used to maintain the current state in the HMAC calculation process. The first hash context is a core part of the hash algorithm execution process, containing information such as the intermediate results of the current iteration, the buffer, and the accumulated message length.

[0090] For example, during HMAC initialization, its context records buf=K0. iPad, and begin hash initialization and message update (K0) iPad), to use K0 The `ipad` (first value) is input into the first hash context. Afterwards, the HMAC's `update` interface can use the hash context to call `hash_update` to input messages in segments.

[0091] Based on the above technical means, by initializing the HMAC context, the first value is passed as the initial input to the first hash context, providing a reliable starting point for subsequent hash operations.

[0092] The process of performing a hash operation on multiple first message data to obtain a second signature value by calling the third interface of the PRFmsg function in S134 is described below. This process may include, but is not limited to, S151 to S153 below.

[0093] S151, perform a hash operation on multiple first message data to obtain the first hash value.

[0094] The third interface of the PRFmsg function can be the PRFmsg_final interface. In some embodiments, the PRFmsg_final interface can be called to perform a hash operation on multiple first message data to obtain a first hash value.

[0095] In some implementations, the `hash_final` interface can be nested within the third interface of the `PRFmsg` function. By calling the `hash_final` interface, hash operations are performed on multiple first message data to obtain a first hash value. For example, each first message data is processed iteratively, requiring the result of the previous first message data as input, called the iteration value. After processing, a new iteration value is output as input for the next second message data. After the last first message data is processed, a final hash operation is performed to obtain a fixed-length hash value. In other implementations, the third interface of the `PRFmsg` function is directly called to perform a hash operation on the first first message data to obtain a first iteration value. Then, the first iteration value and the second first message data are hashed to obtain a second iteration value, and so on, until all second message data have been hashed to obtain the first hash value.

[0096] The `PRFmsg_final` interface is the final processing stage in a segmented hash operation interface, used to complete the final processing of the input message and output the hash result. The `PRFmsg_final` interface is typically used in conjunction with the `PRFmsg_init` and `PRFmsg_update` interfaces. After the message is segmented into segments, the `PRFmsg_final` interface merges all segments to generate the final hash value. For example, in the SHA256 algorithm, the `PRFmsg_final` interface performs the final iteration of compression and outputs a fixed-length digest value. The `PRFmsg_final` interface enables efficient processing of long messages on resource-constrained devices.

[0097] S152, perform an XOR operation on the preprocessed key and the second padding constant to obtain the second value.

[0098] In some implementations, the preprocessed key and the second padding constant are XORed to obtain a second value, which is then recorded in a buffer, i.e., buf = K0. opad.

[0099] S153, perform a hash operation on the first hash value and the second value to obtain the second signature value.

[0100] The first hash value and the second value are concatenated and hashed together to obtain the second signature value.

[0101] Based on the aforementioned technical methods, a first hash value is generated by summarizing all segmented messages. Then, a second hash operation is performed by XORing the preprocessed key with a second padding constant to obtain a second value, ultimately generating a second signature value. This method ensures the uniqueness and immutability of the final signature value; even if some messages are modified, the signature value will change, effectively preventing forgery. Furthermore, the combined use of two hash operations enhances the signature value's collision resistance.

[0102] In some embodiments, the message signing method further includes the generation of a hash digest. The process of generating the hash digest is described below, and this process may include, but is not limited to, S161 to S163 below.

[0103] S161, Initialize the Hmsg context of the message-oriented hash function Hmsg based on the second signature value.

[0104] The message-oriented hash function (Hmsg) is a hash function based on the MGF1 (MaskGeneration Function 1) mechanism, used to construct auxiliary information required for signatures in the SLH-DSA algorithm. By setting three interfaces, this function supports segmented input, and its calculation process requires parameters such as the public key seed PK.seed and the public key root node PK.root.

[0105] In some embodiments, the first interface of the Hmsg function can be invoked to initialize the Hmsg context of the Hmsg function based on the second signature value.

[0106] The Hmsg context refers to a set of state information maintained during the execution of the Hmsg function, including the current hash iteration value, signature value, etc. The Hmsg context of the Hmsg function is initialized by calling the first interface to ensure that subsequent hash operations can be executed correctly. In some implementations, initializing the Hmsg context can involve restoring it to its default state or creating a new Hmsg context.

[0107] By splitting the Hmsg function into multiple interfaces and introducing a context mechanism, not only is the use of temporary memory reduced, but the flexibility of message processing is also improved, and the SLH-DSA algorithm can better adapt to the needs of different scenarios.

[0108] S162, according to the data block size, divide the initialized Hmsg function context and multiple segmented messages to obtain multiple second message data.

[0109] The second interface of the Hmsg function can be the Hmsg_update interface. Calling the second interface of the Hmsg function divides the message into multiple second message data and processes these second message data one by one. In addition, the second interface of the Hmsg function is also responsible for receiving each second message data and updating the state of the Hmsg context of the Hmsg function. This segmented processing method allows hash calculations to be completed without loading the entire message at once, making it particularly suitable for scenarios involving large messages or network streaming.

[0110] In some implementations, the `hash_update` interface can be nested within the second interface of the `Hmsg` function. By calling the `hash_update` interface, the initialized `Hmsg` function context and multiple segmented messages are divided according to the data block size, resulting in multiple second message data. For example, the `hash_update` interface pads the initialized `Hmsg` function context and multiple segmented messages so that the length of the padded message is an integer multiple of the data block size, and then divides the padded message into multiple data blocks according to the data block size, i.e., multiple second message data. In other implementations, the second interface of the `Hmsg` function is called to determine the sum of the sizes of the first segmented message among the multiple segmented messages. If the sum equals the data block size, the initialized `Hmsg` function context and the first segmented message are determined as the first second message data, and this process continues until all multiple segmented messages have been analyzed, resulting in multiple second message data.

[0111] S163, perform a hash operation on multiple second message data to obtain a hash digest.

[0112] In some embodiments, the third interface of the Hmsg function can be called to complete the hash operation and output the final hash digest. The hash digest is a fixed-length output obtained after the hash operation, representing a unique identifier for the input message. In the SLH-DSA algorithm, the hash digest is used to generate a signature or verify the validity of a signature. Due to the collision resistance and one-wayness properties of hash functions, message integrity and immutability can be effectively guaranteed.

[0113] In some implementations, the `hash_final` interface can be nested within the third interface of the `Hmsg` function. By calling the `hash_final` interface, hash operations can be performed on multiple second message data to obtain a hash digest. For example, each second message data can be processed iteratively, requiring the result of the previous second message data as input (called the iteration value). After processing, a new iteration value is output as input for the next second message data. After the last second message data is processed, a final hash operation is performed to obtain a fixed-length hash value, also called a message digest. In other implementations, the third interface of the `Hmsg` function is directly called to perform a hash operation on the first second message data to obtain a first iteration value. Then, the first iteration value and the second second message data are hashed to obtain a second iteration value, and so on, until all second message data have been hashed to obtain the hash digest.

[0114] Based on the aforementioned technical methods, the Hmsg context is configured using the second signature value as an initialization parameter, and then the segmented messages are processed to finally generate a hash digest. By independently processing and integrating multiple segmented messages, the system's fault tolerance and robustness are improved.

[0115] The process of initializing the Hmsg context of the message-oriented hash function Hmsg based on the second signature value in S161 is described below. This process may include, but is not limited to, S171 and S172 below.

[0116] S171, Record the second signature value in the Hmsg context.

[0117] The first interface of the Hmsg function can be the Hmsg_init interface. In some embodiments, the Hmsg_init interface can be called to record the second signature value in the Hmsg context, that is, to write the second signature value into the Hmsg context, so as to ensure that the second signature value is correctly used in subsequent calculations, thereby improving the security and accuracy of signature verification.

[0118] S172, initialize the second hash context in the Hmsg context, and input the second signature value, public key seed and public key root node value into the second hash context.

[0119] The second hash context is a substructure within the Hmsg context used to perform specific hash operations. It manages the intermediate states and iterations of the hash operations, ensuring a correct hash result after each message update.

[0120] The public key seed is part of the SLH-DSA algorithm used to generate the public key tree structure. It participates in multiple hash operations and is one of the fundamental elements in building the Merkle tree. By inputting the public key seed into the second hash context, the consistency and traceability of public key information throughout the signing and verification process can be ensured. The public key root node value is the top-level hash value in the Merkle tree structure, representing the root of the entire tree. It plays a crucial role in the signing and verification process and is the key basis for verifying the signature's legitimacy. By inputting the public key root node value into the second hash context, it can be guaranteed that all hash operations during signature verification are based on a unified public key structure.

[0121] By inputting the second signature value, public key seed, and public key root node value into the second hash context, the consistency and integrity of the hash operation process in the second hash context can be ensured, thereby achieving high reliability and efficiency of signature verification.

[0122] Based on the aforementioned techniques, after initializing the Hmsg context, the second signature value, public key seed, and public key root node value together constitute the basic input for the hash operation. This method ensures that the hash digest generation process is closely related to the signature value, thereby enhancing the credibility and consistency of the signature result. Furthermore, by integrating multiple key parameters into the hash context, memory is saved and computational efficiency is improved.

[0123] In some embodiments, the message signing method further includes: S181, determine the global parameters, and set the same function pointer for the pseudo-random function PRF, the compression function F, the hash function H, and the T function.

[0124] Global parameters represent the parameters used in the hash operation. In some implementations, global parameters are a set of configuration parameters used in the SLH-DSA algorithm to describe different modes. These parameters include the number of hash output bytes (n), the height of the supertree (h), the height of the FORS tree (fors_a), and the number of trees (fors_k), which determine the overall performance and security of the algorithm. By centrally managing these parameters, multiple mode switching can be supported after a single compilation, eliminating the need to compile code separately for each mode.

[0125] The pseudo-random function (PRF) is a fundamental function in the SLH-DSA algorithm used to generate key-related hash values. The PRF output exhibits pseudo-random characteristics and is commonly used for key derivation in the signing and verification processes. The compression function (F) is used to construct Merkle tree nodes, merging two input values ​​to generate a shorter digest. The hash function (H) is used to process message digests and is typically used in signing or verification processes. The T function handles segmented inputs of longer messages. The T function is split into three interfaces: T_init, T_update, and T_final, to reduce memory usage.

[0126] Although the pseudo-random function PRF, compression function F, hash function H, and function T have different functionalities, they share similar structures and calling methods in their implementations. Therefore, these functions can share a single set of function pointer definitions. By using a common set of function pointer definitions for these functions, code logic can be simplified and execution efficiency improved.

[0127] S182 stores global parameters, PRF function, F function, H function, and T function that share the same function pointer in the structure.

[0128] A structure is a data organization method used to centrally manage related variables and function pointers. A structure contains all necessary global parameters and function pointers. By defining structures, the entire runtime environment of the SLH-DSA algorithm can be encapsulated within an object, facilitating management and maintenance.

[0129] Based on the aforementioned technical means, global parameters define the configuration information required for each algorithm, while unified function pointers allow for flexible switching between different hash algorithm instances within the same code framework. By introducing global parameters and unified function pointers, centralized management and scheduling of multiple related functions are achieved. Furthermore, it facilitates rapid switching between different modes, meeting the needs of multi-mode operation.

[0130] The message signature scheme provided in this application will be described below through an embodiment.

[0131] The following are explanations of the terms used in this application: SLH-DSA: Stateless Hash-Based Digital Signature Standard (SDSA), as described in FIPS-205; PK: The user's public key for the SLH-DSA algorithm, PK = PK.seed || PK.root, where both PK.seed and PK.root are n bytes, therefore PK is 2n bytes; SK: The user's private key for the SLH-DSA algorithm, SK = SK.seed || SK.prf || PK.seed || PK.root, where both SK.seed and SK.prf are n bytes, therefore SK is 4n bytes. Clearly, SK contains PK; Merkle tree: A complete binary tree used in the SLH-DSA algorithm. Used for constructing signatures; Hypertree: A supertree, in the SLH-DSA algorithm, a Merkle tree composed of d-level sub-Merkle trees; FORS: In the SLH-DSA algorithm, each leaf node of the supertree corresponds to a FORS (Forest of Random Subsets), which contains k Merkle trees. It can be used to construct FORS signatures, which are part of the SLH-DSA signature; WOTS+: A method for constructing signatures using hash chains (Winternitz One-Time Signature Plus Scheme). WOTS+ signatures are part of the SLH-DSA signature; Bootloader: A small special program that runs after the microcontroller is powered on or reset, before the main application (i.e., firmware) runs. Used for system hardware initialization, booting, etc.; RSA: A digital signature or encryption / decryption algorithm based on the large number factorization problem; ECDSA: A digital signature algorithm based on the elliptic curve discrete logarithm problem; SM2: A Chinese digital signature algorithm based on the elliptic curve discrete logarithm problem, a type of commercial cryptographic algorithm; : XOR operation; ||: Cascade operation.

[0132] Digital signature cryptography algorithms based on large number operations, such as RSA, ECDSA, and SM2, have been widely used for many years. These algorithms all involve calculating a hash value for the message, which replaces the original message in the actual signing or verification process. To improve performance, many chips or devices are designed with hardware accelerators (or coprocessors, computing engines, etc.) for hash algorithms.

[0133] However, with the continued development of quantum computing, practical quantum computers are likely to emerge in the near future. Classical digital signature algorithms such as RSA, ECDSA, and SM2 will then be compromised and rendered unusable. Under this threat, the need for counter-quantum cryptography algorithms is growing stronger. NIST in the United States launched a call for submissions of post-quantum cryptography algorithms, and in 2024, NIST released the post-quantum signature algorithm SLH_DSA. SLH_DSA is built entirely on hash algorithms and does not involve complex mathematical concepts or tools. Naturally, the SLH-DSA algorithm can be implemented and deployed on existing hash accelerators, fully utilizing the capabilities of existing equipment and reducing the cost of equipment replacement or upgrades.

[0134] While some open-source libraries for SLH-DSA are available for reference, they all have certain limitations, such as incomplete mode support or support for only one of the 12 modes; the ability to sign or verify large messages only when they are fully input at once; and the requirement for large amounts of temporary memory. Therefore, porting and implementing the SLH-DSA algorithm based on these open-source libraries presents challenges, especially on low-cost, resource-constrained devices where the code size and memory consumption are significant. This application addresses these shortcomings by recording necessary parameters in a global parameter area, allowing for different configurations across the 12 modes and enabling switching between them—meaning a single compilation can support all 12 modes simultaneously. The PRFmsg and Hmsg functions involved in message processing in the SLH-DSA algorithm are modified to support segmented message input, providing flexibility. The T function in SLH-DSA is modified into three functions: T_init, T_update, and T_final, requiring only a maximum of 300 bytes of context space and eliminating the need for several kilobytes of temporary memory. This allows for simultaneous support of all 12 modes, with no limit on message length, significantly reduced storage space requirements, and lower memory demands. It possesses excellent versatility and applicability, making it highly suitable for implementing the SLH-DSA algorithm on low-cost, resource-constrained devices. It fully utilizes the device's capabilities and facilitates the widespread implementation of post-quantum algorithms.

[0135] Currently, digital signature algorithms based on large number operations, such as RSA, ECDSA, and SM2, are widely used (these signature algorithms are accompanied by hash algorithm calculations, and there are usually hash hardware accelerators to improve performance).

[0136] Some microcontrollers employ a two-level bootloader mechanism. The primary bootloader is immutable, providing a root of trust for system updates and management, while the secondary bootloader can be modified to facilitate the addition of new functions and protocols. For example, before running firmware, the system needs to verify its legitimacy. This can be done by the secondary bootloader, using RSA or ECDSA algorithms for firmware signature verification. The firmware, its signature, and the public key corresponding to the signature are provided to the secondary bootloader for verification. Only after successful signature verification can the firmware run. Therefore, we can now add SLH-DSA algorithm signature verification functionality to the secondary bootloader, replacing RSA signature verification with SLH-DSA. (See below.) Figure 2 As shown.

[0137] S201, after the first-level boot loader 201 is loaded, it jumps to the second-level boot loader 202 for execution.

[0138] S202, the secondary bootloader 202 verifies the signature based on the firmware 203, the SLH-DSA signature 204, and the SLH-DSA public key 205, and gives the result of whether the signature is successful or not.

[0139] S203: If the signature is valid, the firmware will run; otherwise, the firmware will not run and an exception will be returned.

[0140] The method in this application can fully utilize the existing hash calculation accelerator in the chip to accelerate the hash calculation in the SLH-DSA algorithm, and has very small storage requirements (including flash and memory). It is very suitable for implementing the SLH-DSA algorithm on low-cost, resource-constrained devices, and has strong applicability. It is a general method that can efficiently support the calculation of messages of arbitrary length, which helps to maintain the advantage of low device cost.

[0141] 1. Hash function structure Here's a review of the structure of common hash functions to facilitate later explanations.

[0142] like Figure 3As shown, the hash function fills the input message according to specific rules, ensuring that the length of the filled message is an integer multiple of the block size. The filled message is then divided into multiple blocks, from message block 1 to message block n (msg block 1 to msg block n). Each block is iterated over sequentially, requiring the result of the previous block as input, called the iteration value (for the first block, called the IV, i.e., the initial vector, the initial iteration value). The new iteration value is then output as the input for the next block. After the last message block is processed, it undergoes finalization to obtain a fixed-length hash value, also known as a message digest. The detailed steps are as follows: S301, Obtain the initial vector.

[0143] S302, iterate over the initial vector and message block 1 to obtain the corresponding hash value, which is the first iteration value.

[0144] S303, iterate over the first iteration value and message block 2 to obtain the corresponding hash value, i.e., the second hash value.

[0145] S304, until message block n is processed, and its final corresponding hash value is obtained, which is the nth iteration value.

[0146] S305, perform final processing on the nth iteration value to obtain the message digest.

[0147] S306, Output message digest.

[0148] As we can see, if we know the iteration values ​​after processing the first few blocks, we can start calculating the hash value of the complete message from this iteration value, using it as the IV, and only need to input the subsequent message segments. This saves computation and improves hash processing performance. Later, we will see that when using the SLH-DSA algorithm with SHA2, the first block of the input to the PRF, F, H, and T functions is fixed. Therefore, we can perform an iteration calculation on this block, store the result, and then input this iteration value as the IV when processing these functions later, discarding the first block of the original message.

[0149] 2. Segmented hash function calculation function like Figure 4 As shown, assuming that the current device already has a hash calculation accelerator (which is usually equipped on cryptographic chips to calculate message digests, i.e. hash values) and supports segmented calculation function, this calculation method has good versatility and has been widely supported by various cryptographic libraries and devices.

[0150] S401: For longer messages, divide them into multiple segments in sequence and then call the hash initialization API hash_init().

[0151] S402, call the hash update message API hash_update() interface in sequence for each message segment to input each message segment.

[0152] S403: Determine if the input is complete. If the input is complete, proceed to S404; otherwise, proceed to S402.

[0153] S404, call the hash_final API (hash_final()) to process and obtain the hash value.

[0154] S405, outputs the hash value.

[0155] The segmented hash calculation function requires maintaining a common context, which should include the following parts: 21. A block buffer that caches the remaining messages that do not complete a full block in this processing.

[0156] 22. Updated IV (also called iteration value).

[0157] 23. The sum of the lengths of the input messages (which is ultimately the total length of the complete message).

[0158] 3. SLH-DSA parameter initialization With the above background information, we will now elaborate on the key content of this application. For example... Figure 5 As shown, the global parameters to be used by the key generation (key_gen), signing (sign), and verification modules (verify) of the SLH-DSA algorithm can be obtained from the initialized parameter area.

[0159] S501 calls the SLH-DSA initialization interface (SLH-DSA init).

[0160] S502, obtain SLH-DSA global parameters, including: key generation (key_gen), signature (sign), and global parameters to be used by the signature verification module (verify).

[0161] For example, a structure can be designed to store the relevant parameters for a specified mode of SLH-DSA.

[0162]

[0163] As can be seen, the four functions PRF, F, H, and T are similar in function type and structure, and can share a set of function pointer definitions: typedef void (*spx_f)(uint8_t *out, const uint8_t *in, uint32_t in_n_blocks, const struct spx_param_ctx_ *ctx, const uint32_t addr[8]); When using SHAKE256, or SHA2 category 1, or SHA2 categories 3 and 5, these four functions have their own implementation instances. During initialization, it is only necessary to record the pointers to these function instances to be used in the current configuration.

[0164] The system initialization above also introduced the following two values.

[0165] uint32_t sha256_iv[8]; uint32_t sha512_iv

[16] ; This is because when using SHA2, the first block of the input for SHA256 is fixed, and similarly, the first block of the input for SHA512 is also fixed. According to the characteristics of hash algorithms, this block can undergo one hash iteration (or compression) to obtain an iteration value, which is similar to an IV. Therefore, during initialization, this iteration value can be used instead of the algorithm's fixed IV, eliminating the need for the first block of input and allowing direct input of subsequent ADRS. Since these functions are called many times, this reduces computation and improves performance.

[0166] 4. New PRFmsg and Hmsg implementation When messages are large or received in portions that are inconvenient to input and calculate all at once, they can be divided into multiple smaller segments sequentially, with only one segment processed at a time. This approach is more flexible and convenient. The segmented implementation methods for the PRFmsg and Hmsg functions are given below.

[0167] These two functions have three instance definitions depending on the different modes, as follows: 41. When using the SHAKE256 algorithm, it is obviously the simplest to implement. It can support segmented message input simply by applying the existing segmented hash_init, hash_update, and hash_final.

[0168] 42. Using SHA2 (SHA256 or SHA512) is slightly more complicated.

[0169] For PRFmsg, this is an HMAC, and the definition of HMAC is as follows.

[0170] HMAC(K, M) = H((K0 opad )|| H((K0 ipad) || M)) K0 is a hash block space, and the SK.prf of the SLH-DSA used as the HMAC key is a maximum of 32 bytes, which does not exceed the block length of 64 bytes for SHA256, nor the block length of 128 bytes for SHA512. Therefore, we only need to fill some 0x00 bytes after SK.prf to fill a block, namely K0.

[0171] Both opad and ipad are one block long, with values ​​of repeated 0x5c and repeated 0x36, respectively.

[0172] Therefore, an HMAC context can be designed, containing a hash block cache `buf` and a hash context. During HMAC initialization, its context records `buf=K0`. iPad, and begin hash initialization and message update (K0) (iPad). After that, the HMAC update interface can use the hash context to call hash_update to segment the input message. When it reaches final, H((K0) will be calculated. ipad) || M), then set buf = buf in the HMAC context. iPad opad= K0 The final result is calculated by concatenating the two parts (opad and its corresponding hash function). The entire calculation is as follows: Figure 6 As shown.

[0173] S601, calls the PRFmsg initialization API PRFmsg_init interface (PRFmsg Initialization APIPRFmsg_init()).

[0174] S602, sequentially call the PRFmsg update message API PRFmsg_update interface (PRFmsgupdate message API PRFmsg_update()) for each message segment to input each message segment.

[0175] S603: Determine if the input is complete. If the input is complete, proceed to S604; otherwise, proceed to S602.

[0176] S604, call the PRFmsg finalization API PRFmsg_final interface (PRFmsg Finalization APIPRFmsg_final()) to process and obtain the signature value (signature R value).

[0177] S605, output signature value.

[0178] For Hmsg, this is an MGF1 function, as described below.

[0179] Input: message msg, output length len bytes.

[0180] Output: a string of bytes in length len. step: 411.4 bytes counter=0, empty byte string T, at this time the byte length tlen=0 of T.

[0181] 412. Perform the following loop operation.

[0182]

[0183] 413. Output the first len ​​bytes of T.

[0184] This explanation uses MGF1-SHA-256 as an example. Similar to the method above, we can design an Hmsg context containing the input R (or the address of R; PK.seed, being in the global parameter area, doesn't need to be included to save storage) and a hash context. During Hmsg initialization, its context records R and begins hash initialization and updating the message R||PK.seed||PK.root. Afterward, Hmsg's update can segment the input message. By the final iteration, a complete R||PK.seed||SHA-256 (R||PK.seed||PK.root||M) is obtained, allowing the MGF1 function to calculate the final output. The difference between MGF1-SHA-512 and MGF1-SHA-256 is only that the internal hash is changed from SHA256 to SHA512, so it will not be elaborated further. The calculation process is as follows:Figure 7 As shown.

[0185] S701 calls the Hmsg Initialization API Hmsg_init interface (Hmsg Initialization API Hmsg_init()).

[0186] S702, sequentially call the Hmsg update message API Hmsg_update interface (Hmsgupdate message API Hmsg_update()) for each message segment to input each message segment.

[0187] S703: Determine if the input is complete. If the input is complete, proceed to S704; otherwise, proceed to S702.

[0188] S704, call the Hmsg finalization API Hmsg_final() to process and obtain the message Hmsg digest.

[0189] S705, outputs Hmsg summary.

[0190] 5. Methods to save memory 5.1. Public Key Calculation Method for K FORS Trees Both SLH-DSA signing and verification involve calculating the public key FORS_PK corresponding to k FORS trees (the difference is that FORS tree processing in signing requires traversing all nodes in the tree, while FORS tree processing in verification only requires the selected leaf node and its authentication path, so the latter is much faster).

[0191] Each FORS tree's root node has a corresponding n-byte hash value. k FORS trees would have k*n bytes of data, with a maximum of k=35 and n=32, totaling 1120 bytes. The conventional approach is to process each FORS tree, obtain its root node hash value, store it, and then, after processing k FORS trees, concatenate these k hash values ​​into a message. The T function is then used to retrieve the public key of the k FORS trees.

[0192] The improvement here lies in splitting the T function into three functions: T_init, T_update, and T_final. This employs a segmented hash-like approach, with these three functions maintaining the same context. Specifically, T_init completes context initialization, inputs PK.seed and ADRS, and updates the state.

[0193] T_update can take segmented messages as input and update the status.

[0194] T_final completes the input and obtains the final result, which is an n-byte hash value.

[0195] The context needs to occupy some memory space. Specifically, the context size of the T function using the three hash algorithms is shown in Table 1 below.

[0196] Table 1

[0197] The new method alternates between calculating the hash of the root node of a FORS tree and processing that hash using the T_update function. Compared to the 1120 bytes of memory required for direct storage, the T function context here occupies a maximum of 340 bytes, resulting in significant memory savings. The detailed process of the new method is given below, as follows: Figure 8 As shown.

[0198] S801, before processing the first FORS tree, instantiates a T function context (T_init(PK.seed, ADRS)), that is, calls the T_init interface to clear the context, and then inputs PK.seed and ADRS. Specifically, For cases using the SHAKE256 algorithm, simply write PK.seed||ADRS into the context cache and record its length n+32 bytes. Since the maximum value of n is 32, and n+32 bytes is less than the block length of 136 bytes, it will not trigger a hash iteration calculation.

[0199] When using the SHA256 algorithm, the input is PK.seed||00…00||ADRSC, where 00…00 represents 0 bytes from 64 to n bytes, and ADRSC is 22 bytes. Since PK.seed||00…00 is exactly one block, it can trigger one SHA256 compression iteration calculation. This calculation result can be pre-calculated (i.e., sha256_iv in the parameter initialization area) and written as IV to the hash accelerator. At this time, it is only necessary to write ADRSC to the buffer in the context and record the current input message length as 86 bytes (64+22).

[0200] The process for using the SHA512 algorithm is similar to that for the SHA256 algorithm, with the difference being that the number of zero bytes padded in the middle is 128-n, because the block length of the SHA512 algorithm is 128 bytes (the iteration value corresponding to this block is sha512_iv in the parameter initialization region). In addition, the current input message length recorded in the context is 150 bytes (128+22).

[0201] S802 processes the first FORS tree sequentially to obtain the hash value corresponding to its root node. Then, it calls the segmented T_update interface, inputs the hash value, and obtains the first iteration value.

[0202] S803 processes the second FORS tree sequentially to obtain the hash value corresponding to its root node. Then, it calls the segmented T_update interface, inputting the hash value and the first iteration value to obtain the second iteration value.

[0203] S804 continues processing until the Kth FORS tree is reached, obtaining the hash value corresponding to its root node. Then, the segmented T_update interface is called, inputting the hash value and the previous iteration value (the (k-1)th iteration value) to obtain the kth iteration value.

[0204] S805 calls the T_final interface, and finally obtains the public keys of these k FORS trees.

[0205] S806 outputs the public key FORS_PK of the FORS tree.

[0206] 5.2. WOTS+ Public Key Calculation Method During key pair generation or signing, it is necessary to calculate the leaf nodes of the selected Merkle subtree in the supertree. Each leaf node of the Merkle subtree corresponds to a WOTS+ public key. Similarly, during signature verification, it is necessary to calculate the WOTS+ public key corresponding to the leaf node from the WOTS+ signature.

[0207] Calculating a WOTS+ public key requires 2*n+3 hash chains (for key pair generation or signature generation, each hash chain starts iteratively from the initial position, i.e., the secret value of each hash chain; for the signature verification process, it starts from the position corresponding to the signature of each hash chain). Considering that n is at most 32, there are a maximum of 67 hash chains. Each chain eventually yields an n-byte hash value, so the maximum total memory space required is 67*32=2144 bytes.

[0208] This method uses a similar approach to the FORS tree public key method described above, eliminating the need for 2144 bytes of memory space and requiring only a maximum of 340 bytes of segmented T-function context space, saving approximately 2KB of memory. The calculation process is as follows: Figure 9 As shown.

[0209] S901, before processing the first hash chain, instantiate a T function context (T_init(PK.seed,ADRS)).

[0210] S902 processes the first hash chain sequentially to obtain the hash value corresponding to its final node. Then, it calls the segmented T_update interface, inputs the hash value, and obtains the first iteration value.

[0211] S903 processes the second hash chain sequentially to obtain the hash value corresponding to its final node. Then, it calls the segmented T_update interface, inputting the hash value and the first iteration value to obtain the second iteration value.

[0212] S904, until the nth hash chain is processed, obtaining the hash value corresponding to its final node. Then, the segmented T_update interface is called, inputting the hash value and the previous iteration value (n-1th iteration value), to obtain the nth iteration value.

[0213] S905 calls the T_final interface and ultimately obtains the WOTS+ public key WOTS_PK.

[0214] S906 outputs the public key WOTS_PK of WOTS+.

[0215] In simple terms, compared to the case of calculating the FORS public key above, the FORS tree processing here is replaced with hash chain processing. Each dot in the diagram represents an n-byte hash value.

[0216] Specifically, in the key generation or signing process, each hash chain is processed starting from the initial secret value (the circle filled with diagonal lines in the diagram), iterating 15 times to obtain the end point of the hash chain (the circle filled with dots in the diagram), and then inputting it into the T_update interface.

[0217] If it is a signature verification process, it starts from the signature node in each hash chain, iterates up to 15 times, and then reaches the endpoint, which is then sent to the T_update interface for input.

[0218] On a chip that only supports the SHA2 algorithm (including SHA256 and SHA512), the method of this application can be used to implement the SLH-DSA algorithm, as shown in Table 2 below. It supports the following six modes (the mode only needs to be specified during algorithm initialization). Considering that the chip originally used the RSA / ECDSA algorithm for firmware signature verification (only legitimate firmware can pass the signature verification, and only after successful verification can the firmware run), it can be upgraded to use the SLH-DSA algorithm for firmware signature verification.

[0219] Table 2

[0220] It is evident that signature verification at 100MHz only takes tens to over 100 milliseconds, which prevents the verification process from taking too long. Furthermore, implementing only the SLH-DSA signature verification algorithm only increases the code size by 3KB, and it uses less than 1KB of function stack memory, making it highly practical.

[0221] Of course, if the chip has an accelerator for the SHAKE algorithm, the other six modes can also be implemented at a very low cost.

[0222] While the aforementioned methods rely on existing hash calculation accelerators on the device to implement the SLH-DSA algorithm, these methods can also be used when designing new chips and developing dedicated hardware to implement the SLH-DSA algorithm. This can save considerable memory usage, reduce chip area, and lower costs. In the Internet of Things (IoT) and on large-scale applications, the cost savings will be even greater, and it will also promote the widespread application of post-quantum cryptography algorithms.

[0223] This application provides a message signature device 100, applied to a chip, such as... Figure 10 As shown, the message signature device 100 includes...

[0224] in: The first initialization unit 1001 is used to initialize the T context of the tree hash function T; the T context includes: cache field value, data size field value, and iteration field value; The first partitioning unit 1002 is used to partition the initialized cache field value and multiple node hash values ​​according to the predefined data block size to obtain multiple data blocks, and to update the initialized cache field value and the initialized data size field value during the partitioning process. The first operation unit 1003 is used to perform hash iteration operation on multiple data blocks when the updated cache field value is empty and the updated data size field value is equal to the total data size, and to update the initialized iteration field value during the hash iteration operation. The first determining unit 1004 is used to determine the first signature value based on the updated iterative field value.

[0225] In some embodiments, the first initialization unit is further configured to, under the condition that the preset rule is the first rule, determine the public key seed and address as the initialized cache field value, determine the total size of the public key seed and address as the initialized data size field value, and determine the default iteration value as the initialized iteration field value; the address is used to identify the calculation process of the current function T; under the condition that the preset rule is the second rule, determine the address as the initialized cache field value, determine the size of the address as the initialized data size field value, and determine the initial iteration value as the initialized iteration field value; the initial iteration value is obtained by hashing the filled public key seed; the first rule is different from the second rule.

[0226] In some embodiments, the first partitioning unit is further configured to determine the sum of the initialized cache field value and the first node hash value among the node hash values; if the sum is less than the data block size, the initialized cache field value is updated to the initialized cache field value and the first node hash value; if the sum is equal to the data block size, the initialized cache field value and the first node hash value are determined as the first data block, and the initialized cache field value is updated to empty; if the sum is greater than the data block size, the initialized cache field value and the first node hash value are determined as the first data block, and the initialized cache field value is updated to the portion of the initialized cache field value and the first node hash value that exceeds the data block size; the initialized data size field value is updated to the sum, until multiple node hash values ​​are analyzed and multiple data blocks are obtained.

[0227] In some embodiments, the first operation unit is further configured to perform a hash operation on the initialized iteration field value and the first data block among the multiple data blocks to obtain a first iteration value, and update the initialized iteration field value to the first iteration value; the first determination unit is further configured to determine the updated iteration field value as the first signature value after the hash operation has been performed on all the multiple data blocks.

[0228] In some embodiments, the message signature determination device further includes: The second determining unit is used to determine multiple segmented messages in the message to be processed when the size of the message to be processed is greater than a preset threshold, or when the message to be processed is received multiple times. The second initialization unit is used to initialize the HMAC context of the message-oriented pseudo-random function PRFmsg. The second partitioning unit is used to partition the initialized PRFmsg function context and multiple segmented messages according to the data block size to obtain multiple first message data. The second processing unit is used to perform hash operations on multiple first message data to obtain a second signature value; the second signature value is used to generate multiple node hash values.

[0229] In some embodiments, the second initialization unit is further configured to store the first value in the cache of the HMAC context; the first value is the value obtained by XORing the preprocessed key and the first padding constant; the first hash context in the HMAC context is initialized, and the first value is input into the first hash context.

[0230] In some embodiments, the second arithmetic unit is further configured to perform a hash operation on a plurality of first message data to obtain a first hash value; perform an XOR operation on the preprocessed key and the second padding constant to obtain a second value; and perform a hash operation on the first hash value and the second value to obtain a second signature value.

[0231] In some embodiments, the message signature determination device further includes: The third initialization unit is used to initialize the Hmsg context of the message-oriented hash function Hmsg based on the second signature value; The third partitioning unit is used to partition the initialized Hmsg function context and multiple segmented messages according to the data block size, so as to obtain multiple second message data. The third processing unit is used to perform hash operations on multiple second message data to obtain a hash digest.

[0232] In some embodiments, the third initialization unit is further configured to record the second signature value in the Hmsg context; initialize the second hash context in the Hmsg context, and input the second signature value, the public key seed, and the public key root node value into the second hash context.

[0233] In some embodiments, the message signature determination device further includes: The third determining unit is used to determine the global parameters and set the same function pointer for the pseudo-random function PRF, the compression function F, the hash function H, and the T function; the global parameters represent the parameters needed in the hash operation process; The storage unit is used to store global parameters, PRF functions, F functions, H functions, and T functions that share the same function pointer within the structure.

[0234] It should be noted that the message signature device provided in this application embodiment includes all the units included, which can be implemented by a processor in an electronic device; of course, it 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.

[0235] 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.

[0236] It should be noted that, in the embodiments of this application, if the above-described message signature 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.

[0237] This application provides an electronic device that can implement the message signature method described above.

[0238] In one example, reference Figure 11 The electronic device 110, as shown, includes: a processor 1101, at least one communication bus 1102, a user interface 1103, at least one external communication interface 1104, and a memory 1105. The communication bus 1102 is configured to enable communication between these components. The user interface 1103 may include a display screen, and the external communication interface 1104 may include standard wired and wireless interfaces.

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

[0240] 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 message signature methods provided in the above embodiments.

[0241] 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 message signature methods provided in the above embodiments.

[0242] 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.

[0243] 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.

[0244] 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.

[0245] 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.

[0246] 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.

[0247] 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.

[0248] 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.

[0249] 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.

[0250] 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 message signature method, applied to a chip, characterized in that, The method includes: The T context of the tree hash function T is initialized; the T context includes: cache field value, data size field value, and iteration field value; According to the predefined data block size, the initialized cache field value and multiple node hash values ​​are divided to obtain multiple data blocks, and the initialized cache field value and initialized data size field value are updated during the division process. If the updated cache field value is empty and the updated data size field value is equal to the total data size, perform a hash iteration operation on the multiple data blocks and update the initialized iteration field value during the hash iteration operation. The first signature value is determined based on the updated iterative field value.

2. The method according to claim 1, characterized in that, The initialization of the T context for the tree hash function T includes: The cache field value, the data size field value, and the iteration field value are cleared to zero. With the preset rule set to the first rule, the public key seed and address are determined as the initialized cache field value, the total size of the public key seed and the address is determined as the initialized data size field value, and the default iteration value is determined as the initialized iteration field value; the address is used to identify the calculation process of the current T function; When the preset rule is the second rule, the address is determined as the initialized cache field value, the size of the address is determined as the initialized data size field value, and the initial iteration value is determined as the initialized iteration field value; the initial iteration value is obtained by hashing the filled public key seed; the first rule is different from the second rule.

3. The method according to claim 2, characterized in that, The process of dividing the initialized cache field value and multiple node hash values ​​into multiple data blocks according to a predefined data block size, and updating the initialized cache field value and initialized data size field value during the division process, includes: Determine the sum of the size of the initialized cache field value and the size of the first node hash value in the node hash values; If the summation result is less than the data block size, the initialized cache field value is updated to the initialized cache field value and the hash value of the first node; If the summation result equals the data block size, the initialized cache field value and the first node hash value are used to determine the first data block, and the initialized cache field value is updated to empty; If the summation result is greater than the data block size, the initialized cache field value and the first node hash value are determined as the first data block, and the initialized cache field value is updated to the portion of the initialized cache field value and the first node hash value that exceeds the data block size; The initialized data size field value is updated to the summation result until the hash values ​​of the multiple nodes are analyzed, and the multiple data blocks are obtained.

4. The method according to claim 1, characterized in that, The step of performing hash iteration operations on the plurality of data blocks and updating the initialized iteration field values ​​during the hash iteration operation includes: A hash operation is performed on the initialized iteration field value and the first data block among the plurality of data blocks to obtain the first iteration value, and the initialized iteration field value is updated to the first iteration value; Accordingly, determining the first signature value based on the updated iterative field value includes: The updated iterative field value is determined as the first signature value only after all the hash operations on the multiple data blocks have been completed.

5. The method according to claim 1, characterized in that, The method further includes: If the size of the message to be processed is greater than a preset threshold, or if the message to be processed is received multiple times, then multiple segmented messages in the message to be processed are identified. Initialize the HMAC context of the message-oriented pseudo-random function PRFmsg; According to the data block size, the initialized PRFmsg function context and the multiple segmented messages are divided to obtain multiple first message data; A hash operation is performed on the plurality of first message data to obtain a second signature value; the second signature value is used to generate the plurality of node hash values.

6. The method according to claim 5, characterized in that, The initialization of the HMAC context for the message-oriented pseudo-random function PRFmsg includes: The first value is stored in the cache of the HMAC context; the first value is obtained by XORing the preprocessed key and the first padding constant. The first hash context in the HMAC context is initialized, and the first value is input into the first hash context.

7. The method according to claim 5, characterized in that, The step of performing a hash operation on the plurality of first message data to obtain a second signature value includes: A hash operation is performed on the plurality of first message data to obtain a first hash value; Perform an XOR operation on the preprocessed key and the second padding constant to obtain the second value; The first hash value and the second value are hashed to obtain the second signature value.

8. The method according to claim 5, characterized in that, The method further includes: The Hmsg context of the message-oriented hash function Hmsg is initialized based on the second signature value; According to the data block size, the initialized Hmsg function context and the multiple segmented messages are divided to obtain multiple second message data; A hash operation is performed on the multiple second message data to obtain a hash digest.

9. The method according to claim 8, characterized in that, The initialization of the Hmsg context of the message-oriented hash function Hmsg based on the second signature value includes: The second signature value is recorded in the Hmsg context; The second hash context in the Hmsg context is initialized, and the second signature value, public key seed, and public key root node value are input into the second hash context.

10. The method according to claim 1, characterized in that, The method further includes: Determine global parameters and set the same function pointer for the pseudo-random function PRF, the compression function F, the hash function H, and the T function; the global parameters represent the parameters needed in the hash operation process; The structure stores the global parameters, the PRF function, the F function, the H function, and the T function, which have the same function pointer.

Images