Anti-quantum cooperative signature method and anti-quantum cooperative signature system
By introducing an access control mechanism into the quantum-resistant collaborative signature system, the system dynamically controls the clients with legitimate signing permissions, generates and verifies collaborative signatures, and solves the problem of signature system failure caused by client private key leakage or abuse. This ensures the quantum-resistant security of collaborative signatures and the dynamic and precise control of permissions.
Patent Information
- Application Number
- CN202511195499.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-26
- Publication Date
- 2025-12-30
- Estimated Expiration
- 2045-08-26
AI Technical Summary
In existing quantum-resistant collaborative signature systems, there is a security risk that the entire signature system will fail if the client's private key is leaked or misused. Especially in a quantum-resistant environment, the cost of changing the signature algorithm is high, the key lifespan is long, and the risk of losing control of permissions is high.
An access control mechanism is introduced, in which the server dynamically controls the clients with valid signature permissions, generates and verifies collaborative signatures, retains only a portion of the signature blocks from clients with controlled permissions, and discards a portion of the signature blocks from clients without controlled permissions. Dynamic and precise control is achieved through the interaction between the server and the verification client.
To prevent the signature system from failing due to the leakage or misuse of a single client's private key, ensure the quantum-resistant security of collaborative signatures, and achieve dynamic and precise control over client signature permissions.
Smart Images

Figure CN120710685B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network security technology, and more specifically, to a quantum-resistant collaborative signature method and a quantum-resistant collaborative signature system. Background Technology
[0002] In multi-party collaborative scenarios, collaborative signatures, as a digital signature mechanism involving multiple participants, typically involve each participant generating a partial signature, ultimately resulting in a complete and valid signature. Quantum-resistant collaborative signatures, designed to withstand quantum computing attacks, ensure the security of signature operations when facing quantum computing threats.
[0003] Currently, quantum-resistant collaborative signatures lack effective and dynamic control over the permissions of participating clients. If the signer's private key is leaked or misused, it directly threatens the security of the entire signature system. This is especially true in quantum-resistant environments, where the cost of changing signature algorithms is high, key lifecycles are long, and the risk of uncontrolled access is even more significant.
[0004] Therefore, existing quantum-resistant collaborative signatures pose a security risk of the entire signature system failing when the client's private key is leaked or misused. Summary of the Invention
[0005] The purpose of this application is to address the shortcomings of the prior art by providing a quantum-resistant collaborative signature method and system, thereby solving the practical problem of the security risk of the entire signature system failing when the client's private key is leaked or misused in the prior art.
[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows:
[0007] In a first aspect, embodiments of this application provide a quantum-resistant collaborative signature method, applied to the server side of a quantum-resistant collaborative signature system; the method includes:
[0008] Determine the list of authorized clients, and generate the server's secret key based on the list of authorized clients, the quantum resistance parameters sent by the clients, and the random number from the server.
[0009] Receive partial signature blocks sent by each client;
[0010] Based on the message to be signed, the server's secret key, public parameters, and quantum resistance parameters, the server's auxiliary parameters are determined, and a collaborative signature is generated based on the auxiliary parameters and partial signature blocks from each client.
[0011] The collaborative signature is sent to the verification client for verification of partial signature blocks of each client, and the collaborative signature is updated according to the verification results sent by the verification client.
[0012] As an optional implementation, generating the server's secret key based on the authorized client list, the quantum-resistant parameters sent by the clients, and the random number from the server includes:
[0013] Based on the list of authorized clients, the quantum resistance parameter, the first random number from the server, and the second random number from the server, determine the target parameters for each client in the list of authorized clients.
[0014] The product of the target parameters of each client in the list of authorized clients is used as the secret key of the server.
[0015] As an optional implementation, the step of determining the server's auxiliary parameters based on the message to be signed, the server's secret key, public parameters, and quantum resistance parameters, and generating a collaborative signature based on the auxiliary parameters and partial signature blocks from each client, includes:
[0016] The message to be signed is encoded into a first encoded random number, and the first auxiliary parameter of the server is determined based on the first encoded random number, the server's secret key, and the quantum resistance parameter.
[0017] The second auxiliary parameter of the server is determined based on the first encoded random number and the common parameter;
[0018] The partial signature blocks from each client, the first auxiliary parameter from the server, and the second auxiliary parameter from the server are arranged in random order and combined to form the collaborative signature.
[0019] As an optional implementation, updating the collaborative signature based on the verification result sent by the verification client includes:
[0020] Iterate through each result in the verification results. For the current result, if the partial signature block corresponding to the current result is invalid, delete the partial signature block corresponding to the current result from the collaborative signature.
[0021] Secondly, embodiments of this application provide a quantum-resistant collaborative signature method, applied to a client in a quantum-resistant collaborative signature system; the method includes:
[0022] Generate the client's private key and public key strings based on the public parameters sent by the server;
[0023] Based on the message to be signed and the client's private and public key strings, a partial signature block for the client is generated, and the partial signature result of the client is sent to the server.
[0024] Receive the collaborative signature sent by the server, and obtain the partial signature blocks of each client and the auxiliary parameters of the server based on the collaborative signature;
[0025] Based on the partial signature blocks of each client, the auxiliary parameters of the server, the list of authorized clients, the random number of the server, and the public key string of each client, the validity of the partial signature blocks of each client in the collaborative signature is verified in turn to obtain the verification result, and the verification result is sent to the server.
[0026] As an optional implementation, generating the client's private and public key strings based on the public parameters sent by the server includes:
[0027] Based on the public parameters and the client's random number, the client's private key and public key strings are generated.
[0028] As an optional implementation, generating the client's private key and public key strings based on the public parameters and the random numbers from each client includes:
[0029] A quantum homomorphic encryption algorithm is used to determine a quantum-resistant random number, which is the sum of the first random numbers from each client.
[0030] The client's private key is generated based on the public parameters, the client's second random number, and the quantum-resistant random number.
[0031] The client's public key string is generated based on the public parameters, the client's second random number, and the client's third random number.
[0032] As an optional implementation, generating a partial signature block for the client based on the message to be signed and the client's private and public key strings includes:
[0033] The message to be signed is encoded into a second encoded random number;
[0034] A partial signature block of the client is generated based on the second encoded random number, the client's private key, and the public key string.
[0035] As an optional implementation, the step of sequentially verifying the validity of each client's partial signature block in the collaborative signature based on each client's partial signature block, the server's auxiliary parameters, the list of authorized clients, the server's random number, and each client's public key string includes:
[0036] The auxiliary parameters of each client are determined based on the list of authorized clients, the public key string of each client, the random number from the server, and the first auxiliary parameter from the server.
[0037] The verification parameters are determined based on the list of authorized clients, the first random number from the server, and the public key string of each client.
[0038] Based on the partial signature blocks of each client, the second auxiliary parameter of the server, the auxiliary parameters of each client, the random number of the server, the verification parameters, and the public key string of each client, the validity of the partial signature blocks of each client in the collaborative signature is verified in sequence.
[0039] Thirdly, embodiments of this application provide a quantum-resistant collaborative signature device corresponding to the quantum-resistant collaborative signature method executed by the server, the quantum-resistant collaborative signature device comprising:
[0040] The first generation module is used to determine the list of authorized clients and generate the server's secret key based on the list of authorized clients, the quantum resistance parameters sent by the clients, and the random number from the server.
[0041] The first receiving module is used to receive partial signature blocks sent by each client;
[0042] The first generation module is further configured to determine the auxiliary parameters of the server based on the message to be signed, the server's secret key, public parameters, and the quantum resistance parameters, and generate a collaborative signature based on the auxiliary parameters and partial signature blocks of each client;
[0043] The update module is used to send the collaborative signature to the verification client for verification of partial signature blocks of each client, and update the collaborative signature according to the verification result sent by the verification client.
[0044] As an optional implementation, the first generation module is specifically used for:
[0045] Based on the list of authorized clients, the quantum resistance parameter, the first random number from the server, and the second random number from the server, determine the target parameters for each client in the list of authorized clients.
[0046] The product of the target parameters of each client in the list of authorized clients is used as the secret key of the server.
[0047] As an optional implementation, the first generation module is specifically used for:
[0048] The message to be signed is encoded into a first encoded random number, and the first auxiliary parameter of the server is determined based on the first encoded random number, the server's secret key, and the quantum resistance parameter.
[0049] The second auxiliary parameter of the server is determined based on the first encoded random number and the common parameter;
[0050] The partial signature blocks from each client, the first auxiliary parameter from the server, and the second auxiliary parameter from the server are arranged in random order and combined to form the collaborative signature.
[0051] As an optional implementation, the update module is specifically used for:
[0052] Iterate through each result in the verification results. For the current result, if the partial signature block corresponding to the current result is invalid, delete the partial signature block corresponding to the current result from the collaborative signature.
[0053] Fourthly, embodiments of this application provide a quantum-resistant collaborative signature device corresponding to the quantum-resistant collaborative signature method executed by the verification client, the quantum-resistant collaborative signature device comprising:
[0054] The second generation module is used to generate the client's private key and public key strings based on the public parameters sent by the server.
[0055] The second generation module is further configured to generate a partial signature block of the client based on the message to be signed and the client's private key and public key string, and send the partial signature result of the client to the server;
[0056] The second receiving module is used to receive the collaborative signature sent by the server, and obtain partial signature blocks of each client and auxiliary parameters of the server based on the collaborative signature;
[0057] The verification module is used to verify the validity of the partial signature blocks of each client in the collaborative signature according to the partial signature blocks of each client, the auxiliary parameters of the server, the list of authorized clients, the random number of the server, and the public key string of each client, to obtain the verification result, and send the verification result to the server.
[0058] As an optional implementation, the second generation module is specifically used for:
[0059] Based on the public parameters and the client's random number, the client's private key and public key strings are generated.
[0060] As an optional implementation, the second generation module is specifically used for:
[0061] A quantum homomorphic encryption algorithm is used to determine a quantum-resistant random number, which is the sum of the first random numbers from each client.
[0062] The client's private key is generated based on the public parameters, the client's second random number, and the quantum-resistant random number.
[0063] The client's public key string is generated based on the public parameters, the client's second random number, and the client's third random number.
[0064] As an optional implementation, the second generation module is specifically used for:
[0065] The message to be signed is encoded into a second encoded random number;
[0066] A partial signature block of the client is generated based on the second encoded random number, the client's private key, and the public key string.
[0067] As an optional implementation, the verification module is specifically used for:
[0068] The auxiliary parameters of each client are determined based on the list of authorized clients, the public key string of each client, the random number from the server, and the first auxiliary parameter from the server.
[0069] The verification parameters are determined based on the list of authorized clients, the first random number from the server, and the public key string of each client.
[0070] Based on the partial signature blocks of each client, the second auxiliary parameter of the server, the auxiliary parameters of each client, the random number of the server, the verification parameters, and the public key string of each client, the validity of the partial signature blocks of each client in the collaborative signature is verified in sequence.
[0071] Fifthly, embodiments of this application provide an electronic device, which is either the server or the verification client. The electronic device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the method steps as described in the first aspect or the verification client described in the second aspect above.
[0072] Sixthly, embodiments of this application provide a quantum-resistant collaborative signature system, the quantum-resistant collaborative signature system comprising: a server and multiple clients communicatively connected to the server;
[0073] The server is used to execute the steps of the method described in the first aspect above;
[0074] The verification client among the plurality of clients is used to perform the steps of the method described in the second aspect above.
[0075] The beneficial effects of this application are:
[0076] This application provides a quantum-resistant collaborative signature method and system. The client generates its private and public key strings based on public parameters sent by the server. The server receives quantum-resistant parameters from the client. The server determines a list of authorized clients and generates its secret key based on the list, the quantum-resistant parameters, and a random number from the server. The client generates a partial signature block based on the message to be signed and its private and public key strings. The server receives the partial signature blocks from each client, determines its auxiliary parameters based on the message to be signed, its secret key, public parameters, and quantum-resistant parameters, and generates a collaborative signature based on the auxiliary parameters and the partial signature blocks from each client. This collaborative signature is then sent to the verification client. The verification client extracts the partial signature blocks from each client and the server's auxiliary parameters from the collaborative signature. Based on the partial signature blocks from each client, the server's auxiliary parameters, the list of authorized clients, the server's random number, and the public key strings from each client, the verification client sequentially verifies the validity of each client's partial signature block in the collaborative signature, obtains the verification result, and sends the verification result back to the server. The server dynamically updates the collaborative signature based on the verification results, deleting invalid signature blocks and retaining only the valid signature blocks from clients in the permission-controlled list, ultimately resulting in the updated collaborative signature. Because the updated collaborative signature is a valid collaborative signature composed of all permission-controlled clients with legitimate signing permissions, it avoids the security risk of the entire signature system failing due to the leakage or misuse of a single client's private key. This achieves dynamic and precise control over client signing permissions and ensures the quantum-resistant security of the collaborative signature. Attached Figure Description
[0077] 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.
[0078] Figure 1 This is a schematic diagram of the architecture of the quantum-resistant collaborative signature system provided in the embodiments of this application;
[0079] Figure 2 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 1 ;
[0080] Figure 3 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 2 ;
[0081] Figure 4 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 3 ;
[0082] Figure 5 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 4 ;
[0083] Figure 6 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 5 ;
[0084] Figure 7 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 6 ;
[0085] Figure 8 A module structure diagram of a quantum-resistant collaborative signature device provided in this application embodiment;
[0086] Figure 9 A module structure diagram of another quantum-resistant collaborative signature device provided in this application embodiment;
[0087] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0088] 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. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.
[0089] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically 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 to illustrate selected embodiments of the 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.
[0090] 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.
[0091] Currently, in multi-party collaborative scenarios, quantum-resistant collaborative signatures lack effective and dynamic control over the permissions of participating clients. If the signer's private key is leaked or misused, it directly threatens the security of the entire signature system. Especially in a quantum-resistant environment, the cost of changing signature algorithms is high, key lifecycles are long, and the risk of uncontrolled permissions is high. In other words, existing quantum-resistant collaborative signature technologies pose a security risk of system failure if the client's private key is leaked or misused.
[0092] Based on the aforementioned problems, this application proposes a quantum-resistant collaborative signature method. In this system, the server dynamically controls clients with legitimate signing permissions. During the collaborative signature generation process, only signature blocks generated by clients with controlled permissions are ultimately deemed legitimate and participate in forming a valid collaborative signature; signature blocks generated by non-controlled clients are identified and eliminated during the verification phase. This avoids the security risk of the entire signature system failing due to the leakage or misuse of a single client's private key, achieves dynamic and precise control over client signing permissions, and ensures the quantum-resistant security of collaborative signatures.
[0093] Figure 1 This is a schematic diagram of the architecture of the quantum-resistant collaborative signature system provided in the embodiments of this application, as shown below. Figure 1 As shown, the quantum-resistant cooperative signature system includes a server and multiple clients that communicate with the server. Figure 1 For example, the server and There are several client communication connections. The server dynamically controls the participation of clients with legitimate signing permissions to form a valid collaborative signature based on a list of authorized clients. It also dynamically updates some signature blocks in the collaborative signature according to the verification structure sent by the verification client, in order to eliminate some signature blocks generated by non-authorized controlled clients.
[0094] Each client generates a partial signature block and sends it to the server to participate in the collaborative signing. The client's signature is then verified. The validity of partial signature blocks generated by each client is verified. Partial signature blocks generated by clients with controlled permissions from the authorized client list are deemed valid, while partial signature blocks generated by non-authorized clients are deemed invalid. The client verifies a portion of the signature block and sends the verification result to the server. The client being verified is... Any one of the clients.
[0095] Based on this, an access control mechanism is introduced into the collaborative signature process to avoid the security risk of the entire signature system failing due to the leakage or abuse of a single client's private key.
[0096] Figure 2 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 1 This paper uses the interaction between the server and the verification client in a quantum-resistant collaborative signature system as an example to illustrate the process of the quantum-resistant collaborative signature method. The verification client is... Any one of the clients. For example... Figure 2 As shown, the method includes:
[0097] S101, The server sends common parameters to each client.
[0098] Optionally, the server defines two large prime numbers. Multiplication group of order and Define a bilinear mapping Two hash functions are selected to map binary strings of arbitrary length to a group. and model Remaining class ring That is, the mapping is a range of 0 to Integers between [a certain value]. The server retrieves the remaining class ring. Random selection , , Three random numbers. Among them, Used for characterization The version number of each client.
[0099] The server depends on the number of clients. And server-side random numbers and ,calculate One public parameter, and will Each public parameter is sent to One client. Among them, The common parameters include: .in, , , , ..., .
[0100] It is worth noting that, It is a generator, and is a group. A special element, group All elements in can be represented as generators. The power form.
[0101] S102. The client generates its private key and public key strings based on the public parameters.
[0102] Optionally, Each client receives data sent by the server. Several common parameters, and generate The private and public key strings of each client. Any client among the clients Generate client The private and public key strings. Among them, the client... The private key includes and Client The public key string is .
[0103] Client Public key string One of the public keys, where, The public keys in the public key strings exposed by each client are different.
[0104] S103, The server receives the quantum resistance parameters sent by the client.
[0105] Optionally, the client Calculate the anti-quantum parameter and resist quantum parameters The client sends the data to the server, and the server receives it. The transmitted quantum resistance parameters.
[0106] Among them, the resistance to quantum parameters , for The unified quantum-resistant random number generated by the joint decryption by multiple clients Used to implement Quantum attack resistance for each client, ensuring Quantum-resistant security for individual clients.
[0107] S104. The server determines the list of authorized clients and generates the server's secret key based on the list of authorized clients, the quantum resistance parameters sent by the clients, and the random number from the server.
[0108] Optionally, the server determines the list of authorized clients based on the client permission control information pre-entered by the user. For example, if the client permission control information indicates... If the clients with controlled permissions are Client 1, Client 3, Client 4, and Client 5, then the server determines the list of clients with controlled permissions. .
[0109] The server uses a list of authorized clients. Anti-quantum parameter In addition to the server-side random number, a secret key for the server is generated. .
[0110] S105. The client generates a partial signature block based on the message to be signed and the client's private and public key strings.
[0111] Optionally, Each client, based on the message to be signed, Generate with the client's private and public key strings A partial signature block for each client.
[0112] for Any client among the clients Client According to the message to be signed Client private key and and client public key string Generate client Partial signature block .
[0113] S106. The server receives partial signature blocks sent by each client.
[0114] Optionally, for Any client among the clients Client Client Partial signature block Send to the server. In other words, the server receives... Send by a client Each part of the signature block includes , … .
[0115] S107. The server determines the auxiliary parameters based on the message to be signed, the server's secret key, public parameters, and quantum resistance parameters, and generates a collaborative signature based on the auxiliary parameters and partial signature blocks from each client.
[0116] Optionally, the server determines the signature based on the message to be signed. Server-side secret key Common parameters, quantum resistance parameters Determine the auxiliary parameters on the server side. Including the first auxiliary parameter on the server side Second auxiliary parameter .
[0117] server combination One client Each partial signature block, along with the server's first auxiliary parameter Second auxiliary parameter Generate collaborative signature In other words, collaborative signatures. .
[0118] S108. Verify that the client receives the collaborative signature sent by the server.
[0119] Optionally, the server will generate a collaborative signature. Send to Any one of the clients at this time receives the collaborative signature. The client acts as the verification client.
[0120] For example, the server will generate a collaborative signature. Send to client Client As a verification client, it receives collaborative signatures from the server. .
[0121] S109. The verification client obtains partial signature blocks from each client and auxiliary parameters from the server based on the collaborative signature.
[0122] Optionally, the verification client obtains the collaborative signature. The process involves obtaining partial signature blocks from each client, i.e., verifying that the client obtained the signature from the collaborative signature. Extract One client Each part of the signature block includes , … and from collaborative signatures Extract the server-side auxiliary parameters, including the server-side first auxiliary parameter. Second auxiliary parameter .
[0123] S110. The verification client verifies the validity of the partial signature blocks of each client in the collaborative signature process based on the partial signature blocks of each client, the auxiliary parameters of the server, the list of authorized clients, the random number of the server, and the public key string of each client, and obtains the verification result.
[0124] Optionally, the verification client is based on One client Each partial signature block (i.e.) , … Auxiliary parameters of the server List of Permitted Clients Random numbers on the server side and One client The public keys published in the public key strings are used to verify the validity of the partial signature blocks of each client in the collaborative signature process.
[0125] Specifically, the verification client will verify the list of authorized clients. The partial signature blocks generated by clients with controlled permissions are identified as valid partial signature blocks, while the partial signature blocks generated by non-controlled clients are identified as invalid partial signature blocks. The verification result of a partial signature block of a client.
[0126] For example, assuming there are a total of 6 clients, the list of authorized clients is as follows: That is, the clients with controlled permissions are Client 1, Client 3, Client 4, and Client 5, while the clients without controlled permissions are Client 2 and Client 6. Then the verification client will use a portion of the signature block from Client 1. Partial signature block of client 3 Client 4 partial signature block and part of the signature block of client 5 The partial signature block identified as valid is used to process the partial signature block from client 2. and part of the signature block of client 6 The part of the signature block that is determined to be invalid is used to obtain the verification result.
[0127] S111. The client verifies the verification result and sends it to the server.
[0128] Optionally, the verification client sends the verification result to the server so that the server can dynamically update the collaborative signature based on the verification result from the verification client.
[0129] The verification results are used to indicate One client Whether the partial signature block is valid.
[0130] S112. The server updates the collaborative signature based on the verification result.
[0131] Optionally, the server dynamically updates the collaborative signature based on the verification result from the verification client. Specifically, the server updates the signature based on the verification result. One client The system checks the validity of each partial signature block to dynamically delete invalid partial signature blocks in the collaborative signature, retaining only the valid partial signature blocks of clients with controlled permissions, and finally obtaining the updated collaborative signature.
[0132] The updated collaborative signature is a valid collaborative signature composed of clients with legal signature permissions and controlled permissions. In various scenarios that require multi-party collaboration and have strict requirements on signature permissions, such as identity authentication and data interaction of IoT devices, transaction signature verification in blockchain, and document approval signature in e-government systems, the client's signature permissions are precisely controlled, and quantum-resistant security is ensured in the collaborative signature process.
[0133] In this embodiment, the client generates its private and public key strings based on the public parameters sent by the server, and the server receives the quantum-resistant parameters sent by the client. The server determines a list of authorized clients and generates its secret key based on the list of authorized clients, the quantum-resistant parameters, and a random number from the server. The client generates a partial signature block based on the message to be signed and its private and public key strings. The server receives the partial signature blocks from each client, determines its auxiliary parameters based on the message to be signed, the server's secret key, the public parameters, and the quantum-resistant parameters, and generates a collaborative signature based on the auxiliary parameters and the partial signature blocks from each client, sending the collaborative signature to the verification client. The verification client extracts the partial signature blocks from each client and the server's auxiliary parameters from the collaborative signature, and sequentially verifies the validity of the partial signature blocks from each client in the collaborative signature based on the partial signature blocks from each client, the server's auxiliary parameters, the list of authorized clients, the server's random number, and the public key strings from each client, obtaining the verification result, and sends the verification result to the server. The server dynamically updates the collaborative signature based on the verification results, deleting invalid signature blocks and retaining only the valid signature blocks from clients in the permission-controlled list, ultimately resulting in the updated collaborative signature. Because the updated collaborative signature is a valid collaborative signature composed of all permission-controlled clients with legitimate signing permissions, it avoids the security risk of the entire signature system failing due to the leakage or misuse of a single client's private key. This achieves dynamic and precise control over client signing permissions and ensures the quantum-resistant security of the collaborative signature.
[0134] Figure 3 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 2 ,like Figure 3 As shown, in step S104 above, the server's secret key is generated based on the list of authorized clients, the quantum resistance parameters sent by the clients, and the random number from the server. This includes:
[0135] S201. Based on the list of authorized clients, the quantum resistance parameter, the first random number from the server, and the second random number from the server, determine the target parameters for each client in the list of authorized clients.
[0136] Optionally, the server can configure the client list based on permissions. Anti-quantum parameter The first random number on the server side The second random number on the server side Determine the list of authorized clients. The target parameters for each permission-controlled client in the middle are: Among them, the client Indicates the list of authorized clients. Any client with controlled permissions.
[0137] S202. Use the product of the target parameters of each client in the list of authorized clients as the secret key for the server.
[0138] Optionally, the server can configure a list of authorized clients. Target parameters of each permission-controlled client Perform a product operation and determine the server's secret key based on the following formula. :
[0139]
[0140] in, This is the server's secret key. For the list of authorized clients, To resist quantum parameters, and These are the first random number generated by the server and the second random number generated by the server, respectively. Total number of clients, number of clients Indicates the list of authorized clients. Any client with controlled permissions.
[0141] It is worth noting that when a user triggers the permission update mechanism, the client's permissions change, and the list of clients with permissions is updated. Change to the updated client permission list At this time, the server's secret key Update based on the following formula, updated as follows: :
[0142]
[0143] in, This is the updated secret key for the server. This is the updated list of clients with permissions. To resist quantum parameters, and These are the first random number generated by the server and the second random number generated by the server, respectively. Total number of clients, number of clients Indicates the list of authorized clients. Any client with controlled permissions.
[0144] Based on the list of clients with controlled permissions Update server secret key This ensures that the system can dynamically adapt to changes in client permissions when generating the final collaborative signature, thereby continuously maintaining controllable security.
[0145] In this embodiment, the server determines the target parameters of each controlled client in the authorized client list based on the authorized client list, the quantum resistance parameter, and the server's first and second random numbers. The server uses the product of the target parameters of each controlled client in the authorized client list as its secret key. When a user triggers a permission update mechanism that changes the authorized client list, the server synchronously updates its secret key based on the updated authorized client list to dynamically adapt to changes in client permissions and continuously maintain controllable security.
[0146] Figure 4 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 3 ,like Figure 4 As shown, in step S107 above, the auxiliary parameters of the server are determined based on the message to be signed, the server's secret key, public parameters, and quantum resistance parameters. A collaborative signature is then generated based on the auxiliary parameters and partial signature blocks from each client, including:
[0147] S301. Encode the message to be signed into a first encoded random number, and determine the first auxiliary parameter of the server based on the first encoded random number, the server's secret key, and the quantum resistance parameter.
[0148] Optionally, the server will send the message to be signed. Encoding as a residual class ring The random number in the message to be signed is specifically generated by the server. Encode as the first code random number ,and .
[0149] The server generates a random number based on the first encoding. Server-side secret key and resistance to quantum parameters The first auxiliary parameter of the server is determined based on the following formula. :
[0150]
[0151] in, As the first auxiliary parameter of the server, This is the server's secret key. To resist quantum parameters, This is the first encoded random number.
[0152] It is worth noting that when a user triggers the permission update mechanism, the client's permissions change, and the list of clients with permissions is updated. Change to the updated client permission list The server's secret key Change to the updated secret key on the server side At that time, the first auxiliary parameter of the server is based on the following formula. Updated to the first auxiliary parameter after the server update :
[0153]
[0154] in, This is the first auxiliary parameter after the server update. This is the updated secret key for the server. To resist quantum parameters, This is the first encoded random number.
[0155] S302. Determine the second auxiliary parameter of the server based on the first encoded random number and the common parameters.
[0156] Optionally, the server uses a first encoded random number. and in the public parameters The second auxiliary parameter of the server is determined based on the following formula. :
[0157]
[0158] in, This is the second auxiliary parameter for the server. For common parameters, This is the first encoded random number.
[0159] S303. Arrange the partial signature blocks of each client, the first auxiliary parameter of the server, and the second auxiliary parameter of the server in random order and combine them into a collaborative signature.
[0160] Optionally, the server will One client Each partial signature block, the first auxiliary parameter of the server. Second auxiliary parameter Randomized arrangement, confusion The order of the partial signature blocks and the two auxiliary parameters on the server side are combined to obtain the collaborative signature. .
[0161] It is worth noting that, for ease of description, the above collaborative signature will be referred to as... middle The partial signature blocks and two auxiliary parameters from the server are arranged in sequence, which are actually used in generating the collaborative signature. During the process, Each part of the signature block , … and the first auxiliary parameter on the server side Second auxiliary parameter The order between them is random.
[0162] In this embodiment, the server encodes the message to be signed into a first encoded random number, and determines its first auxiliary parameter based on the first encoded random number, the server's secret key, and quantum-resistant parameters. The server's first auxiliary parameter is dynamically updated along with its secret key. The server determines its second auxiliary parameter based on the first encoded random number and common parameters. The partial signature blocks from each client, the server's first auxiliary parameter, and the server's second auxiliary parameter are then rearranged in random order and combined to form a collaborative signature. Finally, the server reassembles the partial signature blocks and the two auxiliary parameters in random order to form the collaborative signature.
[0163] As an optional implementation, updating the collaborative signature based on the verification result in step S112 above includes:
[0164] Iterate through each result in the verification results. For the current result, if the partial signature block corresponding to the current result is invalid, delete the partial signature block corresponding to the current result from the collaborative signature.
[0165] Optionally, the verification results include... One client The results of each partial signature block, for example, the first result indicates whether the partial signature block of client 1 is valid, and correspondingly, the second result... The result is used to instruct the client Is the partial signature block valid?
[0166] The server iterates through each result in the verification results. Taking the second result as an example, if the signature block corresponding to the current result is invalid, it indicates to the client... If the client is not a privileged client, then the server will... Delete the portion of the signature block corresponding to the second result, i.e. Delete client Partial signature block And continue iterating through the third result until the third result has been iterated through. The collaborative signature obtained after the result is the final collaborative signature. At this point, the final collaborative signature only retains the valid partial signature blocks of each authorized client in the list of authorized clients.
[0167] In this embodiment, the server iterates through each result in the verification results. For the current result, if the corresponding partial signature block is invalid, the partial signature block is deleted from the collaborative signature, and the server continues to iterate through the next result until all results in the verification results have been iterated through. The collaborative signature obtained after iterating through the last result is taken as the final collaborative signature. This ensures that the final collaborative signature only retains the valid partial signature blocks of each client with controlled permissions in the list of authorized clients. This prevents the security risk of the entire signature system failing due to the leakage or misuse of a single client's private key, and achieves dynamic and precise control over client signature permissions.
[0168] As an optional implementation, step S102 above, which generates the client's private key and public key string based on public parameters, includes:
[0169] Generate the client's private and public key strings based on the public parameters and the client's random number.
[0170] Optionally, for Any client among the clients Client From the remaining class ring Random selection , , Three random numbers.
[0171] Client according to These One common parameter and , , These three random numbers are used to generate the client. private key , and public key string .
[0172] In this embodiment, the client generates its private and public key strings based on public parameters and its own random number. By introducing a random number, the uniqueness and unpredictability of each client's key are ensured.
[0173] Figure 5 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 4 ,like Figure 5 As shown, the steps above, based on the public parameters and the client's random number, generate the client's private and public key strings, including:
[0174] S401. A quantum homomorphic encryption algorithm is used to determine a quantum-resistant random number, which is the sum of the first random numbers of each client.
[0175] Optionally, the Quantum Homomorphic Encryption (QHE) algorithm is used to transmit the first random number to each client. ciphertext Addition form The ciphertext is decrypted locally on each client, yielding the sum of the plaintext, denoted as . .
[0176] in, For quantum random numbers, quantum random numbers The sum of the first random numbers from each client, quantum-resistant random numbers. for A unified random number for each client is used to resist quantum attacks.
[0177] S402. Generate the client's private key based on the public parameters, the client's second random number, and the quantum-resistant random number.
[0178] Optionally, for Any client among the clients Client According to the public parameters Client The second random number and resistance to quantum random numbers The client is generated based on the following formula. private key and :
[0179]
[0180]
[0181] in, and For the client private key, For common parameters, For the client The second random number, To resist quantum random numbers, It is a generator, and is a group. A special element.
[0182] S403. Generate the client's public key string based on the public parameters, the client's second random number, and the client's third random number.
[0183] Optionally, for Any client among the clients Client According to the public parameters Client The second random number and client The third random number Generate client public key string .
[0184] in, The public key in the public key string published by each client is... ,in, .
[0185] In this embodiment, a quantum homomorphic encryption algorithm is used to calculate the sum of the first random numbers of each client to obtain a quantum-resistant random number. Each client generates its private key based on the public parameters, its second random number, and the quantum-resistant random number, and generates its public key string based on the public parameters, its second random number, and its third random number. This ensures the uniqueness and unpredictability of each client's key and achieves resistance to quantum attacks.
[0186] Figure 6 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 5 ,like Figure 6 As shown, in step S105 above, a partial signature block for the client is generated based on the message to be signed and the client's private and public key strings, including:
[0187] S501. Encode the message to be signed into a second-encoded random number.
[0188] Optionally, for Any client among the clients Client message awaiting signature Encoding as a residual class ring The random number in the message to be signed is specifically generated by the server. Encode as a second-code random number ,and .
[0189] in, The second encoded random numbers obtained by each client are different. For example, the second encoded random number of client 1 is... Client The second encoded random number is This will not be elaborated upon here.
[0190] S502. Generate a partial signature block for the client based on the second encoded random number, the client's private key, and the public key string.
[0191] Optionally, the client Based on the second encoded random number Client private key , and public key string Generate client Partial signature block Specifically, the client Partial signature block ,in, For the client public key string The public key that is publicly available in the database.
[0192] Among them, the client Partial signature block It is represented in the form of an array. Indicates the client Partial signature block The first value , Indicates the client Partial signature block The second value , Indicates the client Partial signature block The third value .
[0193] In this embodiment, the client encodes the message to be signed into a second encoded random number, and generates a partial signature block based on the second encoded random number, quantum-resistant parameters, the client's private key, and public key string. Quantum-resistant security is ensured during the generation of the partial signature block.
[0194] Figure 7 A flowchart illustrating the quantum-resistant collaborative signature method provided in this application embodiment. Figure 6 ,like Figure 7 As shown, in step S110 above, based on the partial signature blocks of each client, the auxiliary parameters of the server, the list of authorized clients, the random number of the server, and the public key string of each client, the validity of the partial signature blocks of each client in the collaborative signature is verified in turn to obtain the verification results, including:
[0195] S601. Determine the auxiliary parameters for each client based on the list of authorized clients, the public key string of each client, the random number from the server, and the first auxiliary parameter from the server.
[0196] Optionally, the client is verified based on a list of authorized clients. The public key published in each client's public key string, and the server's first random number. The first auxiliary parameter of the server The client is determined based on the following formula. Auxiliary parameters :
[0197]
[0198] in, For the client Auxiliary parameters, As the first auxiliary parameter of the server, The first random number generated by the server. For the list of authorized clients, For the client Public key, client Indicates the list of authorized clients. Any client with controlled permissions.
[0199] S602. Determine the verification parameters based on the list of authorized clients, the first random number from the server, and the public key string of each client.
[0200] Optionally, the client is verified based on a list of authorized clients. The first random number on the server side The verification parameters are determined based on the following formula, along with the public key strings of each client. :
[0201]
[0202] in, To verify the parameters, The first random number on the server, the client Indicates the list of authorized clients. Any client with controlled permissions.
[0203] Verification parameters By aggregating the public key information of all authorized clients, a public verification base is formed.
[0204] S603. Based on the partial signature blocks of each client, the second auxiliary parameter of the server, the auxiliary parameters of each client, the random number of the server, the verification parameters, and the public key string of each client, verify in turn whether the partial signature blocks of each client in the collaborative signature are valid.
[0205] Optionally, the verification client verifies the partial signature blocks of each client. The second auxiliary parameter of the server Auxiliary parameters for each client The first random number on the server side The third random number on the server side Verification parameters In addition to the public key in each client's public key string, the validity of each client's partial signature block in the collaborative signature is verified sequentially based on the following formula:
[0206]
[0207] in, To verify the parameters, For the client Partial signature block The first value , For the client Partial signature block The second value , For the client Partial signature block The third value , This is the second auxiliary parameter for the server. For the client Auxiliary parameters, The first random number on the server side, This is the third random number generated by the server. For the client The public key is publicly available.
[0208] Specifically, for the client If both sides of the above equation are equal, that is, the equation is true, then it means the client... For a client with controlled permissions, the client Partial signature block Valid. Correspondingly, if the left and right sides of the above equation are not equal, i.e., the equation is false, it indicates that the client... For non-authorization-controlled clients, the client Partial signature block Invalid; the server needs to remove the client from the collaborative signature later. Partial signature block .
[0209] In this embodiment, the verification client determines the auxiliary parameters for each client based on the list of authorized clients, the public key strings of each client, the server's random number, and the server's first auxiliary parameter. It then determines the verification parameters based on the list of authorized clients, the server's first random number, and the public key strings of each client. For each client, the verification client sequentially verifies the validity of each client's partial signature blocks in the collaborative signature based on the client's partial signature blocks, the server's second auxiliary parameter, the client's auxiliary parameters, the server's random number, the verification parameters, and the client's public key strings. This verification of the validity of each client's partial signature blocks allows the server to remove invalid partial signature blocks, ensuring the validity of each partial signature block in the final generated collaborative signature.
[0210] Based on the same inventive concept, this application also provides an anti-quantum collaborative signature device corresponding to the anti-quantum collaborative signature method executed by the server. Since the principle of the device in this application is similar to the anti-quantum collaborative signature method executed by the server in the above-mentioned application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0211] Figure 8 A module structure diagram of a quantum-resistant collaborative signature device provided in this application embodiment is shown below. Figure 8 As shown, the device includes:
[0212] The first generation module 801 is used to determine the list of authorized clients and generate the server's secret key based on the list of authorized clients, the quantum resistance parameters sent by the clients, and the random number from the server.
[0213] The first receiving module 802 is used to receive partial signature blocks sent by each client.
[0214] The first generation module 801 is also used to determine the auxiliary parameters of the server based on the message to be signed, the server's secret key, public parameters and quantum resistance parameters, and generate a collaborative signature based on the auxiliary parameters and partial signature blocks of each client.
[0215] The update module 803 is used to send the collaborative signature to the verification client for verification of partial signature blocks of each client, and update the collaborative signature according to the verification results sent by the verification client.
[0216] As an optional implementation, the first generation module 801 is specifically used for:
[0217] Based on the list of authorized clients, the quantum resistance parameter, the first random number from the server, and the second random number from the server, determine the target parameters for each client in the list of authorized clients.
[0218] The product of the target parameters of each client in the list of authorized clients is used as the secret key for the server.
[0219] As an optional implementation, the first generation module 801 is specifically used for:
[0220] The message to be signed is encoded into a first encoded random number, and the first auxiliary parameter of the server is determined based on the first encoded random number, the server's secret key, and the quantum resistance parameter.
[0221] The second auxiliary parameter of the server is determined based on the first encoded random number and the common parameters.
[0222] The partial signature blocks from each client, the first auxiliary parameter from the server, and the second auxiliary parameter from the server are arranged in random order and combined to form a collaborative signature.
[0223] As an optional implementation, update module 803 is specifically used for:
[0224] Iterate through each result in the verification results. For the current result, if the partial signature block corresponding to the current result is invalid, delete the partial signature block corresponding to the current result from the collaborative signature.
[0225] Based on the same inventive concept, this application also provides an anti-quantum collaborative signature device corresponding to the anti-quantum collaborative signature method executed by the verification client. Since the principle of the device in this application is similar to the anti-quantum collaborative signature method executed by the verification client in the above-mentioned application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0226] Figure 9 A module structure diagram of another quantum-resistant collaborative signature device provided in the embodiments of this application is shown below. Figure 9 As shown, the device includes:
[0227] The second generation module 901 is used to generate the client's private key and public key strings based on the public parameters sent by the server.
[0228] The second generation module 901 is also used to generate a partial signature block for the client based on the message to be signed and the client's private key and public key string, and send the partial signature result of the client to the server.
[0229] The second receiving module 902 is used to receive the collaborative signature sent by the server, and obtain the partial signature blocks of each client and the auxiliary parameters of the server based on the collaborative signature.
[0230] The verification module 903 is used to verify the validity of the partial signature blocks of each client in the collaborative signature based on the partial signature blocks of each client, the auxiliary parameters of the server, the list of authorized clients, the random number of the server, and the public key string of each client, to obtain the verification result, and then send the verification result to the server.
[0231] As an optional implementation, the second generation module 901 is specifically used for:
[0232] Generate the client's private and public key strings based on the public parameters and the client's random number.
[0233] As an optional implementation, the second generation module 901 is specifically used for:
[0234] A quantum homomorphic encryption algorithm is used to determine a quantum-resistant random number, which is the sum of the first random numbers from each client.
[0235] Generate the client's private key based on the public parameters, the client's second random number, and the quantum-resistant random number.
[0236] Generate the client's public key string based on the public parameters, the client's second random number, and the client's third random number.
[0237] As an optional implementation, the second generation module 901 is specifically used for:
[0238] The message to be signed is encoded into a second-encoded random number.
[0239] A partial signature block for the client is generated based on the second encoded random number, the client's private key, and the public key string.
[0240] As an optional implementation, verification module 903 is specifically used for:
[0241] The auxiliary parameters for each client are determined based on the list of authorized clients, the public key string of each client, the random number from the server, and the first auxiliary parameter from the server.
[0242] The verification parameters are determined based on the list of authorized clients, the first random number generated by the server, and the public key string of each client.
[0243] Based on the partial signature blocks of each client, the second auxiliary parameter of the server, the auxiliary parameters of each client, the random number of the server, the verification parameters, and the public key string of each client, the validity of the partial signature blocks of each client in the collaborative signature is verified in turn.
[0244] This application also provides an electronic device, which can be the aforementioned server or authentication client. For example... Figure 10 The diagram shown is a schematic representation of the structure of an electronic device provided in an embodiment of this application, including: a processor 101, a memory 102, and a bus 103. The memory 102 stores machine-readable instructions executable by the processor 101 (e.g., ...). Figure 8 The execution instructions corresponding to the first generation module 801, the first receiving module 802, and the update module 803 in the device, or, Figure 9 (The execution instructions corresponding to the second generation module 901, the second receiving module 902, and the verification module 903 in the device). When the electronic device 100 is running, the processor 101 and the memory 102 communicate through the bus 103. When the machine-readable instructions are executed by the processor 101, the method steps executed by the above-mentioned server or verification client are executed.
[0245] This application also provides a quantum-resistant collaborative signature system, such as... Figure 1 As shown, the quantum-resistant collaborative signature system includes a server and multiple clients that communicate with the server.
[0246] The server and the verification client among the multiple clients are used to execute the steps described in the foregoing embodiments.
[0247] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.
[0248] Furthermore, the functional units in the various embodiments of 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. If the 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 part 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: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.
[0249] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.
Claims
1. A method of quantum-cooperation-resistant signature, characterized in that, The application is applied to a server in an anti-quantum cooperative signature system, and the method comprises the following steps: determining a permission client list, and generating a secret key of the server according to the permission client list, an anti-quantum parameter sent by a client and a random number of the server; wherein the anti-quantum parameter is a unified anti-quantum random number generated by joint decryption of multiple clients, and the anti-quantum parameter is used for anti-quantum attack of the multiple clients; receiving partial signature blocks sent by each client; wherein the partial signature blocks are generated by the client according to a message to be signed and a private key and a public key string of the client; determining an auxiliary parameter of the server according to the message to be signed, the secret key of the server, a public parameter and the anti-quantum parameter, and generating a cooperative signature according to the auxiliary parameter and the partial signature blocks of each client; sending the cooperative signature to a verification client for verification of the partial signature blocks of each client, and updating the cooperative signature according to a verification result sent by the verification client; wherein when the verification client verifies the partial signature blocks of each client, the verification client verifies whether the partial signature blocks of each client in the cooperative signature are valid according to the partial signature blocks of each client, the auxiliary parameter of the server, the permission client list, the random number of the server and the public key string of each client, and obtains the verification result.
2. The method of claim 1, wherein, The step of generating the secret key of the server according to the permission client list, the anti-quantum parameter sent by the client and the random number of the server comprises the following steps: determining a target parameter of each client in the permission client list according to the permission client list, the anti-quantum parameter, a first random number of the server and a second random number of the server; taking a product of the target parameters of each client in the permission client list as the secret key of the server.
3. The method of claim 1, wherein, The step of determining the auxiliary parameter of the server according to the message to be signed, the secret key of the server, the public parameter and the anti-quantum parameter, and generating the cooperative signature according to the auxiliary parameter and the partial signature blocks of each client comprises the following steps: encoding the message to be signed into a first encoded random number, and determining a first auxiliary parameter of the server according to the first encoded random number, the secret key of the server and the anti-quantum parameter; determining a second auxiliary parameter of the server according to the first encoded random number and the public parameter; randomly arranging the partial signature blocks of each client, the first auxiliary parameter of the server and the second auxiliary parameter of the server, and combining them into the cooperative signature.
4. The method of claim 1, wherein, The step of updating the cooperative signature according to the verification result sent by the verification client comprises the following steps: traversing each result in the verification result, and if a partial signature block corresponding to a current result in the traversal is invalid, deleting the partial signature block corresponding to the current result from the cooperative signature.
5. A method of quantum-cooperation-resistant signature, characterized in that, The application is applied to a client in an anti-quantum cooperative signature system, and the method comprises the following steps: generating a private key and a public key string of the client according to a public parameter sent by a server; According to the to-be-signed message and the private key and the public key string of the client, a partial signature block of the client is generated, and a partial signature result of the client is sent to the server; Receiving the collaborative signature sent by the server, and according to the collaborative signature, obtaining the partial signature block of each client and the auxiliary parameter of the server; the collaborative signature is generated by the server according to the to-be-signed message, the secret key of the server, the public parameter, the anti-quantum parameter and the partial signature block of each client, wherein the anti-quantum parameter is a unified anti-quantum random number generated by joint decryption of multiple clients, and the anti-quantum parameter is used for anti-quantum attack of multiple clients; According to the partial signature block of each client, the auxiliary parameter of the server, the list of authorized clients, the random number of the server and the public key string of each client, whether the partial signature block of each client in the collaborative signature is valid is verified in sequence to obtain a verification result, and the verification result is sent to the server.
6. The method of claim 5, wherein, The private key and the public key string of the client are generated according to the public parameter sent by the server, comprising: According to the public parameter and the random number of the client, the private key and the public key string of the client are generated.
7. The method of claim 6, wherein, The private key and the public key string of the client are generated according to the public parameter and the random number of each client, comprising: The anti-quantum random number is determined by using a quantum homomorphic encryption algorithm, and the anti-quantum random number is the sum of the first random numbers of each client; According to the public parameter, the second random number of the client and the anti-quantum random number, the private key of the client is generated; According to the public parameter, the second random number of the client and the third random number of the client, the public key string of the client is generated.
8. The method of claim 5, wherein, The partial signature block of the client is generated according to the to-be-signed message and the private key and the public key string of the client, comprising: The to-be-signed message is encoded into a second encoded random number; According to the second encoded random number, the private key and the public key string of the client, the partial signature block of the client is generated.
9. The method of claim 5, wherein, According to the partial signature block of each client, the auxiliary parameter of the server, the list of authorized clients, the random number of the server and the public key string of each client, whether the partial signature block of each client in the collaborative signature is valid is verified in sequence, comprising: According to the list of authorized clients, the public key string of each client, the random number of the server and the first auxiliary parameter of the server, the auxiliary parameter of each client is determined; According to the list of authorized clients, the first random number of the server and the public key string of each client, a verification parameter is determined; According to the partial signature block of each client, the second auxiliary parameter of the server, the auxiliary parameter of each client, the random number of the server, the verification parameter and the public key string of each client, whether the partial signature block of each client in the collaborative signature is valid is verified in sequence.
10. An anti-quantum-collusion signature system, comprising: The anti-quantum collaborative signature system comprises a server and a plurality of clients in communication connection with the server; The server is used to execute the method steps of any one of claims 1-4; According to the to-be-signed message and the private key and the public key string of the client, a partial signature block of the client is generated, and a partial signature result of the client is sent to the server; A verification client of the plurality of clients is configured to perform the method steps of any of claims 5-9.
Citation Information
Patent Citations
Collaborative signature method, collaborative signature verification method, collaborative signature verification system and client
CN118869219A
Collaborative key generation method and device based on hash algorithm, collaborative signature method and device based on hash algorithm, and electronic equipment
CN118921169A