Chained collaborative signature method and system based on NTRU lattice

Abstract

The invention provides a chain type collaborative signature method and system based on an NTRU lattice, and the method comprises the steps: optimizing the communication process of collaborative signature into chain type transmission, enabling each signature party to carry out the registration before chain type signature, generating a part of signature after the registration is completed, and transmitting the part of signature to an aggregation party, and the aggregation party aggregates to obtain the collaborative signature and sends the collaborative signature to the verification party for verification. According to the chain communication mechanism, the problem of frequent interaction caused by multiple broadcast operations can be avoided, so that delay and energy consumption are reduced, and the communication efficiency of the collaborative signature is improved. Moreover, the signer only needs to verify the data of the precursor node and add the signature of the signer, so that the number of interaction times is compressed to single linear transmission, and the communication overhead is reduced as much as possible while the communication security is ensured.

Description

Technical Field

[0001] This application relates to the field of quantum communication technology, and more specifically, to a chain-based collaborative signature method and system based on NTRU lattice. Background Technology

[0002] The development of quantum computing technology brings security threats. Traditional RSA / ECC (Rivest-Shamir-Adleman / Elliptic Curve Cryptography, an asymmetric encryption algorithm based on the problem of factoring large integers) algorithms are vulnerable to quantum attacks. To address this issue, existing technologies often employ quantum-resistant collaborative signature schemes based on lattice cryptography.

[0003] Existing quantum-resistant collaborative signature schemes based on lattice cryptography employ a broadcast-based interaction architecture, still relying on high-frequency broadcasting and multiple rounds of interaction, resulting in high communication overhead and a large number of interaction rounds. In resource-constrained scenarios such as IoT edge devices and low-bandwidth mobile terminals, frequent broadcasting can cause serious latency and energy consumption problems, undermining the theoretical advantages of lattice cryptography.

[0004] Therefore, improving the communication efficiency and security in the lattice cryptography collaborative signature process has become a problem that needs to be solved. Summary of the Invention

[0005] The purpose of this application is to address the shortcomings of the prior art by providing a chain-based collaborative signature method and system based on NTRU lattice, so as to solve the problem that the communication efficiency and security in the lattice cryptographic collaborative signature process of the prior art need to be improved.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows: Firstly, this application provides a chain-based collaborative signature method based on the NTRU lattice, applied to a chain-based collaborative signature system based on the NTRU lattice, the system comprising: a private key generator, multiple signers, and a verifier; the method comprising: The private key generator generates short base parameters, public keys, hash function sets, and private keys of each signer in an NTRU lattice according to predefined system parameters. It then sends the private keys of each signer to each signer and sends the public keys, the short base parameters, and the hash function sets to each signer and the verifier. Each signer corresponding to the message to be signed performs chain-like pre-signature registration based on the public key, the short base parameter and the set of hash functions to obtain the pre-signature registration result, which includes: a list of signed messages and a cumulative value. After all signers have completed the pre-signing registration, each signer generates a partial signature based on the accumulated value, the set of hash functions, the identity information of each signer, the identifier of the signed list, the private key of each signer, and the message to be signed, and sends the partial signature to the aggregator among the signers; The aggregator performs aggregator processing on each of the partial signatures to obtain a collaborative signature, which is then verified by the verifier based on the public key, the short base parameter, and the set of hash functions.

[0007] Optionally, the set of hash functions includes: identity-binding hash functions, commitment-generated hash functions, and challenge-generated hash functions; The process by which the private key generator generates short base parameters, public keys, hash function sets, and private keys for each signer based on predefined system parameters includes: Based on the system parameters, the trapdoor generation algorithm is invoked to generate short basis parameters and a public key for the NTRU lattice; Based on the system parameters, define the identity binding hash function, the commitment generation hash function, and the challenge generation hash function; The private key of each signer is generated based on the identity binding hash function, the identity information of each signer, the system parameters, and the short base parameters.

[0008] Optionally, generating the private key for each signer based on the identity binding hash function, the identity information of each signer, the system parameters, and the short base parameter includes: The identity information of the signer is hashed according to the identity binding hash function to obtain the identity hash value; Under preset constraints, Gaussian sampling calculations are performed on the system parameters, the short base parameters, and the identity hash value to obtain the private keys of each signer. The constraints are determined based on the identity hash value and the system parameters.

[0009] Optionally, each of the signers performs a chain-like pre-signature registration based on the public key, the short base parameter, and the set of hash functions to obtain a pre-signature registration result, including: Each signer, except the last signer, generates a commitment value and an auxiliary value based on the public key and the set of hash functions. The signer's identity information, the commitment value, and the auxiliary value are recorded in the signed list, the cumulative value is updated, and the signed list and the cumulative value are sent to the next signer according to the signer list corresponding to the message to be signed. The last signer generates a commitment value and an auxiliary value based on the public key and the set of hash functions, records the identity information of the last signer, the commitment value, and the auxiliary value in the signed list, updates the cumulative value, and broadcasts the cumulative value to each signer recorded in the signed list.

[0010] Optionally, before updating the cumulative value, each signer other than the last signer generates a commitment value and an auxiliary value based on the public key and the set of hash functions, records the signer's identity information, the commitment value, and the auxiliary value in the signed list, the process further includes: If the signer is not the first signer, the signed list is verified. If the verification is successful, a commitment value and an auxiliary value are generated based on the public key and the set of hash functions. The signer's identity information, the commitment value, and the auxiliary value are recorded in the signed list, and the cumulative value is updated.

[0011] Optionally, the process by which the signer generates the commitment value and auxiliary value based on the public key and the set of hash functions includes: The first temporary vector and the second temporary vector are obtained by sampling from a preset Gaussian distribution; The auxiliary value is determined based on the first temporary vector, the second temporary vector, and the public key; The commitment value is generated by generating a hash function based on the auxiliary value and the commitments in the hash function set.

[0012] Optionally, each signer generates a partial signature based on the accumulated value, the set of hash functions, the identity information of each signer, the identifier of the signed list, the private key of each signer, and the message to be signed, including: The cumulative value, the signer's identity information, the identifier of the signed list, and the message to be signed are used as input parameters, and the challenge value of the signer is generated by the challenge generation hash function in the hash function set. A partial signature of the signer is generated based on the signer's challenge value and the signer's private key.

[0013] Optionally, the aggregator performs aggregation processing on each of the partial signatures to obtain a collaborative signature, including: The individual signatures are aggregated to obtain a signature set; The collaborative signature is obtained by combining the signature set and the cumulative value.

[0014] Optionally, the process by which the verifier verifies the collaborative signature based on the public key, the short base parameter, and the set of hash functions includes: The collaborative signature is decomposed to obtain the signature set; The signature set is subjected to a norm constraint check. If the signature set does not meet the norm constraint, the signature set is rejected. If the signature set satisfies the norm constraint, then an equality aggregation check is performed on the signature set. If the signature set does not satisfy the equality constraint, then the signature set is rejected. If the signature set satisfies the equality constraint, then the signature set is accepted.

[0015] Secondly, this application provides a chain-based collaborative signature system based on the NTRU lattice, including a private key generator, multiple signers, and a verifier. When the system is running, the private key generator, multiple signers, and verifiers are respectively used to perform the steps performed by the private key generator, multiple signers, and verifiers as described in the first aspect.

[0016] The beneficial effects of this application are as follows: By adopting a parameter design based on the NTRU lattice, the entire system can be protected against quantum attacks, thereby improving system security. Simultaneously, by generating public keys, short base parameters, hash functions, and private keys through a private key generator, it is ensured that all signers use unified rules, thus improving the reliability of system communication. Signers register in a chain-like manner before signing, ensuring data consistency and availability among signers. Furthermore, the one-way transmission method effectively reduces communication volume compared to broadcast interaction, making it more suitable for low-bandwidth scenarios. Pre-signing registration also ensures that the temporary data of all signers is traceable and tamper-proof, providing a reliable foundation for the generation of subsequent partial signatures. Each signer generates partial signatures based on the same cumulative value, the identifier of the signed list, the hash function set, the message to be signed, the identity information of each signer, and the private key of each signer. This ensures the aggregability of signatures and guarantees the traceability of signature authorization. Moreover, each signer can generate its own partial signature in parallel, reducing the time complexity of partial signature generation and significantly improving the efficiency of multi-party signing, making it more suitable for low-latency scenarios. Verifiers can perform lightweight verification of collaborative signatures using a globally unified public key, short base parameters, and a set of hash functions. This not only improves the efficiency of signature verification but also enhances the security of verification by using NTRU-based parameters.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This illustration shows a schematic diagram of the architecture of a chain-based collaborative signature system based on an NTRU lattice, provided in an embodiment of this application. Figure 2 A flowchart of a chain-based collaborative signature method based on an NTRU lattice provided in an embodiment of this application is shown; Figure 3 This document illustrates a flowchart of a method for generating short base parameters, a public key, a set of hash functions, and a private key, as provided in an embodiment of this application. Figure 4 This application provides a flowchart for generating a private key according to an embodiment. Figure 5 This document illustrates a flowchart of a chain-like pre-signature registration method provided in an embodiment of this application. Figure 6 This document illustrates a flowchart of a method for generating commitment values ​​and auxiliary values, as provided in an embodiment of this application. Figure 7 This document illustrates a flowchart of a partial signature generation method provided in an embodiment of this application. Figure 8 This document illustrates a flowchart of a collaborative signature generation method provided in an embodiment of this application. Figure 9 This document illustrates a flowchart of a collaborative signature verification method provided in an embodiment of this application. Figure 10 The diagram shows an overall flowchart of a chain-based collaborative signature method based on an NTRU lattice provided in an embodiment of this application. Figure 11 This illustration shows a schematic diagram of a chain-based collaborative signature system based on an NTRU lattice, provided in an embodiment of this application. Figure 12 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0022] Existing quantum-resistant collaborative signature schemes based on lattice cryptography employ a broadcast-based interaction architecture. To ensure signature consistency and verifiability, each participant must broadcast temporary parameters to all other members and wait for global confirmation, resulting in a high number of interaction rounds and communication overhead. Especially in resource-constrained scenarios such as IoT edge devices and low-bandwidth mobile terminals, frequent broadcast operations can cause severe latency and energy consumption problems, significantly undermining the theoretical advantages of lattice cryptography. While existing schemes attempt to optimize communication through tree-like topology or aggregation algorithms, they still struggle to achieve linear complexity while maintaining identity verifiability.

[0023] Therefore, improving the communication efficiency and security in the lattice cryptography collaborative signature process has become a problem that needs to be solved.

[0024] Based on this, this application proposes a chain-based collaborative signature method based on the NTRU lattice (NTRU Cryptosystem). By optimizing the communication process of collaborative signature into a chain-like transmission, it avoids the problem of frequent interactions caused by multiple broadcast operations, thereby reducing latency and energy consumption and improving the communication efficiency of collaborative signature. Furthermore, the signer only needs to verify the data of the predecessor node and append its own signature, thus compressing the number of interactions to a single linear transmission, thereby ensuring communication security while minimizing communication overhead.

[0025] The method described in this application can be applied to... Figure 1 In the chain-based collaborative signature system based on the NTRU lattice shown, refer to Figure 1The system includes a Private Key Generator (PKG), multiple signers, and a verifier. Among the multiple signers is an aggregator. The private key generator is used to generate public-private key pairs and parameters required during communication, and distributes them to the signers and verifiers. When a message to be signed needs to be signed, the signers first register before signing using a chain signing method. After all signers have completed their registration, the aggregator can collect the partial signatures generated by all signers and send the aggregated signature to the verifier for verification. After the verification is successful, the verifier accepts the signatures from each signer, thus completing the entire collaborative signing process.

[0026] The aggregator can be the last signer among multiple signers, that is, the last signer to register before signing. The last signer collects partial signatures after registration, which can further reduce communication overhead. The aggregator can also be a third party other than the signer and the verifier. This application does not impose any restrictions on this.

[0027] Next, combine Figure 2 This paper describes the chain-based collaborative signature method based on the NTRU lattice, which can be applied to... Figure 1 In the chain-based collaborative signature system based on the NTRU lattice shown, refer to Figure 2 The method includes: S201. The private key generator generates short base parameters, public keys, hash function sets, and private keys of each signer in the NTRU lattice according to predefined system parameters. It sends the private keys of each signer to each signer and sends the public keys, short base parameters, and hash function sets to each signer and verifier.

[0028] The private key generator can be an initialization center deployed on a cloud server, possessing the authority to generate all core parameters and its behavior is tamper-proof. During the initialization phase, the private key generator can generate short base parameters in NTRU format, public keys for communication, a set of hash functions, and private keys of each signer connected to the server based on predefined system parameters. Before signing, it distributes the parameters and public-private key pairs, at which point the parameters and public-private key pairs can take effect in multiple message signing processes.

[0029] In another possible implementation, the private key generator can send the parameters and public-private key pairs to each signer and verifier corresponding to the message to be signed before each message signing, and after generating the short base parameters, public key, hash function set, and private key of each signer in the NTRU format.

[0030] Optionally, the NTRU lattice is a lattice structure based on a polynomial ring. The short basis parameters can be a set of short vector bases in the NTRU lattice, which is a set of matrices in the lattice that satisfy a specific matrix structure. The short basis parameters can be used to generate the private key, while the public key is a globally public verification parameter generated from the core polynomial of the NTRU lattice.

[0031] The hash function set includes identity-bound hash functions, commitment-generating hash functions, and challenge-generating hash functions. Each function in this set can convert non-celled elements into celled, operable elements while introducing randomness to prevent forgery or reuse of the signer's identity. Specifically, the identity-bound hash function maps the signer's identity identifier, the commitment-generating hash function encrypts auxiliary values ​​to prevent the signer from tampering with them, and the challenge-generating function generates challenge values, thus binding the signature to the message to be signed.

[0032] Optionally, the private key generator can send the private keys of each signer to each signer through a secure transmission channel, and broadcast the public key, short base parameters, and hash function set to each signer and verifier.

[0033] By employing an NTRU-based parameter design, the entire system can be protected against quantum attacks, thereby enhancing system security. Simultaneously, by using a private key generator to generate the public key, short base parameters, hash function, and private key, it is ensured that all signing parties use the same rules, thus improving the reliability of system communication.

[0034] S202. Each signer corresponding to the message to be signed performs chain-like pre-signature registration based on the public key, short base parameters, and hash function set to obtain the pre-signature registration result.

[0035] The pre-signature registration results include: a list of signed items and a cumulative value.

[0036] When signing messages, each signer corresponding to the message to be signed can be registered before signing to ensure the data consistency and availability of the signers and avoid the generation of invalid signatures later.

[0037] Optionally, the signatories corresponding to the message to be signed can be a set of authorized signatories related to the message, such as multi-level approval nodes in blockchain transactions, or hierarchical issuing departments of documents. The signatories can be arranged in a preset order to form a signer list, with the order determined based on business rules or other methods. Assuming... Figure 1 The system includes N signers. After the message to be signed is determined, it can be determined that the message to be signed requires the signatures of signer 1, signer 2 and signer M. Therefore, the signers corresponding to the message to be signed are signer 1, signer 2 and signer M.

[0038] In one possible implementation, the private key generator can determine the order of the signers in the signer list, send the message to be signed to each signer corresponding to the message to be signed, and determine the first signer to register before signing in the signer list. Each signer that receives the message to be signed can perform chain-like pre-signing registration.

[0039] In another possible implementation, after determining the message to be signed, the private key generator may not send the message to be signed immediately. Instead, it may determine the first signer based on the signer list and notify each signer corresponding to the message to be signed to perform chained pre-signature registration based on the public key, short base parameters, and hash function set. After the pre-signature registration is completed, the message to be signed is sent to each of the registered signers.

[0040] During the pre-signature registration process, the first signer generates its own registration data based on the public key, short base parameters, and hash function set, adds it to the signed list, and updates the cumulative value. Each signer can receive the registration data from the previous signer, and after verifying the legality of the registration data, generates its own temporary data, adds it to the signed list, updates the cumulative value, and then passes it on to the next signer.

[0041] Optionally, the signed list records the registration data and cumulative value of all participating signers. The registration data is generated by each signer based on their public key, a set of hash functions, and short base parameters. The cumulative value indicates the number of signers who have registered before signing.

[0042] Registering signers in a chain-like manner before signing ensures data consistency and availability across all signers. Furthermore, the one-way transmission method effectively reduces communication overhead compared to broadcast interactions, making it more suitable for low-bandwidth scenarios. Simultaneously, pre-signing registration ensures that all signers' temporary data is traceable and tamper-proof, thus providing a reliable foundation for the generation of subsequent partial signatures.

[0043] S203. After all signers have completed the pre-signing registration, each signer generates a partial signature based on the cumulative value, the set of hash functions, the identity information of each signer, the identifier of the signed list, the private key of each signer, and the message to be signed, and sends the partial signature to the aggregator among the signers.

[0044] Optionally, the signer's identity information can be a signer's identifier, such as a device identifier or a user account. During the registration process before signing, each signer can save an identifier for the signed list, which is globally unique and immutable.

[0045] If the current cumulative value is equal to the number of signers in the signer list corresponding to the message to be signed, then it can be assumed that all signers have completed the pre-signing registration. At this time, the last signer can notify all signers to generate their respective partial signatures. After each signer generates a partial signature, it can send the partial signature to the aggregator among the signers.

[0046] It should be noted that after the last signer completes the signer registration, the latest cumulative value can be broadcast to all signers. After receiving the latest cumulative value, each signer can generate a partial signature based on the latest cumulative value, its own stored set of hash functions, its own identity information, the identifier of the signed list saved during the pre-signing registration process, and its own private key.

[0047] In this process, the aggregator among the signers can be the last signer registered before signing. When the last signer broadcasts the latest cumulative value, each signer can obtain the communication address of the last signer, and thus, after generating a partial signature, send the partial signature to the last signer based on the communication address for aggregation processing.

[0048] S204. The aggregator performs aggregator processing on each part of the signature to obtain a collaborative signature, which is then verified by the verifier based on the public key, short base parameters, and set of hash functions.

[0049] Optionally, after aggregating the partial signatures of all signers to obtain a collaborative signature, the aggregator can send the collaborative signature to the verifier. The verifier verifies the collaborative signature based on the public key, short base parameters, and hash function set sent by the private key generator. If the verification is successful, the aggregator accepts the partial signatures of each signer; if the verification fails, the aggregator rejects the signature.

[0050] In this embodiment, by employing a parameter design based on the NTRU lattice, the entire system can be protected against quantum attacks, thereby enhancing system security. Simultaneously, generating public keys, short base parameters, hash functions, and private keys via a private key generator ensures that all signers use unified rules, thus improving the reliability of system communication. Signers register in a chain-like manner before signing, ensuring data consistency and availability among signers. Furthermore, the one-way transmission method effectively reduces communication volume compared to broadcast interaction, making it more suitable for low-bandwidth scenarios. Pre-signing registration also ensures that all signers' temporary data is traceable and tamper-proof, providing a reliable foundation for subsequent partial signature generation. Each signer generates partial signatures based on the same cumulative value, the identifier of the signed list, the hash function set, the message to be signed, each signer's identity information, and each signer's private key. This ensures signature aggregability and guarantees the traceability of signature authorization. Moreover, each signer can generate their partial signatures in parallel, reducing the time complexity of partial signature generation and significantly improving the efficiency of multi-party signing, making it more suitable for low-latency scenarios. Verifiers can perform lightweight verification of collaborative signatures using a globally unified public key, short base parameters, and a set of hash functions. This not only improves the efficiency of signature verification but also enhances the security of verification by using NTRU-based parameters.

[0051] Optionally, the set of hash functions includes: identity-bound hash functions, commitment-generated hash functions, and challenge-generated hash functions.

[0052] like Figure 3 As shown, the process by which the aforementioned private key generator generates short base parameters, public keys, hash function sets, and private keys for each signer based on predefined system parameters includes: S301. Based on system parameters, call the trapdoor generation algorithm to generate short base parameters and public key for the NTRU lattice.

[0053] Optionally, the private key generator can call the algorithm MSetup. Generate system parameters. System parameters include those derived from the modulus prime number. Remaining ring A prime number randomly selected from the middle positive real numbers With Gaussian parameters The Gaussian parameter is a positive real number.

[0054] The private key generator can run the TrapGen trapdoor generation algorithm. Generate NTRU grid short basis parameters and public key .

[0055] in It is a positive integer. For model polynomial ring, , , Represents an anticyclic matrix, specifically expressed as, for polynomials Inverse circular matrix .

[0056] S302. Define identity binding hash function, commitment generation hash function and challenge generation hash function based on system parameters.

[0057] Optionally, the identity binding function can be represented as This is used to map the identity of the signer's non-celled element to a celled element. The commitment generation hash function can be represented as... This is used to encrypt auxiliary values ​​while ensuring that the encrypted auxiliary values ​​remain in-cell elements. The challenge generation function can be represented as: , used to generate challenge values.

[0058] in, Represents a binary string of arbitrary length. The representative length is dimension string, For vectors, Represents the module length.

[0059] S303. Generate the private key of each signer based on the identity binding hash function, the identity information of each signer, system parameters, and short base parameters.

[0060] By generating a private key using an identity-binding hash function, identity information, system parameters, and short base parameters, the private key can be bound to the identity of the signer. Furthermore, the private key generated using short base parameters ensures that only the authorized signer can obtain it, thereby improving the security of system communication.

[0061] Furthermore, such as Figure 4 As shown, in step S303 above, the process of generating the private key for each signer based on the identity binding hash function, the identity information of each signer, system parameters, and short base parameters includes: S401. Perform a hash calculation on the identity information of the signer using the identity binding hash function to obtain the identity hash value.

[0062] Optionally, the signatory's identity is represented as: The identity information can be hashed based on the identity binding hash function to obtain the identity hash value. This maps identity information into elements within the cell.

[0063] S402. Under preset constraints, Gaussian sampling calculation is performed on the system parameters, short base parameters, and identity hash values ​​to obtain the private keys of each signer. The constraints are determined based on the identity hash values ​​and system parameters.

[0064] Alternatively, the Gaussian sampling function SampleGau can be used. The output satisfies the constraints. and The key pair is obtained by combining the key pair to get the private key. .

[0065] in, For short basis parameters, For identity hash value, It is a positive real number in the system parameters.

[0066] In this embodiment, a private key is generated based on the short base parameter, the signer's identity information, and the identity binding hash function. This enables the binding of the private key with the signer's identity and improves the security and reliability of the private key without using the short base parameter.

[0067] The following is a further explanation of the chained pre-signature registration process performed by the aforementioned signers based on their public keys, short base parameters, and hash function sets, to obtain the pre-signature registration results. Figure 5 As shown, the above step S202 includes: S501. Except for the last signer, each signer generates a commitment value and an auxiliary value based on the public key and the set of hash functions. The signer's identity information, commitment value, and auxiliary value are recorded in the signed list, the cumulative value is updated, and the signed list and cumulative value are sent to the next signer according to the signer list corresponding to the message to be signed.

[0068] The list of signers corresponding to the message to be signed can be a list obtained by arranging the authorized signers of the message to be signed in a preset order. The order can be determined based on business rules or the length of the communication link between each signer, and there are no specific restrictions here.

[0069] For example, the N signers can be arranged in order to obtain a list of signers. .

[0070] Optionally, the auxiliary value can be a temporary parameter generated by each signer, serving as the atomic unit for generating the cumulative value. The cumulative value is obtained by summing the auxiliary values ​​of all signers, providing a unified benchmark for the generation of subsequent challenge values. Furthermore, transmitting only the cumulative value avoids repeatedly transmitting all auxiliary values, reducing communication overhead. The commitment value can be a digital fingerprint calculated by generating a hash function from the commitments in the hash function set, serving as a verification credential for the validity of the preceding data. The next signer can determine whether the data has been tampered with by verifying the commitment value.

[0071] The signer list records the identity information of all authorized signers, while the signed list records the identity information of each signer who has registered before signing. By comparing the signed list and the signer list, it is possible to determine which signers have not yet registered before signing, and based on this, the signed list and the accumulated value are forwarded to ensure the chain transmission of the signed list and the accumulated value among the signers.

[0072] It should be noted that each signer may not forward the signed list and cumulative value in the order specified in the signer list. Instead, before each forwarding, they may compare the signer list and the signed list, identify the signers who have not yet registered for signing, and forward the signed list and cumulative value to the signers who have not yet registered for signing.

[0073] As one possible implementation, the private key generator can control the forwarding process of the signed list and the accumulated value. That is, the private key generator monitors the update process of the signed list and the accumulated value through a process module, and forwards the signed list and the accumulated value to each signer in the order listed in the signer list. For example, after signer 1 completes the update of the signed list and the accumulated value, the process module detects the data update and can forward the signed list to the next signer in the signer list after signer 1.

[0074] S502. The last signer generates a commitment value and an auxiliary value based on the public key and the set of hash functions. The identity information, commitment value, and auxiliary value of the last signer are recorded in the signed list. The cumulative value is updated, and the cumulative value is broadcast to each signer recorded in the signed list according to the signed list.

[0075] Optionally, the last signer can obtain the identity information of the other signers based on the signed list, and broadcast the cumulative value to each signer recorded in the signed list according to the identity information.

[0076] Optionally, each signer other than the last signer generates a commitment value and an auxiliary value based on the public key and the set of hash functions. The signer's identity information, commitment value, and auxiliary value are recorded in the signed list. Before updating the cumulative value, the process also includes: If the signer is not the first signer, the signed list is verified. If the verification is successful, a commitment value and an auxiliary value are generated based on the public key and the set of hash functions. The signer's identity information, commitment value, and auxiliary value are recorded in the signed list, and the cumulative value is updated.

[0077] The first signer can directly generate a commitment value and an auxiliary value based on the public key and the set of hash functions. The signer's identity information, commitment value, and auxiliary value are recorded in the signed list, the cumulative value is updated, and the signed list and cumulative value are sent to the next signer.

[0078] Other signers besides the first signer can first verify the signed list to see if it has been tampered with. If the verification is successful, they generate a commitment value and an auxiliary value based on the public key and the set of hash functions. They then record the signer's identity information, commitment value, and auxiliary value in the signed list, update the cumulative value, and send the signed list and cumulative value to the next signer.

[0079] Optionally, the signed list can be represented as ,in, This indicates the identity information of the signatory. Indicates the commitment value. To represent negative values, the cumulative value can be represented as... The cumulative value refers to the sum of the auxiliary values ​​of all signatories who have registered before signing.

[0080] Verifying the signed list can involve checking each item in the signed list one by one. Does it meet the requirements? The process involves generating a hash function to calculate the auxiliary values ​​for each item and then checking if the calculated commitment value matches the commitment values ​​already recorded in the list. If all matches, the auxiliary values ​​have not been tampered with, and the verification passes. If at least one match is not met, the signature process terminates.

[0081] In this embodiment of the application, the pre-signature registration is completed by using the signed list and the cumulative value, which can achieve the non-duplication of auxiliary values ​​and reduce communication overhead. By registering identity information, auxiliary values ​​and commitment values ​​in the signed list, the immutability of the information of each signer can be guaranteed.

[0082] The following is a further explanation of the process by which the signer generates the commitment value and auxiliary value based on the public key and the set of hash functions, such as... Figure 6 As shown, the above process includes: S601. Sample the first temporary vector and the second temporary vector from the preset Gaussian distribution.

[0083] Optionally, the signer may generate two short and random temporary vectors using a specific Gaussian distribution, serving as the first temporary vector and the second temporary vector.

[0084] In one possible implementation, sampling can be performed from a Gaussian distribution on an n-dimensional integer lattice to obtain a first temporary vector and a second temporary vector, which can be represented as follows: ,in, Let i be the first temporary vector of the i-th signer. Let i be the second temporary vector of the i-th signer. This represents a Gaussian distribution over an n-dimensional integer lattice.

[0085] S602. Determine the auxiliary value based on the first temporary vector, the second temporary vector, and the public key.

[0086] Alternatively, it can be done through Generate an auxiliary value, where h represents the public key. This represents an auxiliary value.

[0087] S603. Generate a hash function based on the auxiliary value and the commitments in the hash function set, and generate a commitment value.

[0088] Alternatively, auxiliary values ​​can be used as input parameters to the commitment-generating hash function, through... Generate commitment value .

[0089] In this embodiment, by sampling the first and second temporary vectors from a Gaussian distribution, the randomness of the temporary vectors can be guaranteed. Even if an attacker knows the system's public key and preceding data, they cannot deduce the specific value of the temporary vector, thus preventing the forgery of auxiliary values ​​or partial signatures, thereby ensuring the unforgeability of partial signatures. By generating a commitment value and using it as a digital fingerprint for auxiliary values, the immutability of auxiliary values ​​during communication can be guaranteed, further enhancing communication security.

[0090] The following is a further explanation of how each of the aforementioned signers generated a partial signature based on the cumulative value, the set of hash functions, the identity information of each signer, the identifier of the signed list, the private key of each signer, and the message to be signed. Figure 7 As shown, the above process includes: S701. Take the cumulative value, the signer's identity information, the identifier of the signed list, and the message to be signed as input parameters, and generate the signer's challenge value through the challenge generation hash function in the hash function set.

[0091] Optionally, each signer can invoke the challenge generation hash function pre-sent by the private key generator to generate a challenge value. ,in, Indicates the challenge value. This represents the identity information of the i-th signer. This represents the latest cumulative value after the last signer completed the pre-signature registration. Indicates the identifier of the signed list. This indicates a message awaiting signature.

[0092] S702. Generate a partial signature of the signer based on the signer's challenge value and the signer's private key.

[0093] Alternatively, each signatory can sign using a formula. Calculate the partial signature .in,( , Let be the key pair in the private key of the i-th signer. This represents the challenge value of the i-th signer. This represents a partial signature of the i-th signer. This represents the first temporary vector of the i-th signer. Let represent the second temporary vector of the i-th signer, with the probability of application being... Rejecting sampling ensures that the distribution is independent of the key.

[0094] After generating partial signatures, each signer can send its partial signature to the aggregator for signature aggregation, such as... Figure 8 As shown, the process by which the aggregator aggregates the signatures from each part to obtain the collaborative signature includes: S801. Aggregate the signatures of each part to obtain a signature set.

[0095] The aggregator can calculate , obtain the signature set , This indicates partial signatures from each signatory.

[0096] In one possible implementation, if there is an order requirement for the signature set, such as in a hierarchical approval scenario, it is necessary to ensure that the signatures of each signer are arranged according to the approval level. After receiving a portion of the signatures, the aggregator can arrange the partial signatures of each signer according to the hierarchical order indicated in the signer list to obtain the signature set.

[0097] S802. Combine the signature set and the cumulative value to obtain the collaborative signature.

[0098] The aggregator can combine the signature set and the accumulated value to obtain a collaborative signature. .

[0099] After the aggregator completes the signature aggregation, it can send the collaborative signature to the verifier for verification processing, such as... Figure 9As shown, the process by which the verifier verifies the collaborative signature based on the public key, short base parameters, and hash function set includes: S901. Decompose the collaborative signature to obtain a signature set.

[0100] Optionally, the verifier can perform a cutover on the collaborative signature to obtain a signature set. and cumulative value .

[0101] S902. Perform norm constraint checks on the signature set. If the signature set does not meet the norm constraint, then reject the signature set.

[0102] Norm constraints can be used to check Whether it holds true, where ||·|| is the vector norm, N is the total number of signer, σ is the Gaussian parameter, and n is the lattice dimension.

[0103] If the signature set meets the norm constraint, the verification passes and step S903 is executed. If the verification fails, the process is terminated and a signature verification failure message is sent.

[0104] S903. If the signature set satisfies the norm constraint, then perform an equality aggregation check on the signature set. If the signature set does not satisfy the equality constraint, then reject the signature set. If the signature set satisfies the equality constraint, then accept the signature set.

[0105] Alternatively, the signature set can be split into two parts. and , In the corresponding part of the signature , In the corresponding part of the signature The verifier can request challenge values ​​from each collaborating signer and check the equation. Whether it is valid or not.

[0106] If the equation holds true, the signature set satisfies the equality constraint, and the verifier accepts the signature set. If the signature set does not satisfy the equality constraint, the verifier refuses to accept the signature set. If the signature set satisfies the equality constraint, the verifier accepts the signature set.

[0107] In this embodiment, the verifier can achieve lightweight signature verification through two steps: norm checking and equality aggregation, which improves the efficiency of signature verification. At the same time, verification based on NTRU lattice parameters can also ensure the reliability of signature verification.

[0108] Next, combine Figure 10 This paper describes the overall process of the collaborative signature method in this application. (Refer to...) Figure 10The method flow of this application includes the following steps, and the specific implementation of each step is as described in the foregoing embodiments.

[0109] S1. The private key generator sends the private key, public key, short base parameters, and hash function set of each signer to each signer. S2. The private key generator sends the public key, short base parameters, and a set of hash functions to the verifier. When a message needs to be signed, each signer first performs a chain-like pre-signature registration based on its public key, short base parameters, and hash function set, referring to... Figure 10 Specifically, it includes: S3. The first signer calculates the commitment value and auxiliary value, and updates the list of signed items and the cumulative value; S4. The first signer sends the updated list and cumulative value to the next signer. S5. Each intermediate signer must verify the signed list and cumulative value before registering for signing. Only after the verification is passed will the signed list and cumulative value be updated. S6. Each intermediate signer registers before signing in a chain until the list of signed parties is sent to the aggregator. S7. The aggregator verifies the signed list and updates the signed list and the cumulative value; After the aggregator, as the last signer, completes the pre-signature registration, each signer generates its own partial signature, which is then verified by the verifier, as per [reference needed]. Figure 10 Specifically, it includes: S8. After completing the update, the aggregator broadcasts the accumulated value to each signer. S9. After receiving the cumulative value, each signer can generate a partial signature based on the cumulative value, the set of hash functions, identity information, the identifier of the signed list, the private key, and the message to be signed. S10. Each signer sends a portion of its signature to the aggregator. S11. The last signer, acting as the aggregator, completes the signature aggregation and obtains the collaborative signature; S12. The aggregator sends the collaborative signature to the verifier. S13. The verifier verifies the collaborative signature through norm constraints and equality aggregation, and accepts partial signatures from all signers after the verification is successful.

[0110] This application's embodiments utilize a chain-like unidirectional transmission mechanism to reduce communication complexity from... Down to This significantly reduces communication latency and optimizes energy consumption. A signature framework built on the NTRU lattice enables post-quantum security, ensuring long-term trustworthiness of system communication.

[0111] Figure 11 This is an architecture diagram of a chain-based collaborative signature system based on an NTRU lattice, provided in an embodiment of this application. (Refer to...) Figure 11 The system includes a key management module, a chain signature engine, an aggregate verification module, and a quantum-resistant module.

[0112] The key management module includes a system parameter generation interface, a trapdoor generation component, an identity hash mapping interface, and a key distribution interface. The private key generator generates system parameters by calling the system parameter generation interface, generates short base parameters, a public key, and a private key by calling the trapdoor generation component, predefines the hash function in the identity hash mapping interface, and distributes the public and private keys by calling the key distribution interface.

[0113] The chained signature engine includes a temporary vector sampling interface, an auxiliary commitment calculation interface, a predecessor verification component, and a one-way transmission interface. Signers can call the temporary vector sampling interface to sample the first and second temporary vectors. After pre-defining the commitment generation hash function in the auxiliary commitment calculation interface, the signer calls the auxiliary commitment calculation interface to generate the auxiliary value and the commitment value. Signers other than the first signer can call the predecessor verification component to verify the signed list and pass the signed list and accumulated value to the next signer through the one-way transmission interface.

[0114] The aggregation verification module includes a challenge generation component, a partial signature calculation interface, a signature aggregator, and a two-step verifier. A challenge generation hash function is predefined in the challenge generation component. The signer can call the challenge generation component to generate a challenge value and the partial signature calculation interface to generate a partial signature. The aggregator can call the signature aggregator to generate a collaborative signature, and the verifier can call the two-step verifier to perform signature verification.

[0115] The quantum-resistant security module includes an NTRU lattice configuration, a short basis generator, a Gaussian sampler, and a quantum-resistant hash interface. The NTRU lattice configuration predefines the relevant parameters and functions for the NTRU lattice. The private key generator calls the short basis generator to generate short basis parameters, calls the Gaussian sampler to perform Gaussian sampling calculations to obtain the private key, and defines a set of hash functions through the quantum-resistant hash interface.

[0116] Figure 12 This illustration shows a structural diagram of an electronic device provided in an embodiment of this application. The electronic device may be deployed with… Figure 11The electronic device of the system shown includes a processor 1201, a storage medium 1202, and a bus 1203. The storage medium 1202 stores machine-readable instructions executable by the processor 1201. When the electronic device runs a chain-based collaborative signature method based on an NTRU lattice as described in the embodiment, the processor 1201 communicates with the storage medium 1202 via the bus 1203. The processor 1201 executes the machine-readable instructions. The preamble of the method item of the processor 1201 executes the steps in the chain-based collaborative signature method based on the NTRU lattice described above.

[0117] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor, which performs the steps of the above-described chained collaborative signature method based on the NTRU lattice.

[0118] In this embodiment, the computer program, when run by the processor, can also execute other machine-readable instructions to perform other methods as described in the embodiments. For details on the specific execution steps and principles, please refer to the description of the embodiments, which will not be repeated here.

[0119] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus 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. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0120] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0121] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0122] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, 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 steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0123] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0124] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A chain-based collaborative signature method based on NTRU lattice, characterized in that, A chain-based collaborative signature system based on NTRU lattice is applied, the system comprising: a private key generator, multiple signers, and a verifier; the method comprising: The private key generator generates short base parameters, public keys, hash function sets, and private keys of each signer in an NTRU lattice according to predefined system parameters. It then sends the private keys of each signer to each signer and sends the public keys, the short base parameters, and the hash function sets to each signer and the verifier. Each signer corresponding to the message to be signed performs chain-like pre-signature registration based on the public key, the short base parameter and the set of hash functions to obtain the pre-signature registration result, which includes: a list of signed messages and a cumulative value. After all signers have completed the pre-signing registration, each signer generates a partial signature based on the accumulated value, the set of hash functions, the identity information of each signer, the identifier of the signed list, the private key of each signer, and the message to be signed, and sends the partial signature to the aggregator among the signers; The aggregator performs aggregator processing on each of the partial signatures to obtain a collaborative signature, which is then verified by the verifier based on the public key, the short base parameter, and the set of hash functions.

2. The method according to claim 1, characterized in that, The set of hash functions includes: identity binding hash function, commitment generation hash function, and challenge generation hash function; The process by which the private key generator generates the short base parameters of the NTRU lattice, the public key, the set of hash functions, and the private keys of each signer based on predefined system parameters includes: Based on the system parameters, the trapdoor generation algorithm is invoked to generate short basis parameters and a public key for the NTRU lattice; Based on the system parameters, define the identity binding hash function, the commitment generation hash function, and the challenge generation hash function; The private key of each signer is generated based on the identity binding hash function, the identity information of each signer, the system parameters, and the short base parameters.

3. The method according to claim 2, characterized in that, The step of generating the private key for each signer based on the identity binding hash function, the identity information of each signer, the system parameters, and the short base parameters includes: The identity information of the signer is hashed according to the identity binding hash function to obtain the identity hash value; Under preset constraints, Gaussian sampling calculations are performed on the system parameters, the short base parameters, and the identity hash value to obtain the private keys of each signer. The constraints are determined based on the identity hash value and the system parameters.

4. The method according to claim 1, characterized in that, Each of the aforementioned signers performs a chain-like pre-signature registration based on the public key, the short base parameter, and the set of hash functions to obtain a pre-signature registration result, including: Each signer, except the last signer, generates a commitment value and an auxiliary value based on the public key and the set of hash functions. The signer's identity information, the commitment value, and the auxiliary value are recorded in the signed list, the cumulative value is updated, and the signed list and the cumulative value are sent to the next signer according to the signer list corresponding to the message to be signed. The last signer generates a commitment value and an auxiliary value based on the public key and the set of hash functions, records the identity information of the last signer, the commitment value, and the auxiliary value in the signed list, updates the cumulative value, and broadcasts the cumulative value to each signer recorded in the signed list.

5. The method according to claim 4, characterized in that, Before updating the cumulative value, each signer other than the last signer generates a commitment value and an auxiliary value based on the public key and the set of hash functions, records the signer's identity information, the commitment value, and the auxiliary value in the signed list, and then proceeds as follows: If the signer is not the first signer, the signed list is verified. If the verification is successful, a commitment value and an auxiliary value are generated based on the public key and the set of hash functions. The signer's identity information, the commitment value, and the auxiliary value are recorded in the signed list, and the cumulative value is updated.

6. The method according to claim 4, characterized in that, The process by which the signer generates the commitment value and auxiliary value based on the public key and the set of hash functions includes: The first temporary vector and the second temporary vector are obtained by sampling from a preset Gaussian distribution; The auxiliary value is determined based on the first temporary vector, the second temporary vector, and the public key; The commitment value is generated by generating a hash function based on the auxiliary value and the commitments in the hash function set.

7. The method according to claim 1, characterized in that, Each signer generates a partial signature based on the accumulated value, the set of hash functions, the signer's identity information, the identifier of the signed list, the signer's private key, and the message to be signed, including: The cumulative value, the signer's identity information, the identifier of the signed list, and the message to be signed are used as input parameters, and the challenge value of the signer is generated by the challenge generation hash function in the hash function set. A partial signature of the signer is generated based on the signer's challenge value and the signer's private key.

8. The method according to claim 1, characterized in that, The aggregator performs aggregation processing on each of the partial signatures to obtain a collaborative signature, including: The individual signatures are aggregated to obtain a signature set; The collaborative signature is obtained by combining the signature set and the cumulative value.

9. The method according to claim 8, characterized in that, The process by which the verifier verifies the collaborative signature based on the public key, the short base parameter, and the set of hash functions includes: The collaborative signature is decomposed to obtain the signature set; The signature set is subjected to a norm constraint check. If the signature set does not meet the norm constraint, the signature set is rejected. If the signature set satisfies the norm constraint, then an equality aggregation check is performed on the signature set. If the signature set does not satisfy the equality constraint, then the signature set is rejected. If the signature set satisfies the equality constraint, then the signature set is accepted.

10. A chain-based collaborative signature system based on NTRU lattice, characterized in that, The system includes a private key generator, multiple signers, and a verifier. When the system is running, the private key generator, multiple signers, and verifier are respectively used to perform the steps performed by the private key generator, multiple signers, and verifier as described in any one of claims 1-9.

Images