Classic password and anti-quantum password mixed TLS protocol communication method
By mixing classic and quantum-resistant ciphers in the TLS protocol, and directly attaching X25519 and Kyber public keys to ServerHello messages, the compatibility and delay problems caused by the splitting of ClientHello messages is solved, achieving an efficient TLS communication experience.
Patent Information
- Application Number
- CN202510682899.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-26
- Publication Date
- 2025-08-08
AI Technical Summary
When the existing TLS protocol introduces post-quantum key exchange, it faces the compatibility problems caused by the splitting of ClientHello messages and the increased delay in the handshake process, especially the problem of inability to effectively handle large packets under middleware and hardware limitations.
The TLS protocol communication method that mixes classic ciphers and quantum ciphers is adopted. By promoting the support of the X25519+Kyber hybrid key exchange algorithm suite in the initial ClientHello message of the client, and directly attaching the X25519 and Kyber public keys to the server ServerHello message, omitting the HelloRetryRequest process, realizing the completion of hybrid key negotiation within a handshake.
It significantly reduces the number of interactions of the protocol, avoids the compatibility of the intermediate box, improves the handshake efficiency and overall connection speed, is suitable for a performance-sensitive actual deployment environment, and achieves low latency resistant quantum migration.
Smart Images
Figure CN120454990A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of quantum-resistant cryptography migration and relates to a TLS protocol communication method that mixes classical cryptography with quantum-resistant cryptography, which is used to solve problems such as abnormal interruption of the TLS protocol caused by the large size of the quantum-resistant algorithm. Background Art
[0002] As quantum computing technology accelerates from theoretical breakthroughs toward engineering breakthroughs, the classical cryptographic systems relied upon by currently used encryption protocols, particularly TLS, face an unprecedented existential crisis. The rapid development of quantum computing, and in particular the emergence of Shor's algorithm, has ushered in a new attack vector capable of breaking existing public key cryptography algorithms, such as RSA and ECC, in polynomial time. These algorithms are the core foundation of most current network communication protocols, particularly TLS. However, over 90% of global HTTPS traffic still relies on TLS 1.3, whose key exchange and digital signature mechanisms rely heavily on classical cryptographic algorithms, such as ECDHE and RSA-PSS, which are vulnerable to quantum computing. This makes the existing security model extremely vulnerable to the threat of quantum computing.
[0003] This conflict between cryptographic security and the potential threat of quantum computing has compelled industry and academia to launch an urgent quantum migration plan for the TLS protocol. This plan encompasses a comprehensive effort, from the development of post-quantum cryptographic algorithms to the standardization and implementation of the protocol. To adapt to the upcoming quantum computing era, researchers and engineers worldwide are actively developing quantum-safe algorithms and integrating them into the existing TLS protocol framework to ensure the protocol's security in quantum computing environments. This effort involves not only the design and implementation of new algorithms, but also a comprehensive upgrade and reconstruction of existing protocols to ensure that network communications maintain their privacy protection and data security features before the arrival of the quantum era. This challenge requires rapid coordination and cooperation among all parties to achieve multiple goals, including compatibility, scalability, and quantum resistance, to promote the future development of internet security.
[0004] In industry practice, tech giants have pioneered diverse technological approaches. Google was an early adopter of quantum-resistant migration research and has extensive production experience. In Chrome version 116 (August 2023), it pioneered the X25519-Kyber768 hybrid key exchange protocol, combining the classical elliptic curve algorithm X25519 with the NIST-standard quantum-resistant algorithm Kyber-768. This protocol generates session keys through a "double encryption" mechanism, resistant to the "intercept now, decrypt later" attack of quantum computers. However, when migrating post-quantum key agreement to TLS, Google encountered a major challenge: protocol rigidity. This issue stems from the relatively large public keys of post-quantum algorithms like Kyber, which results in the ClientHello message being split into multiple packets. In early TLS implementations, ClientHello message depacketization was extremely rare, leading many software and hardware to mistakenly assume it would never occur. This assumption led to compatibility issues with many middleware and load balancers, most notably in 2019, when middleware from certain vendors experienced connection drops due to ClientHello message depacketization. While most TLS implementations now support this unpacking, there are still some limited cases where middleboxes in TLS will fail due to hardcoded limits on message size.
[0005] In order to smoothly transition to post-quantum key agreement, Google adopted the HelloRetryRequest mechanism, the process of which is as follows: Figure 1 As shown in the figure, Google avoids the client sending the X25519+Kyber key exchange directly in the ClientHello message. Instead, Google declares support for X25519+Kyber in the first ClientHello message and only sends the non-post-quantum secure X25519 exchange key. The X25519+Kyber exchange key is then included in the ClientHello message retransmitted after receiving the HelloRetryRequest. This approach effectively avoids the problem of ClientHello message fragmentation, thereby reducing connection failures caused by middleware unable to handle large packets.
[0006] However, this approach creates numerous problems. Such interactions make the overall protocol process overly complex and increase latency during the TLS handshake. Each renegotiation via the HelloRetryRequest mechanism, especially when the client sends a large ClientHello message with post-quantum key exchange, requires multiple calls to recv() to receive the entire message, increasing complexity and slowing down communication. This additional step significantly impacts TLS protocol efficiency, increasing communication latency and defying the requirements for efficient and secure communication. Summary of the Invention
[0007] In order to solve the additional delay problem caused by the HelloRetryRequest mechanism when Google introduced post-quantum key exchange in the TLS protocol, the present invention proposes a TLS protocol communication method that mixes classical cryptography and quantum-resistant cryptography. It aims to ensure compatibility and security while optimizing the key exchange and handshake process, reducing the number of interaction rounds in the handshake, thereby reducing overall latency, speeding up protocol execution, shortening latency, and providing a more efficient TLS communication experience.
[0008] In order to achieve the above object, the technical solution of the present invention includes:
[0009] A TLS protocol communication method that mixes classical cryptography and quantum-resistant cryptography, comprising the following steps:
[0010] 1) The client sends a ClientHello message to the server; the ClientHello message includes the X25519 public key and the hybrid classical / quantum-resistant algorithm key exchange suite OQS_CODEPOINT_X25519_KYBER512;
[0011] 2) After receiving the ClientHello message, the server returns a ServerHello message with the X25519 public key and Kyber public key to the client;
[0012] 3) After receiving the ServerHello message, the client sends a ClientKeyExchange message with an X25519 public key and Kyber ciphertext to the server to complete the hybrid key negotiation; the Kyber ciphertext is the ciphertext obtained by encapsulating the information using the Kyber algorithm public key encryption.
[0013] Furthermore, the fields of the ClientHello message include: ProtocolVersion, Random, SessionID, CipherSuites, CompressionMethods and Extensions; wherein, ProtocolVersion is used to record the TLS protocol version supported by the client, Random is used to record the random bytes generated by the client for generating session keys, SessionID is used to record the session ID specified by the client, CipherSuites is used to record the list of cipher suites supported by the client, CompressionMethods is used to record the list of compression methods supported by the client, and Extensions includes supported_group s, key_share, pq_algorithm_support, signature_algorithms; supported_groups is used to explicitly indicate support for the X25519 key exchange algorithm, key_share is used to record the X25519 public key provided by the client, pq_algorithm_support is used to record the client's declaration of support for the hybrid classical / quantum-resistant algorithm key exchange suite OQS_CODEPOINT_X25519_KYBER512, and signature_algorithms is used to record the signature algorithms supported by the client; the X25519 public key provided by the client is used to pair with the X25519 public key generated by the server to generate a shared key as part of the key exchange.
[0014] Furthermore, the fields of the ServerHello message include: ProtocolVersion, Random, SessionID, CipherSuite, CompressionMethod, and Extensions; wherein ProtocolVersion is used to record the TLS protocol version supported by the server, Random is used to record the random bytes generated by the server for generating the session key together with the random bytes in the client Random, SessionID is used to record the session ID selected by the server, CipherSuite is used to record the cipher suite selected by the server, and CompressionMethod is used to record the cipher suite selected by the server. Extensions are used to record the selected compression method. They include key_share, pq_algorithm_support, and supported_groups. key_share is used to record the X25519 public key generated by the server. pq_algorithm_support is used to record the server's declared support for the hybrid classical / quantum-resistant algorithm key exchange suite OQS_CODEPOINT_X25519_KYBER512. supported_groups is used to record the key exchange algorithm groups supported by the server. The X25519 public key generated by the server is used to pair with the client's X25519 public key to jointly generate a shared key.
[0015] Furthermore, the fields of the ClientKeyExchange message include: keyexchange and pq_algorithm_support; wherein keyexchange is used to record the X25519 public key provided by the client and the shared key generated by the client using the Kyber algorithm public key encryption encapsulation; pq_algorithm_support is used to record the client's declaration of support for the hybrid classical / quantum-resistant algorithm key exchange suite OQS_CODEPOINT_X25519_KYBER512.
[0016] Furthermore, after receiving the ServerHello message, the client generates a Finished message and sends it to the server; the Finished message of the client includes a hash value of all data in the ClientHello message and the ServerHello message, which is used to verify the integrity of the handshake process.
[0017] Furthermore, after receiving the Finished message from the client, the server generates a Finished message and sends it to the client; the Finished message from the server includes a hash value of all data in the ClientHello message and the ServerHello message, which is used to ensure that the handshake process has not been tampered with.
[0018] Furthermore, the client and the server exchange Finished messages, establish a TLS session, and use the negotiated session key for encrypted communication; the data transmitted during the encrypted communication process is segmented and encrypted through the TLS record layer to ensure the confidentiality and integrity of the data.
[0019] Similar to Google's solution, the present invention also only advertises the hybrid key exchange algorithm suite (OQS_CODEPOINT_X25519_KYBER512) that supports X25519+Kyber in the client's initial ClientHello message, and attaches a non-post-quantum secure X25519 key exchange public key to ensure compatibility and prevent the ClientHello message from being unpacked due to excessive data volume. However, the difference is that Google's approach is to only negotiate non-post-quantum algorithms in the first handshake, and then guide the client to resend the ClientHello message that supports the hybrid algorithm through the HelloRetryRequest mechanism to complete the exchange of the Kyber public key. After receiving the resent ClientHello message from the client, the server sends a ServerHello message, and attaches the X25519 and Kyber public keys in the ServerHello message, thereby completing the hybrid key negotiation between the client and the server. Although this method ensures the stability of the connection, it introduces an additional half-round interaction process, which increases the handshake time and communication delay.
[0020] The improved solution proposed in this invention omits the HelloRetryRequest process. When the server first receives a ClientHello message containing an X25519 public key, and the Keyshare of the ClientHello message contains the cipher suite for hybrid key exchange (OQS_CODEPOINT_X25519_KYBER512), the server directly attaches the X25519 and Kyber public keys to the ServerHello message and begins the hybrid key exchange process. After receiving the ServerHello message, the client sends a ClientKeyExchange message to the server, attaching the X25519 public key and Kyber ciphertext to the message, thereby completing the hybrid key negotiation between the client and server within a single handshake round trip.
[0021] The advantages of the present invention are as follows:
[0022] This method significantly reduces the number of protocol interactions, avoiding middlebox compatibility issues caused by HelloRetryRequest, while also improving handshake efficiency and overall connection speed, making it more suitable for real-world deployments that are performance-sensitive or subject to middleware limitations. By reducing half-round interactions, this method achieves low-latency quantum migration resistance for the TLS protocol while maintaining quantum resistance and protocol security. BRIEF DESCRIPTION OF THE DRAWINGS
[0023] Figure 1 This is a flowchart of Google's HelloRetryRequest mechanism.
[0024] Figure 2 This is a flowchart of the "reduced process version TLS protocol" of the present invention. DETAILED DESCRIPTION
[0025] The present invention will be described in further detail below with reference to the accompanying drawings. The examples given are only used to explain the present invention and are not used to limit the scope of the present invention.
[0026] The method flow of the present invention is as follows Figure 2 As shown, the steps include:
[0027] 1. The client first sends a ClientHello message
[0028] The client first sends a ClientHello message containing the following fields:
[0029] ProtocolVersion: The TLS protocol version supported by the client (for example, TLS 1.3).
[0030] Random: Random bytes generated by the client, usually used to generate session keys.
[0031] SessionID: The session ID specified by the client. If it is a new session, it will be empty.
[0032] CipherSuites: A list of cipher suites supported by the client.
[0033] CompressionMethods: A list of compression methods supported by the client, usually NULL (indicating no compression).
[0034] Extensions:
[0035] o supported_groups: The client no longer passes the traditional elliptic curve or discrete logarithm group list in this field, but instead explicitly indicates support for the X25519 key exchange algorithm.
[0036] o key_share: The X25519 public key provided by the client as part of the key exchange. This public key is used to pair with the server's public key to generate a shared secret.
[0037] o pq_algorithm_support: The client declares support for the hybrid classical / quantum-resistant algorithm key exchange suite (OQS_CODEPOINT_X25519_KYBER512) and describes that support in this extension field (this field may vary depending on the specific implementation).
[0038] o signature_algorithms: The signature algorithms supported by the client (such as RSA-PSS, ECDSA, etc.). 2. Server Response ServerHello Message After receiving the ClientHello message, the server returns a ServerHello message containing the following fields:
[0039] ProtocolVersion: The TLS protocol version supported by the server (for example, TLS 1.3).
[0040] Random: Random bytes generated by the server, used together with the client's Random to generate the session key.
[0041] SessionID: The session ID selected by the server. If it is a new session, it will be empty.
[0042] CipherSuite: The cipher suite selected by the server.
[0043] CompressionMethod: The selected compression method, usually NULL (indicates no compression).
[0044] Extensions:
[0045] o key_share: The X25519 public key generated by the server and included in this field. This public key is used to pair with the client's X25519 public key to jointly generate a shared key (i.e., a mixed public key).
[0046] o pq_algorithm_support: The server responds to the client, announcing support for the hybrid classical / quantum-resistant algorithm key exchange suite (OQS_CODEPOINT_X25519_KYBER512).
[0047] o supported_groups: Although this field is no longer used in TLS 1.3, it can still be used to return the key exchange algorithm groups supported by the server in certain circumstances.
[0048] 3. After receiving the ServerHello message, the client sends a ClientKeyExchange message
[0049] The client first sends a ClientKeyExchange message containing the following fields:
[0050] keyexchange: The X25519 public key provided by the client is encrypted using the Kyber algorithm public key to encapsulate the shared key generated by the client.
[0051] pq_algorithm_support: The client declares support for the hybrid classical / quantum-resistant algorithm key exchange suite (OQS_CODEPOINT_X25519_KYBER512).
[0052] 4. The client sends a Finished message
[0053] After receiving the ServerHello, the client performs the following processing and sends a Finished message containing the following fields:
[0054] verify_data: The client calculates and generates this field, which contains the hash value of all data in the ClientHello and ServerHello messages. This field is used to verify the integrity of the handshake process.
[0055] 5. The server sends a Finished message
[0056] After receiving the Finished message from the client, the server performs the following processing and returns a Finished message containing the following fields:
[0057] verify_data: The server calculates and generates this field, which contains the hash value of all data in the ClientHello and ServerHello messages to ensure that the handshake process has not been tampered with.
[0058] 6. Start encrypted communication
[0059] Once both parties have exchanged Finished messages, the TLS session is officially established and begins encrypted communication using the negotiated session key. At this point, the TLS protocol encrypts and decrypts data through the following steps:
[0060] ApplicationData: Application data between the client and server will be encrypted and decrypted using the negotiated session key in subsequent communications.
[0061] Record Layer: Transmitted data will be segmented and encrypted through the TLS record layer to ensure data confidentiality and integrity.
[0062] While specific embodiments of the present invention have been disclosed for illustrative purposes, intended to facilitate understanding and implementation of the present invention, those skilled in the art will appreciate that various substitutions, variations, and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the disclosure of the preferred embodiments, and the scope of protection claimed in the present invention shall be determined by the scope of the claims.
Claims
1. A TLS protocol communication method that mixes classical cryptography and quantum-resistant cryptography, comprising the following steps: 1) The client sends a ClientHello message to the server; the ClientHello message includes the X25519 public key and the hybrid classical / quantum-resistant algorithm key exchange suite OQS_CODEPOINT_X25519_KYBER512; 2) After receiving the ClientHello message, the server returns a ServerHello message with the X25519 public key and Kyber public key to the client; 3) After receiving the ServerHello message, the client sends a ClientKeyExchange message with an X25519 public key and Kyber ciphertext to the server to complete the hybrid key negotiation; the Kyber ciphertext is the ciphertext obtained by encapsulating the information using the Kyber algorithm public key encryption.
2. The method according to claim 1, characterized in that The fields of the ClientHello message include: ProtocolVersion, Random, SessionID, CipherSuites, CompressionMethods and Extensions; among them, ProtocolVersion is used to record the TLS protocol version supported by the client, Random is used to record the random bytes generated by the client for generating session keys, SessionID is used to record the session ID specified by the client, CipherSuites is used to record the list of cipher suites supported by the client, CompressionMethods is used to record the list of compression methods supported by the client, Extensions includes supported_groups, key_share, p q_algorithm_support, signature_algorithms; supported_groups is used to explicitly indicate support for the X25519 key exchange algorithm, key_share is used to record the X25519 public key provided by the client, pq_algorithm_support is used to record the client's declaration of support for the hybrid classical / quantum-resistant algorithm key exchange suite OQS_CODEPOINT_X25519_KYBER512, and signature_algorithms is used to record the signature algorithms supported by the client; the X25519 public key provided by the client is used to pair with the X25519 public key generated by the server to generate a shared key as part of the key exchange.
3. The method according to claim 2, characterized in that The fields of the ServerHello message include: ProtocolVersion, Random, SessionID, CipherSuite, CompressionMethod, Extensions; among them, ProtocolVersion is used to record the TLS protocol version supported by the server, Random is used to record the random bytes generated by the server for generating session keys together with the random bytes in the client's Random, SessionID is used to record the session ID selected by the server, CipherSuite is used to record the cipher suite selected by the server, CompressionMethod is used to record the selected compression method, Extensions includes key_share, pq_algorithm_support and supported_groups, key_share is used to record the X25519 public key generated by the server, pq_algorithm_support is used to record the server's declared support for the hybrid classical / quantum-resistant algorithm key exchange suite OQS_CODEPOINT_X25519_KYBER512, supported_groups is used to record the key exchange algorithm groups supported by the server; the X25519 public key generated by the server is used to pair with the client's X25519 public key to jointly generate a shared key.
4. The method according to claim 3, characterized in that The fields of the ClientKeyExchange message include: keyexchange and pq_algorithm_support; keyexchange is used to record the X25519 public key provided by the client and the shared key generated by the client using the Kyber algorithm public key encryption package; pq_algorithm_support is used to record the client's declaration of support for the hybrid classical / quantum-resistant algorithm key exchange suite OQS_CODEPOINT_X25519_KYBER512.
5. The method according to claim 1, wherein After receiving the ServerHello message, the client generates a Finished message and sends it to the server. The Finished message of the client includes a hash value of all data in the ClientHello message and the ServerHello message, which is used to verify the integrity of the handshake process.
6. The method according to claim 5, characterized in that After receiving the Finished message from the client, the server generates a Finished message and sends it to the client; the Finished message from the server includes a hash value of all data in the ClientHello message and the ServerHello message to ensure that the handshake process has not been tampered with.
7. The method according to claim 6, characterized in that After the client and the server exchange Finished messages, a TLS session is established and the negotiated session key is used for encrypted communication. The data transmitted during the encrypted communication is segmented and encrypted through the TLS record layer to ensure the confidentiality and integrity of the data.