Post-quantum TLS is being implemented now
A quantum computer that will solve cryptographic problems (cryptographically-relevant quantum computer or CRQC in NSA terminology), is still far from reality. But the problem is that the creators of such a computer are unlikely to immediately inform the world of its existence, but may secretly use the opportunity to hack the world cryptographic system.
The worst thing is that with the advent of CRQC it will be possible to decrypt all encrypted traffic intercepted and stored in previous years (i.e. now). The recording and storage of encrypted traffic is currently carried out by hosting providers, mobile operators, Internet providers and intelligence agencies (strategy harvest now, decrypt later).
The industry has already begun preparing for such a scenario. Since many pre-quantum ciphers will be compromised, the transition to new, post-quantum algorithms must be thought through in advance.
Browser developers have also begun to implement support for post-quantum algorithms, a future encryption standard for websites on the Internet that is planned to be included in TLS 1.3.
Next Generation TLS
Last year, Chrome developers
to implement browser support for the hybrid post-quantum encryption protocol ML-KEM (formerly known as Kyber). It is currently in draft form
but in essence it is a combination of a pre-quantum algorithm on elliptic curves
and post-quantum algorithm
.
Kyber-768 — a quantum-resistant key encapsulation method, NIST PQC Competition Winner for general-purpose ciphers (website access). For digital signatures, the winners are different.
In other words, in 2022 NIST has chosen Kyber-768 as a next-generation TLS. And now Chrome developers offer approve the “hybrid” version of X25519Kyber768 (Kyber-768 + X25519) as a standard.
In May 2024, the latest ML-KEM specification for TLS 1.3 and QUIC enabled by default on all desktop versions of Chrome (since Chrome version 124.2).
Since the standards from NIST and IETF are not yet finalized, the current implementation in Chrome will be removed and replaced with the final versions later. At this stage, it is more of an experiment for enthusiasts who want to try out how the post-quantum encryption of the future works right now.
Launch of Quantum-Resistant Key Exchange – Part a broader strategy on the priority implementation of post-quantum cryptography in all existing systems, taking into account the likelihood of a quantum threat.
Quantum threat
In the context of HTTPS, cryptography is used primarily in three ways:
- Symmetric encryption/decryption. HTTP transmits data inside TLS using an AEAD cipher such as AES-GCM. These algorithms are generally considered safe for quantum cryptanalysis, they can be left.
- Key exchangeSymmetric cryptography requires a secret key. Key exchange is a form of asymmetric cryptography in which two parties mutually generate a shared secret key over a public channel. This secret key can be used for symmetric encryption and decryption. All existing forms of asymmetric key exchange standardized for use in TLS are vulnerable to quantum cryptanalysis.
- AuthenticationIn HTTPS, authentication is achieved primarily through digital signatures, which are used to transmit server credentials, handshake authentication, and certificate issuance transparency. All digital signature and public key algorithms standardized for TLS authentication are vulnerable to quantum cryptanalysis.
This means two specific quantum threats to HTTPS:
- Threat to traffic generated today: An adversary can now store encrypted traffic – and wait for CRQC to appear to decrypt it after the fact.
- Future encrypted traffic spoofing: If CRQC does emerge, it could be used to break HTTPS authentication and impersonate the server from CRQC's side.
According to a survey of experts for an analytical report
“Quantum Threat Timeline 2023”
According to the Global Risk Institute, the probability of breaking the RSA-2048 cipher within the next 15 years is about 43%:
Chrome's post-quantum strategy also includes improving cryptographic certificates Web PKI and rules Chrome Root Program for certification centers.
To protect current traffic from future decryption, post-quantum encryption algorithms should be implemented now, before CRQC. Implementing ML-KEM in browsers allows servers to protect themselves from this attack.
It should be noted that the implementation of post-quantum TLS is associated with a number of difficulties, primarily with large size of cryptographic primitives (1 KB of traffic during handshake in ML-KEM instead of 32 bytes in X25519). It is necessary to split ClientHello in TLS by two packets, resulting in a 4% increase in average latency for all TLS handshakes in Chrome.
However, when reusing HTTP/2 and HTTP/3, this increase is no longer reflected in the metrics. Core Web Vitals on the desktop. Unfortunately, the difference is still noticeable under Android, where the channel bandwidth is lower and the latency is higher. That's why the new TLS hasn't been rolled out to Chrome for Android yet.
The increase in traffic is even more dramatic for authentication. ML-DSA (Dilithium) keys and signatures are 40 times larger than ECDSA. Today, a typical TLS connection uses two public keys and five signatures for authentication. This means that ML-DSA will add approximately 14 KB to the TLS handshake. Cloudflare ratingthis will increase latency by 20-40%. Therefore, alternative approaches to HTTPS authentication are currently being developed, such as Trust Expressions for TLS And TLS certificates in Merkle tree.
In the future, website owners may have to choose between the security of new customers and compatibility with old customers.
