Tomáš Vávra walks the room through post-quantum cryptography in the OpenSSL Library — ML-KEM, ML-DSA, SLH-DSA, three FIPS standards, fifteen interop providers, and the one command that turns it all into a working TLS session.
The question in cryptography this decade is no longer whether the post-quantum algorithms are coming — NIST finalised them, the browsers shipped them, the governments signed the memos. The question is whether the libraries you already depend on can actually do the work. On Wednesday morning, for forty-five minutes in Salon 1, Tomáš Vávra's answer was: yes, and here is the command line.
It was a talk that started with a tongue-in-cheek self-portrait and ended with a shared secret. In between: three NIST standards, the three OpenSSL releases that shipped them, a speed table that tells you what a lattice actually costs, and the results of an interop hackathon that answers the quiet question behind every PQC rollout — will it work with the other guys?
The session was chaired by Tomáš Mráz, CTO of the OpenSSL Foundation, who introduced — as the symmetry of the project demands — Tomáš Vávra, engineering manager of the OpenSSL Corporation. Two Tomášes, one PQ track. The moderator handed off; the engineering manager opened the way engineering managers open these things, which is with a personality-test result. “I'm an Eagle / Peacock,” he said, and left the audience to translate that into whichever framework they grew up with.
The self-deprecating continuous goal, delivered on slide four: “switching open-source development into agile development — which is fun, especially when you don't have the resources.” Anyone who has tried to land a post-quantum algorithm into a library that ships to every Linux distribution on earth recognises this as, technically, a mission statement.
Before PQC, there was infrastructure for PQC. Tomáš walked through three releases in order — 3.5, 3.6, 4.0 — because the work that landed in 4.0 last week is only interesting if you understand the year of plumbing that preceded it.
EVP_SKEY promoted to a first-class symmetric handle, configutl helper, NIST security-level categories on PKEY objects, FIPS provider upgraded so KDF & KEXCH understand opaque keys. C99 now required; ANSI-C support dropped.curveSM2MLKEM768 TLS group, cSHAKE (SP 800-185), ML-DSA-µ external-digest variant, TLS 1.2 FFDHE negotiated groups, deferred FIPS tests, opaque ASN1_STRING, and the legacy sweep Tim read into the record on Tuesday — SSLv3 gone, ENGINE API gone, SSLv2 hello gone.Read top-to-bottom, the sequence is legible: ship the algorithms, harden the FIPS path, remove the legacy that would have blocked the next decade. Not one of those three steps is optional. Do any of them out of order and the rollout stops.
The “why” slide arrived four minutes in, and it was short by design. Tomáš's bullet list distilled into a single sentence the project could have stuck on the cover of the release: NIST finalised FIPS 203, 204 and 205 earlier than expected; most browser vendors have already switched; more than 80% of the traffic is already using ML-KEM; and OpenSSL's users must not be left behind. That last clause is the one Tomáš kept circling back to. The mission, he said plainly, is “security and privacy for everyone” — and everyone now has to include a world in which large quantum computers exist.
Governments, customers, and the industry as a whole are looking to upgrade to cryptographic systems that can withstand post-quantum cryptanalysis — inside a 5-to-20-year window.
Artefacts that need to stay signed for a long time — firmware among them — need signature algorithms that will still mean something in the year they are verified, not the year they were issued.
The highest priority is to replace Diffie-Hellman in key agreement, because a record-now-decrypt-later adversary only has to record once. That happens today.
More than 80% of the traffic is already using ML-KEM. We don't want our users left behind.Tomáš Vávra · on why OpenSSL added PQC · 04:33 into the session
Slide eleven put five families of post-quantum approach on a single board — lattice, hash-based, code-based, multivariate, isogeny — which is the polite version of the story. The blunt version is: NIST standardised three of them, and those three are what OpenSSL 3.5 shipped. Lattice for the fast cases. Hash-based as the conservative fallback.
The FIPS 140-3 provider shipped in 3.5 supports all variants of ML-KEM, and the pure (non-Hash) variants of ML-DSA and SLH-DSA. The Hash variants — HashML-DSA and HashSLH-DSA — are on the list for upcoming releases. This is the detail buried at the bottom of slide seventeen that a procurement officer will want to photograph.
Slide thirteen was the kind of slide that gets quiet attention: the output of openssl speed -kem-algorithms, in a simple table. The headline is a sentence most of the room had been waiting a decade to be able to say out loud: ML-KEM-768 is within shouting distance of ECP-256 on key generation — and it is materially faster on encapsulation and decapsulation than every classical curve listed.
Note the shape of the RSA-2048 row: encaps is fast, keygen and decaps are orders of magnitude slower. That asymmetry is why nobody generates RSA keypairs on the hot path. ML-KEM flattens it — keygen, encaps, and decaps all land in the same bracket, within a factor of two of each other. From a performance standpoint, lattice KEMs are not a concession. They are a simplification.
The point of the slide is not to win an argument. It is to take the “PQC is slow” objection off the table before it gets raised. On this particular CPU, with this particular build, the objection is approximately untrue. Hand-tuning per platform changes the numbers. The shape of the answer does not.
Slide twenty was the reason the room leaned in. The project's long-held conviction is that the CLI is the interface most users actually meet, and so the demonstration started there. An ML-DSA-65 root CA, entirely from openssl(1), no plugin required, no OQS provider, no “experimental” branch.
After that: an ML-DSA-65 end-entity certificate, an ML-KEM-768 key pair whose certificate is signed by the ML-DSA CA, and a CMS detached signature over a Fedora kernel binary. All ordinary openssl subcommands. Nothing custom. And then — the shot of the morning — the round-trip TLS session:
One side sets up an ML-DSA-signed cert. The other side reads it. The handshake ends in X25519MLKEM768. Not a demo build. Not a branch. Just openssl.Reading the demo output · s_server ↔ s_client · Salon 1–3
A lab result is not a network. To close the “yes, but against another implementation” loop, slide twenty-six connected the new CLI to Open Quantum Safe's public test endpoints. Three ports, three ML-DSA parameter sizes, one HTTP response:
The final third of the talk was the part that does not appear in release notes. Interoperability — the question of whether one implementation's certificates and keys are legible to another's — is the thing a lab result cannot answer, and which the IETF PQC Hackathon exists specifically to measure. Round 5 dropped on 15 April, one day after 4.0 shipped. In Tomáš's words: “it is a volunteer activity. Fifteen companies. Automated. If your company wants to participate, have a look at the link.”
Tomáš spent a slide not on a comparison-as-competition, but on a comparison-as-complement. The two projects reached R5 with different strengths. You can read that as rivalry or you can read it as a working division of labour.
X25519MLKEM768.Read as a map of scope, not a scoreboard. Each vendor chose what to submit to R5.
Post-quantum is not a finished subject. Tomáš closed the interop section with a slide that the project — openly — has on its list. Naming the gap is more useful than pretending it isn't there.
OpenSSL 3.5 has no R5 entries as a verifier for composite certificates (e.g. MLDSA44+RSA2048). Only Bouncy Castle and composite-ref-impl parse them today. On the roadmap.
Consistent 0/1 on ML-DSA private-key formats, but — as Tomáš put it — “they do composite, and they don't do other things. They know what they are doing.” Read the R5 table as a map of what each vendor chose to submit, not a scorecard.
Only seventhsense.ai has submitted seed and expanded-key format artifacts for SLH-DSA. Broader participation needed to validate cross-vendor support.
TLS authentication with PQC X.509 certificate chains is still pending RFC finalisation — draft-ietf-lamps-dilithium-certificates and the composite-sigs RFCs.
Composite algorithm OIDs have no permanent IANA assignment yet. Implementations use temporary OIDs, creating forward-compatibility risk for artefacts shipped today.
Once it is standardized, we will quickly add it. We are working on it — it is just not in the library yet.Tomáš Vávra · on composite certificates · 27:28 into the session
Wednesday was our last day exhibiting — back-to-back meetings with clients, partners, cryptographers, senior leaders from large businesses, government representatives. Friends, too. Thursday we are still here, no booth this time, just the floor. If you are still around, find us. OpenSSL Corporation would like to know what you do with the OpenSSL Library, and how we can help.