Lattice-based TLS unbalanced key exchange protocol and device, readable storage medium and product
By using a lattice-based unbalanced key exchange protocol, the problem of excessive computational burden on low-computing-power devices in the TLS protocol is solved, realizing an efficient, secure, and easy-to-deploy communication solution suitable for secure communication between IoT devices and high-computing-power servers.
Patent Information
- Application Number
- CN202511314748.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-15
- Publication Date
- 2025-12-12
AI Technical Summary
In existing TLS protocols, low-computing-power devices bear an excessive computational burden during key exchange, leading to increased communication latency and power consumption. At the same time, traditional algorithms face the risk of quantum attacks and lack optimization mechanisms adapted to low-computing-power devices and compatibility with TLS protocols.
It adopts a lattice-based unbalanced key exchange protocol, and by introducing an unbalanced computation allocation mechanism, it transfers time-consuming operations in the key exchange process, adapts to low-computing-power devices to perform a small number of polynomial calculations and hash operations, and combines the TLS 1.3 handshake process to achieve efficient and secure communication.
It reduces the computational burden on low-performance devices, provides quantum-resistant security, is easy to deploy, and integrates seamlessly with existing TLS protocols, making it suitable for IoT scenarios.
Smart Images
Figure CN121125246A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication protocol technology, and in particular to a lattice-based TLS unbalanced key exchange protocol, apparatus, readable storage medium, and product. Background Technology
[0002] With the rapid development of Internet of Things (IoT) technology, a large number of low-power, low-computing-power smart devices have been deployed globally. These devices are widely used in environmental monitoring, smart cities, edge computing, and other scenarios. However, these resource-constrained devices face significant challenges with existing secure communication protocols such as TLS. Current mainstream TLS protocol key exchange mechanisms generally employ traditional algorithms such as Elliptic Curve Diffie-Hellman (ECDHE). While these algorithms offer good security, their execution relies on large-scale numerical and exponential calculations, leading to a significant increase in communication latency and power consumption, thus reducing the device's battery life and real-time response capabilities.
[0003] On the other hand, with the rapid breakthroughs in quantum computing technology, traditional public-key encryption systems based on large integer factorization and discrete logarithm problems (such as RSA and ECC) will face the risk of failure. Developing quantum-resistant key exchange schemes has become a core direction for cryptographic development. Although some research has explored lattice-based key exchange mechanisms and attempted to integrate them into the TLS protocol, the following shortcomings still exist: First, some schemes are based on identity base structures and require PKG systems, making deployment complex; second, no dedicated optimization mechanisms have been designed for communication scenarios with significant differences in computing power; and third, there is a lack of systematic consideration of the compatibility and ease of deployment of the protocol under the TLS system.
[0004] Therefore, there is an urgent need to propose a new key exchange mechanism that is both quantum-resistant and reduces the computational burden on low-power devices, and can be seamlessly integrated with the TLS protocol, in order to meet the secure, lightweight, and deployable communication needs in scenarios such as the Internet of Things. Summary of the Invention
[0005] To address the aforementioned technical issues, this application proposes a lattice-based TLS unbalanced key exchange protocol, apparatus, readable storage medium, and product.
[0006] The technical solution adopted in this application is: a lattice-based TLS unbalanced key exchange protocol, comprising the following steps:
[0007] Step 1: The client first sends a handshake message ClientHello. After receiving the handshake message, the server replies with ServerHello, along with the server certificate and the server key exchange message ServerKeyExchange. Then, the server ends the phase with ServerHelloDone.
[0008] The server certificate (Certificate) and the server key exchange message (ServerKeyExchange) are calculated using a lattice-based unbalanced key exchange protocol, including the server public key. and server identity information Server shared key ;
[0009] Step 2: After receiving the server's response, the client calculates the ClientKeyExchange message; then, the client sends a ChangeCipherSpec message to indicate that it is about to switch to a new encryption key, calculates the compute keys, and finally sends a Finished message to indicate that the client's handshake process is complete.
[0010] The ClientKeyExchange message includes the client public key calculated using a lattice-based unbalanced key exchange protocol. Client identity information Temporary keys generated by the client Client shared key and signal value The compute keys are client session keys calculated using a lattice-based unbalanced key exchange protocol. ;
[0011] Step 3: The client verifies the server's signature to confirm the legitimacy of its identity. Then, the client accepts the handshake to indicate that all verifications have passed and sets the status to "accepted".
[0012] Step 4: The server locally calculates the same symmetric server session key as the client session key using a lattice-based unbalanced key exchange protocol. The server accepts the signal to complete the handshake; then it begins to encrypt and transmit the actual business data using the negotiated symmetric key. At this point, the TLS handshake is complete, and the application data exchange phase begins, with both parties communicating securely.
[0013] Furthermore, the implementation process of the lattice-based unbalanced key exchange protocol is as follows:
[0014] Step 1: The system first generates common parameters q and n, and defines a polynomial ring R. q =Z q [x] / f(x), selection error distribution Where q is a prime number and n is a positive integer. Let f(x) represent the ring of integers modulo q, i.e., the set of residue classes {0,1,…,q−1} obtained by taking all integers modulo q. is a polynomial, and n is a power of 2. Let it be a variable used to represent the unknowns in the polynomial. Represent the quotient ring; then give a uniformly randomly generated polynomial a. s and e Follows distribution Where s is the secret element and e is the error; the server first selects a secret element that conforms to the rules. Distributed secret element server private key and server-side noise vector Then the server calculates the server public key. =a* +2 Calculate server identity information == + The server will and Send it to the client as Message1;
[0015] Step 2: Then the client selects an option to comply. Distributed secret element client private key Adjacent to client-side noise Then the client calculates the client's public key. =a* +2 Calculate client identity information = + Calculate the temporary key generated by the client. =a* The client put and Send it to the server as Message2;
[0016] Step 3: The server receives data from the client. Next, calculate the server's shared key. = *( - ), and among them Replace with a* , Replace with a* +2 Then Change to + After expanding the formula, we can finally obtain... =a -2 ;
[0017] Step 4: The client receives data from the server. and Post-calculation of client shared key = *( *a)- , and Change to + , Replace with a* +2 After expanding the formula, we can finally obtain... =a -2 ; Calculate signal value =S( ), and will Send it to the server as Message3;
[0018] Step 5: The server will and The result is fed into the robust extractor for computation, and the result is hashed to obtain the server's shared key. ;
[0019] Step 6: The client will and The result is fed into the robust extractor for computation, and the result is hashed to obtain the client shared key. .
[0020] Furthermore, in step 1, when the server requires client authentication, it also needs to send a CertificateRequest* message. Subsequently, after the client receives the server's response, it needs to send a Certificate* message.
[0021] Furthermore, the server shared key calculated in step 5 =SHA2-256(E( , ));
[0022] The client shared key calculated in step 6 =SHA2-256(E( , )).
[0023] A computer device includes a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method.
[0024] A computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the method.
[0025] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the method.
[0026] The advantages of this application over the prior art are as follows: The key exchange method proposed in this application has the following advantages:
[0027] 1. Innovative unbalanced design: The core of this application lies in introducing an unbalanced computing allocation mechanism on the basis of the existing RLWE key exchange protocol, which effectively solves the performance bottleneck of low computing power devices in key negotiation;
[0028] 2. Post-quantum security: The protocol is built on the R-LWE problem, which has the mathematical foundation to resist quantum attacks and meets the security requirements of future network communication;
[0029] 3. High TLS integration: By optimizing the message embedding structure, the protocol can be naturally embedded into the TLS 1.3 handshake process, is compatible with existing TLS architectures, and is easy to deploy;
[0030] 4. High practicality: This protocol is particularly suitable for asymmetric communication scenarios between IoT terminals and high-performance servers, balancing security and computing efficiency. Attached Figure Description
[0031] The following description, in conjunction with the accompanying drawings, further illustrates this application:
[0032] Figure 1 A flowchart of a lattice-based unbalanced key exchange protocol provided in this application embodiment;
[0033] Figure 2 A flowchart of a lattice-based TLS unbalanced key exchange protocol is provided for embodiments of this application;
[0034] Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0035] like Figure 1-3 As shown, this application provides a lattice-based TLS unbalanced key exchange protocol, which is suitable for secure communication between communication devices with asymmetric computing power. It systematically integrates post-quantum lattice cryptography, asymmetric computation distribution mechanism and TLS protocol compatibility, and has the advantages of post-quantum security, computational load optimization and TLS protocol integration.
[0036] Specifically, the lattice-based TLS unbalanced key exchange protocol of this application can be divided into two parts: the first part is the lattice-based unbalanced key exchange protocol, and the second part is the process of embedding the lattice-based unbalanced key exchange protocol into TLS.
[0037] The following is the flow of a lattice-based unbalanced key exchange protocol, such as... Figure 1 As shown, it specifically includes:
[0038] Step 1: The system first generates common parameters q and n, and defines a polynomial ring R. q =Z q [x] / f(x), selection error distribution Where q is a prime number and n is a positive integer. Let f(x) represent the ring of integers modulo q, i.e., the set of residue classes {0,1,…,q−1} obtained by taking all integers modulo q. is a polynomial, and n is a power of 2. Let it be a variable used to represent the unknowns in the polynomial. Indicates the quotient ring, that is Two polynomials are considered to be the same element if they are equal in modulus. Then, given a uniformly randomly generated polynomial a... s and e Follows distribution Where s is the secret element and e is the error. The server first selects a secret element that conforms to... Secret elements of distribution and Then the server calculates =a* +2 ,calculate == + The server will and Send it to the client as Message1;
[0039] Step 2: Then the client selects an option to comply. Secret elements of distribution and Then the client calculates =a* +2 ,calculate = + ,calculate =a* The client will... and Send it to the server as Message2;
[0040] Step 3: The server receives data from the client. Then, calculate = *( - ), and among them Replace with a* , Replace with a* +2 Then Change to + After expanding the formula, we can finally obtain... =a -2 ;
[0041] Step 4: The client receives data from the server. and Post-calculation = *( *a)- , and Change to + , Replace with a* +2 After expanding the formula, we can finally obtain... =a -2 ;calculate =S( ), and will Send it to the server as Message3;
[0042] Step 5: The server will and The result is fed into the robust extractor for computation, and the result is hashed to obtain the server's shared key. : =SHA2-256(E( , )); where E is the robust extractor;
[0043] Step 6: The client will and The result is fed into the robust extractor for computation, and the result is hashed to obtain the client shared key. : =SHA2-256(E( , )).
[0044] The meanings of the parameters in the above lattice-based unbalanced key exchange protocol are shown in Table 1 below.
[0045] Table 1 Parameter Meaning
[0046]
[0047] The lattice-based unbalanced key exchange protocol proposed in this application is an innovation based on the classic lattice cryptography RLWE protocol. It introduces the concept of unbalanced key exchange into RLWE, transferring the time-consuming operation of polynomial multiplication to obtain a lattice-based unbalanced key exchange protocol. This protocol is then combined with TLS to obtain a lattice-based TLS unbalanced key exchange protocol. Its focus is on PK... A and PK B The calculation introduces noise e. A and e B This embodies lattice cryptography, which hides the key in an approximately linear equation consisting of "ring elements multiplied by the private key plus a small error". This allows the communicating parties to obtain a consistent value through noise tolerance, while the attacker must solve the shortest vector problem to remove the noise and recover the private key.
[0048] The traditional TLS process is as follows:
[0049] In the first phase of the handshake process, the client first sends a handshake message, ClientHello, notifying the server that it wishes to establish a secure communication connection. Upon receiving this message, the server replies with ServerHello, along with a Certificate and ServerKeyExchange message. If the server requires client authentication, it may also send an optional handshake message, CertificateRequest* (which indicates: "I need to verify your identity now; please send me your digital certificate." This message is only needed when the server requires authentication; the digital certificate is issued by a third-party Certificate Authority (CA) and contains extended fields such as the certificate holder's public key, the holder's identity information (domain name, organization, country, etc.), the CA's information and digital signature, validity period, and purpose (TLS client or server authentication)). This phase then ends with ServerHelloDone.
[0050] After receiving the server's response, the client begins sending Certificate* (if needed), then performs ClientKeyExchange, and sends CertificateVerify* (if a digital certificate is provided; this message is only sent when the client sends its Certificate message, whereby the client signs all messages sent from the beginning to the present with its private key, and the server verifies this signature using the client's public key). Next, the client sends a ChangeCipherSpec message, indicating an upcoming switch to a new encryption key, and computes the keys. Finally, it sends a Finished message, signifying the completion of the client's handshake process.
[0051] After receiving the ClientKeyExchange message from the client, the server performs key calculation and verifies the client's identity (if applicable). Once the server confirms the key calculation is correct, it sends an accept message, then performs CertificateVerify (if necessary), and also sends a ChangeCipherSpec message to begin encrypted communication using the new key. The server then executes compute keys and sends Finished, completing the handshake phase.
[0052] After the handshake is complete, the server verifies the client's signature to confirm its legitimacy, then proceeds to the computekeys calculation phase and sends "Finished". At this point, the TLS handshake is complete, and the application data exchange phase begins, allowing both parties to communicate securely.
[0053] Based on the above description of the traditional TLS rectification process and the specification of the lattice-based unbalanced key exchange protocol, such as Figure 2 As shown, the overall steps of the lattice-based TLS unbalanced key exchange protocol proposed in this application are as follows:
[0054] Step 1: The client first sends a handshake (ClientHello) message to notify the server that it wishes to establish a secure communication connection. Upon receiving this message, the server replies with ServerHello, along with a Certificate and a ServerKeyExchange message. If the server requires client authentication, it may also send a CertificateRequest*, and then concludes this phase with ServerHelloDone. The Certificate is issued by a third-party Certificate Authority (CA) and stored locally on the server. The ServerKeyExchange message is calculated using a lattice-based unbalanced key exchange protocol, including the server's public key calculated in Step 1. and server identity information and the server shared key obtained through step 3. .
[0055] Step 2: After receiving the server's response, the client begins sending Certificate* (if needed), then performs ClientKeyExchange, and sends CertificateVerify* (if a certificate is provided). Next, the client sends [ChangeCipherSpec], indicating that it is about to switch to a new encryption key, and computes the keys. Finally, it sends a Finished message, indicating that the client's handshake process is complete. After Finished... Figure 2 The double-lined arrow indicates that the client sends the first encrypted message, containing the MAC address of all preceding handshake data, for the server to verify the integrity of the handshake. The server accepts the message and checks if the CertificateVerify signature is valid.
[0056] ClientKeyExchange includes the client public key calculated via step 2 in a lattice-based unbalanced key exchange protocol. Client identity information Temporary key generated by the client And the client shared key calculated via step 4 and signal value The compute keys are those in step 6. .
[0057] Step 3 begins with verifying the signature: The client verifies the signature on the server side to confirm the legitimacy of the identity. Then, accept indicates that the handshake has passed all verifications, and the status is set to "accepted".
[0058] Step 4: The server locally performs the exact same key calculation as the client using step 5 of the lattice-based unbalanced key exchange protocol, obtaining the same symmetric key. On the server side, `accept` indicates that the handshake is complete.
[0059] Finally, the application data indicates that the actual business data will be transmitted using the negotiated symmetric key. At this point, the TLS handshake is complete, and the application data exchange phase begins, allowing both parties to communicate securely.
[0060] This protocol builds a key exchange mechanism based on the Ring-with-Error (R-LWE) problem, which has good resistance to quantum attacks. In the protocol design, an unbalanced computation allocation mechanism is introduced, that is, the two communicating parties share different computational tasks according to their computing power. The high-computing-power device undertakes most of the key generation and conversion operations, while the low-computing-power device only needs to complete a small number of polynomial calculations and hash operations.
[0061] The unbalanced computation allocation mechanism of this application works as follows: Unbalanced operation mainly involves the transfer of time-consuming operations. Among lattice-based operations, the most time-consuming operation is polynomial multiplication over rings. Therefore, this application proposes an unbalanced protocol to share the burden of computational time consumption. For details, please refer to... Figure 1 On the left side of the diagram, there is only one polynomial multiplication operation: K A =R A *(T) B -PK B (); there is a cubic polynomial multiplication on the right: T B =a*U B Once, K B =R B *(U A *a-PKA This is repeated twice, for a total of three times, thus enabling an unbalanced protocol. Figure 1 Device B can serve as a high-performance computing device, undertaking most of the key generation and conversion operations.
[0062] The protocol can be seamlessly embedded into the TLS 1.3 handshake process. Without changing the original TLS communication semantics and message structure, it achieves high compatibility with the existing TLS protocol stack by inserting RLWE-related key materials in stages such as ClientHello and ServerKeyExchange, and supports deployment on platforms such as OpenSSL and GnuTLS.
[0063] Furthermore, the protocol ensures the consistency and confidentiality of the negotiation results by constructing a shared key using a robust extractor and SHA-256 hash. Experimental evaluations show that this scheme reduces the computational burden on the client while maintaining security, making it suitable for lightweight authentication communication between low-power IoT devices and high-performance servers.
[0064] The key point of this application's key exchange protocol is that it solves the problem of efficient and secure communication for low-computing-power devices in IoT scenarios through unbalanced computation allocation, improvements to the RLWE quantum-resistant algorithm, and TLS compatibility extensions. Its protection points cover core technical features such as algorithm design, protocol flow, key generation, and noise management, ensuring the solution's comprehensive advantages in quantum security, computational efficiency, and deployment cost.
[0065] The key exchange protocol in this application does not require an identity base structure, but is based on a peer-to-peer computing model for key negotiation; and it introduces an asymmetric computing task allocation mechanism, which is an optimized design for heterogeneous devices in IoT scenarios, with different focuses on the optimization of computing structure.
[0066] Furthermore, the key exchange protocol of this application adopts an interactive TLS structure, embeds a handshake process, has clear message rounds and encrypted material exchange, solves the problem of optimizing the computational burden of the TLS handshake phase, and provides a system-level deployment solution; moreover, the key exchange protocol of this application is based on the RLWE lattice construction and has a clear post-quantum security foundation.
[0067] Figure 3A structural block diagram of a computer device according to an embodiment of this application is shown. As shown in Figure 3, the computer device includes a memory and a processor, wherein the memory stores instructions executable on the processor. When the processor executes the instructions, it implements the methods described in the above embodiments. The number of memories and processors can be one or more. This computer device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The computer device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.
[0068] The computer device may also include a communication interface for communicating with external devices and exchanging data. The devices are interconnected using different buses and can be mounted on a common motherboard or otherwise as needed. The processor can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as a display device coupled to the interface). In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). The bus can be divided into address buses, data buses, control buses, etc. For ease of illustration, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0069] Optionally, in a specific implementation, if the memory, processor, and communication interface are integrated on a single chip, then the memory, processor, and communication interface can communicate with each other through an internal interface.
[0070] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting advanced RISC machines (ARM) architecture.
[0071] This application provides a computer-readable storage medium (such as the memory described above) that stores computer instructions, which, when executed by a processor, implement the method provided in this application.
[0072] Optionally, the memory may include a stored program area and a stored data area, wherein the stored program area may store the operating system and application programs required for at least one function; the stored data area may store data created based on the use of the computer device for mapping. Furthermore, the memory may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the computer device for mapping via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0073] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A lattice-based TLS unbalanced key exchange protocol, characterized in that: Includes the following steps: Step 1: The client first sends a handshake message ClientHello. After receiving the handshake message, the server replies with ServerHello, along with the server certificate and the server key exchange message ServerKeyExchange. Then, the server ends the phase with ServerHelloDone. The server certificate (Certificate) and the server key exchange message (ServerKeyExchange) are calculated using a lattice-based unbalanced key exchange protocol, including the server public key. and server identity information Server shared key ; Step 2: After receiving the server's response, the client calculates the ClientKeyExchange message; then, the client sends a ChangeCipherSpec message to indicate that it is about to switch to a new encryption key, calculates the compute keys, and finally sends a Finished message to indicate that the client's handshake process is complete. The ClientKeyExchange message includes the client public key calculated using a lattice-based unbalanced key exchange protocol. Client identity information Temporary keys generated by the client Client shared key and signal value The compute keys are client session keys calculated using a lattice-based unbalanced key exchange protocol. ; Step 3: The client verifies the server's signature to confirm the legitimacy of its identity. Then, the client accepts the handshake to indicate that all verifications have passed and sets the status to "accepted". Step 4: The server locally calculates the same symmetric server session key as the client session key using a lattice-based unbalanced key exchange protocol. The server accepts the signal to complete the handshake; then it begins to encrypt and transmit the actual business data using the negotiated symmetric key. At this point, the TLS handshake is complete, and the application data exchange phase begins, with both parties communicating securely.
2. The lattice-based TLS unbalanced key exchange protocol according to claim 1, characterized in that: The implementation process of the lattice-based unbalanced key exchange protocol is as follows: Step 1: The system first generates common parameters q and n, and defines a polynomial ring R. q =Z q [x] / f(x), selection error distribution Where q is a prime number and n is a positive integer. Let f(x) represent the ring of integers modulo q, i.e., the set of residue classes {0,1,…,q−1} obtained by taking all integers modulo q. is a polynomial, and n is a power of 2. Let it be a variable used to represent the unknowns in the polynomial. Represent the quotient ring; then give a uniformly randomly generated polynomial a. s and e Follows distribution Where s is the secret element and e is the error; the server first selects a secret element that conforms to the rules. Distributed secret element server private key and server-side noise vector Then the server calculates the server public key. =a* +2 Calculate server identity information == + The server will and Send it to the client as Message1; Step 2: Then the client selects an option to comply. Distributed secret element client private key Adjacent to client-side noise Then the client calculates the client's public key. =a* +2 Calculate client identity information = + Calculate the temporary key generated by the client. =a* ; The client put and Send it to the server as Message2; Step 3: The server receives data from the client. Next, calculate the server's shared key. = *( - ), and among them Replace with a* , Replace with a* +2 Then Change to + After expanding the formula, we can finally obtain... =a -2 ; Step 4: The client receives data from the server. and Post-calculation of client shared key = *( *a)- , and Change to + , Replace with a* +2 After expanding the formula, we can finally obtain... =a -2 ; Calculate signal value =S( ), and will Send it to the server as Message3; Step 5: The server will and The result is fed into the robust extractor for computation, and the result is hashed to obtain the server's shared key. ; Step 6: The client will and The result is fed into the robust extractor for computation, and the result is hashed to obtain the client shared key. .
3. The lattice-based TLS unbalanced key exchange protocol according to claim 2, characterized in that: In step 1, when the server requires client authentication, it also needs to send a CertificateRequest* message. Subsequently, after the client receives the server's response, it needs to send a Certificate* message.
4. A lattice-based TLS unbalanced key exchange protocol according to claim 2, characterized in that: The server shared key calculated in step 5 =SHA2-256(E( , )); The client shared key calculated in step 6 =SHA2-256(E( , )), where E is the robust extractor.
5. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-4.
6. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1-4.
7. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1-4.