TLS and Post-Quantum Cryptography

Transport Layer Security (TLS) is one of the most widely used cryptographic protocols, playing a critical role in securing communications across various applications — from web browsing to email and beyond.

However, the emergence of quantum computing is poised to fundamentally reshape the landscape of cybersecurity, threatening to break many of the classical cryptographic algorithms that TLS relies on today.

By leveraging the principles of quantum mechanics, quantum computing can solve certain problems that are practically unsolvable for classical — even supercomputing — systems, or at least not quickly enough to be useful.

As a result, the asymmetric cryptographic algorithms that TLS relies on — such as RSA and elliptic curve cryptography (ECC) — are intrinsically vulnerable to quantum attacks, though they remain secure until sufficiently powerful quantum computers exist.

One might argue that the so-called Q-Day — the day when large-scale, fault-tolerant quantum computers (capable of maintaining quantum states without errors) will be able to break 2048-bit RSA encryption — is still years away. Optimistic estimates often place this milestone somewhere around 2035 to 2040.

Nevertheless, two important considerations must be kept in mind:

1. Some researchers anticipate a faster timeline, especially given the increasing investment from both tech giants and national governments. Under these conditions, a breakthrough could occur as early as 2027–2030.

2. Even in the absence of an immediate quantum threat, the so-called harvest now, decrypt later approach presents a serious concern. Following this strategy, malicious actors intercept and store encrypted data today, with the intent of decrypting it once quantum computers become powerful enough.

From this perspective, it becomes crucial to assess the risk of transmitting sensitive information over non–quantum-safe channels today — particularly if that data must remain confidential for the next 10 years or more. This underscores the urgent need to implement post-quantum cryptographic solutions before the quantum threat fully materializes.

Building on the considerations above — and focusing specifically on the TLS protocol — I set out to assess the maturity of currently available tools, the quality of their documentation, ease of use, and the degree of customization required to conduct the following experiment: successfully complete a full TLS 1.3 handshake using only quantum-resistant cryptographic algorithms, specifically those standardized by NIST in August 2024.

I deliberately chose not to adopt hybrid approaches (e.g., combining classical and post-quantum key exchange mechanisms), as the goal was to establish a TLS session based purely on NIST-approved post-quantum primitives.

The technical environment used for the experiment was composed of the following components:

• A reverse proxy based on NGINX, custom-built using OpenSSL 3 with the Open Quantum Safe (OQS) provider, enabling support for post-quantum cryptographic algorithms.
• A Spring Boot microservice, exposing a simple “Hello, World!” page over HTTPS, serving as the backend endpoint behind the reverse proxy.
• A client built on OpenSSL 3 with the OQS provider, used to initiate TLS 1.3 connections and validate the success of the handshake using post-quantum algorithms.

Architecture used to test a full TLS 1.3 handshake with quantum-safe algorithms only

The certificate chain used in the setup — composed of a root CA and the server certificate — is based on the digital signature scheme ML-DSA-65 (FIPS 204). This signature scheme features the following parameters:

• Private key size: 4032 bytes
• Public key size: 1952 bytes
• Signature length: 3309 bytes

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            70:1b:10:73:98:eb:cf:13:94:70:c3:16:ca:83:7e:78:e7:a9:19:0a
        Signature Algorithm: mldsa65
        Issuer: CN=PostQuantum TestCA
        Validity
            Not Before: Apr 11 17:33:01 2025 GMT
            Not After : Apr 11 17:33:01 2026 GMT
        Subject: CN=postquantum-nginx
        Subject Public Key Info:
            Public Key Algorithm: mldsa65
                mldsa65 public key:
                PQ key material:
                    b0:0c:f3:d3:24:d7:ea:77:75:8c:b5:49:73:ac:bc:
                    4b:4d:28:b6:a5:8b:90:0f:72:9d:7c:9e:d2:c7:25:
                    49:a9:37:e6:92:aa:50:65:d6:06:f4:b0:51:f4:28:
                    a5:90:5c:8d:e4:70:4e:98:28:60:3f:33:41:95:86:
                    ............................................:
                    (1952 bytes)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                0F:56:E7:1C:63:43:C6:69:28:DF:55:9B:BB:AD:99:79:D7:55:7C:84
            X509v3 Authority Key Identifier:
                F4:18:F9:03:E6:BC:10:B5:36:DA:9C:0A:38:68:7A:A9:FD:2C:6A:CC
    Signature Algorithm: mldsa65
    Signature Value:
        4e:40:76:8a:0a:34:33:1c:37:50:c0:bf:fa:5b:39:07:00:e2:
        dd:c7:87:07:e7:8c:97:3f:37:01:c4:79:2e:f9:01:1b:23:a0:
        7c:0c:cb:ad:14:e6:d9:88:d2:21:8f:0d:bb:4a:ef:fe:77:47:
        14:e7:62:57:20:5e:01:20:b7:65:70:56:37:2a:f7:b9:e5:8f:
        .....................................................:
        (3309 bytes)

For key exchange, I explicitly enforced the use of ML-KEM-1024 (FIPS 203), a NIST-standardized Key Encapsulation Mechanism (KEM). This algorithm is designed to be quantum-resistant and features the following parameters:

• Encapsulation (public) key size: 1568 bytes
• Decapsulation (private) key size: 3168 bytes
• Ciphertext size: 1568 bytes
• shared secret key size: 32 bytes

Without diving too deeply into technical details, a Key Encapsulation Mechanism (KEM) typically consists of three core algorithms:

1. Key Generation (KeyGen): generates a key pair, consisting of an encapsulation key (public) and a decapsulation key (private).
2. Encapsulation (Encaps): takes the encapsulation key as input and produces a ciphertext and a shared secret.
3. Decapsulation (Decaps): takes the ciphertext and the decapsulation key as input and returns the same shared secret.

This shared secret can then be used to derive session keys and establish a secure communication channel — in our case, within the TLS 1.3 handshake.

Key establishment using a KEM

In the TLS handshake, the client performs the KeyGen operation and includes the encapsulation key in the ClientHello message. The server, in turn, executes the encapsulation process and sends back the resulting ciphertext within the ServerHello message. This post-quantum key exchange mechanism replaces the traditional Diffie-Hellman-based approaches used in classical TLS handshakes, providing quantum-resilient forward secrecy.

By capturing the network traffic during the TLS handshake, it is possible to observe the correct use of the KeyShareEntry structure, as specified in the draft "ML-KEM Post-Quantum Key Agreement for TLS 1.3" (IETF draft-connolly-tls-mlkem-key-agreement-05):

enum {

         ...,

          /* ML-KEM Key Agreement Methods */
          mlkem512(0x0200),
          mlkem768(0x0201),
          mlkem1024(0x0202)

         ...,

    } NamedGroup;

.....................

struct {
        NamedGroup group;
        opaque key_exchange<1..2^16-1>;
    } KeyShareEntry;

.....................

struct {
      KeyShareEntry client_shares<0..2^16-1>;
    } KeyShareClientHello;

struct {
      KeyShareEntry server_share;
    } KeyShareServerHello;

This confirms that the post-quantum key exchange mechanism integrates seamlessly within the existing TLS 1.3 handshake structure, with the KeyShareEntry field carrying the encapsulation key in the ClientHello and the ciphertext in the ServerHello.

Below is a capture of the ClientHello message, highlighting the **key_share extension.**

As shown, the Key Share Entry includes:

• Group ID 514 (0x0202 in hexadecimal) — corresponding to ML-KEM-1024, as defined in the IETF draft.
• Key Exchange Length 1568— matching the expected size of the encapsulation key for ML-KEM-1024 (FIPS 203).

Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        ..........................
        Length: 1921
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 1917
            ..........................
            Extension: supported_versions (len=5) TLS 1.3, TLS 1.2
                Type: supported_versions (43)
                Length: 5
                Supported Versions length: 4
                Supported Version: TLS 1.3 (0x0304)
                Supported Version: TLS 1.2 (0x0303)
            ..........................
            Extension: key_share (len=1574)
                Type: key_share (51)
                Length: 1574
                Key Share extension
                    Client Key Share Length: 1572
                    Key Share Entry: Group: Key Exchange length: 1568
                        Group: (514)
                        Key Exchange Length: 1568
                        Key Exchange […]: 35971969472bf5c87dcfe5206ba32b8e06b......
                        ..........................

Below is the capture of the ServerHello message, showing the server's response within the key exchange process.

As in the client message, the Key Share Entry clearly indicates:

• Group ID 514 — confirming the use of ML-KEM-1024 as the agreed key exchange group.
• Key Exchange Length 1568 — corresponding to the expected size of the ciphertext, as defined by the ML-KEM-1024 specification.

This ciphertext, generated by the server using the encapsulation key received in the ClientHello, is returned to the client to complete the post-quantum key exchange.

Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        ............................
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 1654
            ..........................
            Extensions Length: 1582
            Extension: supported_versions (len=2) TLS 1.3
                Type: supported_versions (43)
                Length: 2
                Supported Version: TLS 1.3 (0x0304)
            Extension: key_share (len=1572)
                Type: key_share (51)
                Length: 1572
                Key Share extension
                    Key Share Entry: Group: Key Exchange length: 1568
                        Group: (514)
                        Key Exchange Length: 1568
                        Key Exchange […]: 37170becd94e922b6c21083060730bfb39d......
                        ............................

In addition to the key exchange mechanism, the TLS handshake also handles server authentication. During this phase, the server signs the handshake transcript using ML-DSA-65, the post-quantum digital signature algorithm selected for this experiment. The client then verifies both the certificate chain and the server’s signature, ensuring the authenticity and integrity of the communication channel.

Final Thoughts

This experiment demonstrates that a fully post-quantum TLS 1.3 connection — relying exclusively on NIST-standardized algorithms (ML-KEM-1024 for key exchange and ML-DSA-65 for digital signatures) — is technically feasible today using available tools, even though these solutions are still evolving and probably not yet ready for production environments.

While setting up such an environment requires a deep understanding of TLS internals and some degree of custom integration, the current tooling already provides a solid foundation to start experimenting and analyzing the potential impact of the post-quantum transition.

Classical cryptographic algorithms like RSA and ECC have been around for more than 45 years, with over three decades of widespread deployment and adoption. In contrast, post-quantum algorithms are relatively new and have yet to undergo the same level of real-world validation and integration.

Nevertheless, preparing for the post-quantum era is not optional — it is essential, especially for forward-looking organizations concerned with long-term data confidentiality.

Hands-on experimentation is a critical first step, but it must be paired with a comprehensive transition strategy — one that carefully balances security, performance, and interoperability, while keeping pace with the rapid evolution of cryptographic standards.

Organizations that begin today — by testing, learning, and planning — will be best positioned to adapt seamlessly when quantum-safe cryptography becomes not just a recommendation, but a requirement.