What a quantum-safe Internet looks like
How to secure websites against quantum computing threats
Behind the scenes of the Internet, public-key cryptography (i.e., RSA, Diffie-Hellman, and Elliptic Curve Cryptography) protects data like passwords and payment details from being read by anyone as it travels across the network. The development of quantum computers capable of breaking public-key cryptography requires a new Internet infrastructure.
Post-quantum upgrades to browsers and security protocols have been ongoing, but recent announcements about protecting the Internet from quantum computing have reignited questions about what else needs to be done.
Last week, Google revealed that it is taking the first step towards quantum-resistant website identification, starting by upgrading its TLS certificates to better support post-quantum signatures. Cloudflare’s new platform shows that post-quantum encryption adoption for Internet data transfer remains limited.
A fully quantum-safe Internet is still a work-in-progress. This article describes and explains how quantum-safe cryptography works and the current progress in implementing it.
Current security guarantees of the Internet
The existing Internet infrastructure currently provides security guarantees we expect when using the Internet, such as:
Only the final website has access to sensitive data, such as passwords and payment details, when entered.
The website they are visiting is legitimate and not a fake version. For instance, Facebook.com is Meta’s social media platform, and hackers cannot alter the website domain to another site.
However, this was not always the case. Before the widespread adoption of security protocols that use public-key cryptography, such as SSL/TLS in the late 1990s, anyone on the same network could detect other users’ activity, including their usernames and passwords used for login.
Lookalike websites without SSL certificates, or using HTTPS, tricked users into logging in and intercepted their logins to real websites.
A quantum computer that can break public-key cryptography could revert the Internet to the insecure days of the 1990s. To ensure current security guarantees, quantum-resistant cryptography must replace the current public-key cryptography that secures the Internet.
How to quantum-secure the Internet
Any new, post-quantum infrastructure must maintain the same security without impacting the user experience in these key areas:
Connecting to a secure website
Identifying a legitimate website
Protecting sensitive data
Connecting to a secure website
The underlying process that a browser uses to connect to a website heavily relies on cryptography that needs to be upgraded to a post-quantum alternative. The adoption of post-quantum alternatives is increasing, but more action is needed.
How a secure website connection works
To establish a secure connection for transmitting sensitive data to the website, the browser and web server must complete a TLS handshake to agree on the encryption keys. A quantum computer could break the public-key cryptography that generates these encryption keys, generate the keys itself, impersonate the other party, and read sensitive data being sent between the browser and the web server.
The graph shows each step of the TLS handshake and how a quantum computer could compromise cryptography, enabling it to impersonate parties and generate encryption keys for a secure connection.
At a high level, the client and server use non-quantum-resistant public-key cryptography to exchange information and agree on encryption keys. A client, such as a web browser or an API, sends its information, including to the server. The server creates a secret from both its and the client’s info, which is never sent back. The server then sends its identity info to the client. The client verifies this and creates a secret based on it. These secrets generate the encryption keys.
Using post-quantum solutions to securely connect to websites
Instead of using public-key cryptography, such as Elliptic Curve Diffie-Hellman (for example, X25519), to generate the shared secret, clients and servers can use post-quantum key agreement schemes, also known as key exchange algorithms.
Clients and browsers are selecting X25519MLKEM768 as their preferred option, a hybrid solution that blends traditional elliptic-curve (X25519) and post-quantum cryptography (ML-KEM). It is the most adopted post-quantum solution as it offers backup security if one scheme is compromised and is more efficient than fully post-quantum alternatives.
In Steps 2 and 4 of the TLS handshake, the client and server each generate two secrets: one using the traditional X25519 scheme and another using the post-quantum ML-KEM. The final secret is the concatenation of the X25519 and ML-KEM shared secrets.
The main assumption is that a quantum computer cannot break both schemes simultaneously. A quantum computer would need to correctly guess both the X25519 and ML-KEM secrets between the same browser and web server, which is very hard.
Since X25519MLKEM768 uses both schemes, it requires more data to be transmitted and slows the TLS handshake; it still remains more efficient than fully post-quantum options, which adds to its popularity.
Researchers found X25519MLKEM768 is about 0.0025 seconds, or 20 percent, slower than X25519, but it is still not as noticeably slow by several orders of magnitude as post-quantum options, such as MLKEM768 and MLKEM1024 [1]. In practice, the Chrome team observed an average latency of four percent across all TLS handshakes with X25519MLKEM768, which they considered negligible for their users [3].
Adoption of X25519MLKEM768
The adoption of X25519MLKEM768 is progressing slowly: clients are adopting it quickly, but web servers have not yet.
The latest versions of most browsers, including popular ones such as Chrome, Firefox, Safari, Brave, and Edge, already support X25519MLKEM768.
The adoption of post-quantum cryptography on servers is much, much lower. Currently, only 8.6 percent of servers use X25519MLKEM768, up 3.4 percentage points from the previous year.
This disparity in adoption between clients and servers is technically a challenge, as both must support the same post-quantum cryptography scheme for it to work; otherwise, they will need to default to another supported scheme, potentially a non-post-quantum one. Ideally, web servers should adopt post-quantum cryptography because, without it, the connection between the origin server and reverse proxies will be insecure.
Fortunately, most web servers rely on intermediary services that use post-quantum cryptography. These intermediary services, known as reverse proxies, are servers that sit in front of original web servers and manage, secure, and accelerate incoming user traffic, including generating secrets and establishing secure connections with clients.
Popular reverse proxies such as Cloudflare and AWS CloudFront use X25519MLKEM768 to generate post-quantum-secure secrets. Upon connecting to the latest popular browsers, they can establish secure browser connections on behalf of the original web server.
For example, since the host of substack.com supports X25519MLKEM768, your connection to Substack remains post-quantum secure as long as you use an updated browser.
In turn, 65.7 percent of HTTPS traffic is already quantum-secure, as most intermediary services and browsers have implemented post-quantum cryptography.
However, that means one-third of Internet requests are currently not quantum-secure, indicating that much more adoption of X25519MLKEM768 is still needed.
Identifying legitimate websites
Unlike using post-quantum cryptography for web connections, applying it for website authentication noticeably slows down the experience and, therefore, is not widely adopted.
In Step 3 of the TLS Handshake in Figure 4, the server provides a certificate that verifies its identity, proving that it is the server for the specific domain, before the client can proceed to establish a secure connection. The certificate includes a public key and a signature that the client can use to verify that the signature is associated with the public key.
Currently, certificates are signed using the Elliptic Curve Digital Signature Algorithm (ECDSA), which is not quantum-resistant (You can read my previous article on ECDSA here).
The challenge with using a post-quantum signature scheme is its slowness and the need for more certificate storage.
Creating and verifying post-quantum signatures is slow, slowing down the TLS Handshake process. Cloudflare and independent research teams found that using a post-quantum signature scheme increased TLS latency by 20 to 40 percent [2, 3]. Chrome adopted X25519MLKEM768 for web connections because it only added four percent latency, but it avoids further quantum security by adding post-quantum signatures to certificates due to the substantially higher latency [3].
Another challenge is that post-quantum signatures are more than 30 times larger, requiring much more storage for certificates on web servers and certificate management platforms.
Google plans to solve the problem of signature sizes by introducing Merkle Tree certificates, with a finalization plan by Q3 2027. Instead of storing the signature directly in the certificate, they would be stored in separate Merkle Trees.
The certificate stores a Merkle proof, a cryptographic method used to verify that a specific piece of data in a Merkle Tree.
A standard ECDSA signature is 64 bytes. The smallest post-quantum signature is 2,420 bytes, and the Merkle proof that Google and its partners are initially reviewing is 734 bytes, making Merkle proofs a better alternative to replacing ECDSA [4].
Quantum-secure website identity and authentication will be slower than for the two other flows, as upgrading to post-quantum signatures is the most challenging aspect of a post-quantum Internet.
Protecting sensitive data
The quantum security level of AES-128, the current method for encrypting data sent between a client and a server, is often debated.
Using AES-128, the plaintext is encrypted with a 128-bit key, which a hacker would try to recover to decrypt and steal data.
Organizations such as the U.S. National Institute of Standards and Technology and Cloudflare do not consider AES-128 highly vulnerable to quantum computing.
Some organizations, like Cisco, recommend upgrading to AES-256, which uses a longer 256-bit key, making it more difficult for a quantum computer to crack and thus providing better system protection. Although NIST does not recommend that all enterprises migrate, all U.S. government organizations and major cloud providers such as Google Cloud and Amazon Web Services already use AES-256.
Conclusion
A quantum-safe Internet has advanced steadily, with the flows ranked by the most post-quantum adoption:
Connecting to a secure website (High)
Protecting sensitive data (Some already consider it post-quantum secure, while others do not)
Identifying a legitimate website (Low)
Browsers and reverse proxies commonly use X25519MLKEM768, a hybrid key agreement scheme that combines traditional and post-quantum methods, enabling websites to set up secure connections.
Many organizations believe that using AES-128 for data encryption on the Internet is already quantum-secure, but some push for migrations to higher-security AES-256.
The most significant challenge with a quantum-safe Internet is migrating to post-quantum signatures, which servers use to authenticate and prove their identity to clients such as browsers and APIs. Potential solutions, such as Merkle Tree Certificates, must address the slowness and high data storage requirements of post-quantum signatures.
Additional Sources
Mrinal, K., & S, V. (2025). 2025 9th International Conference on Computing, Communication, Control and Automation (ICCCBEA). In IEEE. Retrieved March 6, 2026, from https://ieeexplore.ieee.org/document/11283923.
Sikeridis, D., Kampanakis, P., & Devetsikiotis, M. (2020, February 26). Post-quantum authentication in TLS 1.3: A performance study. IACR Cryptology ePrint Archive. https://eprint.iacr.org/2020/071
Chromium. (2024, May 23). Advancing our amazing bet on asymmetric cryptography. Chromium. https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html
Benjamin, D., O’Brien, D., Westerbaan, B., Valenta, L., & Valsorda, F. (2026, March 2). Merkle Tree certificates. IETF Datatracker. https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/
love this!!
Great info yet again! If I could, I’d hire you immediately! I see you as being incredibly successful and soon! Best of luck.