Post-Quantum Cryptography in February 2025

February 19th, 2025

About a year ago, I posted a summary of where the industry stands with regards to post-quantum cryptography. Since then, a lot has happened, and as I'm tracking the developments both for work (I recently gave a presentation on this topic to the FS-ISAC CISO Congress) and out of my own interest, I figured it might be useful to provide another update for people not closely following this topic.

Quantum Computer Capabilities

Last year, a lot of focus in the industry was on the total number of qubits available on a given processor, with, e.g., IBM proudly having broken the 1,000 qubit threshold with its Condor chip. But since then, we have not seen any major announcements about the sheer number of qubits per processor. Instead, we've seen headlines like "Microsoft and Atom Computing unveil 24-qubit quantum machine" (Microsoft's announcement) or "IBM's newest 156-qubit quantum chip can run 50 times faster than its predecessor" (IBM chip description). 24 qubits? 156 qubits? What happened to thousands of qubits - what's going on here?

Even Google's new Willow processor (Google's announcement) has only 105 qubits, yet headlines were going nuts, noting that it could perform calculations that would take a classical processor 10 septillion years and even reporting it as proof of the many-worlds interpretation (MWI) of quantum mechanics¹.

So it's clear that we're no longer focused (only) on qubit density. If you look at, e.g., IBM's Quantum Roadmap and their plans for supercomputing, you'll find instead an objective of increasing the number of quantum gates, modularizing the architecture, and improving error correction. And that is where Google did have its break-through: by reducing errors exponentially, they showed that through quantum error correction, quantum computers can be made fault-tolerant. That is, adding more qubits will no longer increase the error rate. That seems useful indeed.

Meanwhile, Microsoft is betting on their brand new Majorana 1 chip, which is based on a topological superconductor ("topoconductor") able to create and control Majorana fermions, bound into "Majorana zero modes" (MZMs). Microsoft views this approach as simplifying quantum error correction and is promising chips with one million qubits (although in this announcement, their breakthrough "Majorana 1" contains only eight qubits) in their effort to create a usable topological quantum computer.

PQC Threat Model

So where are we now with respect to the threat quantum computing poses to our classical encryption algorithms? What do we need to focus on, and when?

Not much has changed since last year: we continue to consider symmetric encryption (e.g., AES) and integrity (e.g., SHA-2) to be largely quantum safe. While we've previously noted that increasing key sizes should be sufficient, even AES-128 may still practically remain out of reach to feasibly break using Grover's algorithm in the near future -- see, e.g., this presentation^[archive]2, which notes some of the difficulties in parallelizing and error correction. But, as we've seen above, quantum error correction is improving, and AES-256 is a Good Idea^TM anyway, so don't stray from that.

What remains vulnerable are asymmetric encryption (e.g., RSA, ECDSA, ECDH) and digital signatures (e.g., RSA, ECDSA, ECDH). The largest threat then continues to be Harvest Now, Decrypt Later, since any cryptographically relevant quantum computer (CRQC) still remains the ever elusive 10 - 20 years in the future. For that reason, we currently, today, don't care all that much about digital signatures either: we use these to verify authenticity of the sites we are connecting to. An adversary with access to a CRQC in ten years still cannot impersonate a system I'm connecting to today.

We will need to move away from quantum-vulnerable signature algorihtms within that timeframe, however. NIST's current guidance^[archive] and plan here is to deprecate ECDSA, EdDSA, and RSA after 2030, and to disallow them altogether after 2035. That gives us just 10 years, so it really is high time for you to get your cryptographic inventory and an internal roadmap going. 10 years sounds like a long time, but I know how slowly most organizations move.

With asymmetric encryption being subject to Harvest Now, Decrypt Later, we are moving quite a bit faster and are now primarily focused on key exchange³, particularly within the context of TLS⁴.

NIST Standards

After a long time, NIST finally landed the first standardized post-quantum cryptography algorithms^[archive] in August of 2024:

• Public-Key Encryption / Key Encapsulation Mechanism:
  • FIPS-203: ML-KEM^[archive] (Module-Lattice based Key Encapsulation Mechanism) - formerly CRYSTALS-KYBER
• Digital Signatures:
  • FIPS-204: ML-DSA^[archive] (Module-Lattice based Digital Signature Algorithm) - formerly CRYSTALS-Dilithium
  • FIPS-205: SLH-DSA^[archive] (Stateless Hash-Based Digital Signature Algorithm) - based on SPHINCS+

(FIPS-206: FN-DSA (Fast Fourier lattice-based compact signatures over NTRU) is expected to be finalized in 2025.)

Hybrid Key Exchange in TLS 1.3

With these post-quantum cryptography algorithms now officially standardized, pure PQC implementations (e.g., ML-KEM Post-Quantum Key Agreement for TLS 1.3) are now in the works, and codepoints have been reserved by IANA (0x0200 (decimal 512) for MLKEM512, 0x0201 (decimal 513) for MLKEM768, and 0x0202 (decimal 514) for MLKEM1024)⁵.

However, the industry is still primarily focused on implementing a hybrid key exchange in TLS 1.3, combining a classical algorithm with a post-quantum algorithm, so that any compromise in the comparatively immature PQC implementations won't be fatal and you effectively fail over to the protections of the classical algorithm. I've summarized what the TLS handshake looks like for this in a separate blog post.

As of February 2025, this pretty much means using X25519MLKEM768, which is defined in this IETF draft (together with SecP256r1MLKEM768 and SecP384r1MLKEM1024), and is what browsers, libraries, and, e.g., CDNs are implementing. Offering multiple hybrid keyshares is tricky, because of the size of the PQC keys:

This becomes a problem, because right now there is no good way for a client to efficiently signal to the server which of several possible hybrid algorithms it prefers: advertizing the supported keygroups in the ClientHello without also providing the key shares means you incur multiple round trips negotiating; including multiple key shares balloons up the the ClientHello which can lead to fragmentation and performance issues⁶ or even a completely broken⁷ handshake.

On the other hand, clients will likely want to offer multiple hybrid key shares: since FIPS 140-2^[archive] (published in 2001) does not allow X25519 nor MLKEM, the hybrid X25519MLKEM768 is also non-compliant. A hybrid SecP384r1MLKEM1024, on the other hand would be compliant because NIST P-384 / secp384r1 is allowed per NIST SP 800-56Ar3^[archive], but browsers do not yet implement that. Once they do, servers may be lagging and so clients will want to offer both.

(On the other hand, NIST has recently said that it "intends to allow" hybrid constructs using a compliant algorithm, so X25519MLKEM768 should then be FIPS 140-2 compliant. As usual, interpreting these rules requires some advanced tea leaf reading skills...)

This problem goes away if you're aiming for compliance with FIPS 140-3^[archive] (published in 2019), but as you know, the industry -- especially the industry subject to these regulations -- moves very slowly. In the mean time, there are discussions around possibly using HTTPS/SVCB DNS records to signal supported key shares, but of course that requires sites to actually implement HTTPS/SVCB records, and from what I've seen, that adoption is severely lacking⁸.

Some sites may also choose to support clients' preference by letting them advertize multiple key groups and then taking the hit with a Hello Retry Request (HRR) as outlined by Amazon for some of their services.

PQC Implementations

Okay, let's take a look at where we stand as of February 2025:

Browsers

Prior to NIST's publication of ML-KEM as FIPS-203, the hybrid key exchange most widely being adopted was the experimental X25519Kyber768. This was available in at least Google Chrome as well as Mozilla Firefox, but both browsers quickly moved to X25519MLKEM768 soon after standardization. At the same time, and in part due to the above mentioned problem with supporting multiple hybrid key groups, they then deprecated X25519Kyber768. If you had just started adopting PQC and were working on implementing that, you quickly had to switch over to X25519MLKEM768 as well. Fortunately that's not a major change, but the speed with which browsers moved here did come as somewhat of a surprise: NIST published FIPS-203 on August 13th, 2024; Firefox included X25519MLKEM768 in 132.0 (October 29th, 2024), and Google shipped support for X25519MLKEM768 in Chrome 131 (stable on November 6th, 2024).

For both Chrome and Firefox, you still need to explicitly enable PQC, and the flags for those are somewhat unintuitive as a result of the rapid adoption: For Firefox, this is via about:config, security.tls.enable_kyber (which, despite the name, now enables X25519MLKEM768 because naming things); in Chrome (and Chromium based browsers), that's via chrome://flags/#enable-tls13-kyber and chrome://flags/#use-ml-kem. Here, #use-ml-kem chooses X25519MLKEM768, but it still requires you to also enable #enable-tls13-kyber despite the name, as that now basically functions as a "enable hybrid pqc key exchange (default to Kyber)" toggle.

As of 2025-02-17, Safari does not seem to support PQC.

You can verify that your browser uses X25519MLKEM768 by visiting https://pq.cloudflareresearch.com/.⁹

Libraries

Open Quantum Safe supports X25519MLKEM768 as well as the pure PQC algorithms. (Get it from pkgsrc! :-)

BoringSSL supports X25519MLKEM768 and is (as best as I know) what is being used by Google services / Google Chrome as well as by, e.g., Cloudflare. One would think that this should imply PQC capabilities in Google Cloud Platform (GCP), but I don't know if there's guidance on how to enable it in, e.g., Google Cloud Load Balancing.

WolfSSL supports pure PQC ML-KEM and ML-DSA since October 2024. I wasn't able to find whether it also supports hybrid X25519MLKEM768. This page lists a few hybrid "Kyber" groups, but the page is not dated.

OpenSSL (without OQS) noted in September of 2024 that they are planning to integrate PQC algorithms, likely based on OQS's oqs-provider, but did not provide a timeline. In January 2025, they then published a "Position and Plans on Private Key Formats for the ML-KEM and ML-DSA Post-quantum (PQ) Algorithms", which lead to some discussion on the IETF SPASM working group mailing list. It looks like it's still going to be a while before OpenSSL provides native PQC capabilities.

Microsoft SymCrypt notes support for both hybrid and pure PQC as of September 2024, with the addition of Leighton-Micali Signature Scheme (LMS) and ML-DSA in December of 2024. This should make PQC available via Azure, although I didn't find specific instructions on how to enable it in, e.g., Azure Load Balancer.

AWS Libcrypto announced in December 2024 that they now include ML-KEM in FIPS 140-3 mode, as well as hybrid key exchange in s2n-tls.

OpenJDK had tickets tracking the implementation of ML-KEM and ML-DSA; those tickets were closed in early February 2025. I don't know much about their release strategy, but I think that this will bring pure PQC to Java 24 in March 2025. I'm not aware of any hybrids being supported there.

Go 1.23 shipped with support for X25519Kyber768Draft00 in August of 2024; 1.24 ships with crypto/mlkem, implementing ML-KEM-768 and ML-KEM-1024; this page suggests that also enables X25519MLKEM768 by default (which would make sense).

Services

If you want to use PQC, you obviously need both sides of the connection to support it. For service providers that means either waiting for one of the libraries above to provide the support, or to implement your own. As a result, the current status is still a bit all over the map:

Cloudflare is already serving traffic from their edge to origins as well as from clients to their edge using X25519MLKEM768 (and sees about 33% adoption). (I don't know if this is enabled for their free tier only or also for all enterprise customers, nor whether their internal communications use PQC for a full end-to-end PQC connection from client to origin.)

F5 supports PQC in F5 NGINX Plus R33 since November 2024 by way of using OQS¹⁰ They also announced support for X25519Kyber768Draft00 in BIG-IP Next 20.3 on October 30th, 2024, although it seems unfortunate that they didn't switch directly to launch with X25519MLKEM768.

Facebook / Meta provided an update on post-quantum readiness in May 2024. It looks like they are using OQS underneath and added support for X25519MLKEM768 (alongside a custom "X25519MLKEM512_FB", presumably because IANA doesn't have a codepoint defined for X25519MLKEM512) to their fizz library in November 2024. I haven't seen any use of PQC on their public facing services.

AWS provided an updated roadmap in December 2024, but without specific dates. This is similar to Akamai, which, literally days before NIST published the standards, had outlined their plans to ship PQC from edge to origin (unfortunately, those timelines have slipped somewhat).

Other updates

In addition to the above, there are a couple of other interesting things going on that are worth mentioning:

• Within the IETF "Post-Quantum Use in Protocols" (PQUIP) working group, there's a draft in progress to help explain Post-Quantum Cryptography for Engineers.
• Latacora updated their Cryptographic Right Answers to include PQC advice.
• There's a feature request for SSLLabs as well as a feature request for caniuse.com to support PQC. (Hardenize supports X25519MLKEM768 already.)
• China's "Institute of Commercial Cryptography Standards" (ICCS) recently launched a global program to "call for proposals for next-generation public-key cryptographic algorithms (NGCC-PK), cryptographic hash algorithms (NGCC-CH) and block cipher algorithms". If this sounds redundant after NIST's competition and standardization, then (a) you're not alone, and (b) you are due for a "would you like your crypto to be backdoored by China or by the US" joke-not-joking-or-am-I-haha.

That's it

Well, that's my update and summary of the current state of post-quantum cryptography as of February 2025. I expect a lot more changes to be happening here this year, at least with respect to adoption and roll-out. Perhaps I should do a survey of who actually supports PQC on the edge next...

February 19th, 2025

Footnotes:

[1] The brief idea here is that quantum calculations are simply executed in parallel universes. I have a few problems with that approach, including that it seems to me to violate Occam's Razor by requiring an infinite number of infinitely complex, uhm, things (i.e., "universes"), or that by their very definition, they are non-interacting. There's also discussion around weather the MWI is still needed (based on this paper).^↩

[2] Linking to .gov resources has become unreliable; it's quite possible that content there disappears over night due to a long list of forbidden words -- a sentence I didn't think I'd be writing about the United States of America, but here we are. I'll include a link to the wonderful Internet Archive for those links.^↩

[3] We're going to be ignoring Quantum key distribution (QKD) for the time being, even though some vendors will pitch it to you. While interesting from a physics perspective, QKD mostly requires an already trusted channel, so doesn't really solve the key exchange bootstrapping problem.^↩

[4] Of course key exchange is relevant and important elsewhere, including, e.g., SSH. As I noted in my previous post, you can already enable, e.g., sntrup761x25519-sha512@openssh.com in recent OpenSSH versions.^↩

[5] These are the values you might see in, e.g., Wireshark or your raw tcpdump output; note that those are different from those assigned to the hybrid key groups (0x11eb (decimal 4587) for SecP256r1MLKEM768, 0x11ec (decimal 4588) for X25519MLKEM768, and 0x11ed (decimal 4589) for SecP384r1MLKEM1024).^↩

[6] See also this presentation by Cloudflare's Luke Valenta on the impact of PQ signatures on performance.^↩

[7] Just wait until middleboxes have to handle PQC algorithms. Middleboxes ruin everything. I fully expect them to be actively harmful in the adoption here once again.^↩

[8] Different browsers implement different subsets of the various HTTPS parameters, but notably Google Chrome appears to primarily be focused on Encrypted Client Hello here. Perhaps the fact that the proposal to advertize supported keyshares also comes from Google signals that Chrome will move to support that approach, but I'm once again ambivalent about having the industry's direction be largely set by Google.^↩

[9] If you want to check other tools, you can also make an HTTP GET request to ḣttps://pq.cloudflareresearch.com/cdn-cgi/trace. For example, if you have oqs-provider installed, you could check that curl(1) uses it correctly via:^↩

$ curl --curves X25519MLKEM768 https://pq.cloudflareresearch.com/cdn-cgi/trace
[...]
kex=X25519MLKEM768 

[10] If you're looking for instructions on how to set up nginx with OQS, check out these two HOWTO's I created for Linode with one of my interns: Debian, Ubuntu^↩

Links:

• Post-Quantum Certificates
• Post-Quantum Cryptography in January 2024
• TLS 1.3 Hybrid Key Exchange using X25519Kyber768 / ML-KEM
• Sites using PQC (March 2025)