Post-Quantum Cryptography in Mirantis Container Runtime

As part of an upcoming release, we're adding post‑quantum protection to the TLS connections Mirantis Container Runtime (MCR) relies on, starting with the key exchange, the part that matters most today. It happens automatically, your certificates don't change, your FIPS compliance remains intact, and the performance impact is small enough that most workloads won't notice it. This post explains what changed, why we started with key exchange, and what it means for you.

Why we're doing this now

Large-scale quantum computers don't exist yet, but the threat to today's encrypted traffic already does. An attacker can record encrypted data now, store it, and decrypt it years later once a cryptographically relevant quantum computer arrives. Anything with a long confidentiality lifetime (e.g., credentials, customer data, internal control-plane traffic) is exposed to this "harvest now, decrypt later"(HNDL) model today. The recording is happening now, even though the decryption isn't.Regulators have started putting dates on the transition. NIST's draft guidance (IR 8547) deprecates today's public-key algorithms (RSA, ECDSA, ECDH) after 2030 and disallows them after 2035, and NSA's CNSA 2.0 calls for quantum-resistant cryptography in new national-security systems from 2027. Enterprise crypto migrations tend to run for years, so customers in regulated and federal-adjacent markets are already asking for a post-quantum roadmap, increasingly as a procurement requirement rather than a future aspiration.

The first thing worth fixing isn't certificates or signatures, it's making the key exchange quantum-resistant, so attackers can’t use data intercepted today to decrypt your session keys in the future.

What we're introducing: Hybrid post-quantum key exchange

Mirantis Container Runtime uses mutual TLS authentication to protect communication between its components. That traffic carries sensitive material like credentials and secrets, exactly the kind of long-lived-confidentiality information the harvest-now-decrypt-later threat targets. We're moving it to a hybridpost-quantum key exchange built on the NIST-standardized ML-KEM algorithm (FIPS 203).

The TLS 1.3 handshake negotiates one of two hybrid groups:

• SecP256r1MLKEM768 (NIST P-256 ECDH + ML-KEM-768)

• SecP384r1MLKEM1024 (NIST P-384 ECDH + ML-KEM-1024)

Both are defined in the IETF'sdraft-ietf-tls-ecdhe-mlkem specification, which the TLS Working Group adopted in early 2025, and they're part of the same hybrid family now shipping across the wider ecosystem.

The word "hybrid" is the important part. The session key is derived from both the classical and the post-quantum exchange combined, so an attacker has to break both to recover it. A quantum computer can break the elliptic-curve half but not ML-KEM, and if ML-KEM ever turned out to have a classical weakness, the elliptic-curve half still holds.

How the handshake works

A hybrid handshake is still a single TLS 1.3 handshake. It does two things in the following order:

1. Key exchange first (the post-quantum part). Client and server exchange key shares for the hybrid group and derive a session key from the combined classical + ML-KEM secret.

2. Authentication next (your existing certificates). The server, and in mutual TLS the client, proves its identity with the existing classical certificate (ECDSA or RSA), validated against the CA exactly as before.

The reason this works cleanly is that TLS 1.3 derives its encryption keys from the key exchange first. That means the Certificate and CertificateVerify messages are already encrypted under the hybrid keys by the time they're sent, so certificate validation happens inside the quantum-safe channel rather than alongside it. You have the same certificates, validated the same way, wrapped in a key exchange that's now resistant to future decryption.

Your certificates don't change

A reasonable first question people tend to ask is whether this means re-issuing certificates or regenerating keys. It doesn't. The post-quantum protection applies to the key exchange, and in TLS 1.3 the key exchange usesephemeral keys generated fresh on every handshake. It never touches your long-term certificate or identity keys, so your existing PKI, CAs, and certificates stay exactly as they are. And because the change lives entirely in the key exchange, turning it on is a software update on both ends of a connection. There's nothing to coordinate across certificate authorities, trust stores, or key management, which is a large part of why the rollout is so undramatic.

That isn't a convenience we engineered. It falls out of where the quantum threat actually lands. Confidentiality is what's exposed to harvest-now-decrypt-later, and the key exchange is what protects it. Authentication is a separate problem on a separate timeline, which is the subject of the last section.

FIPS and quantum resistance, at the same time

This isn't a tradeoff between staying FIPS-compliant and getting post-quantum protection. Each hybrid group pairs a classical curve (P-256 or P-384) with ML-KEM, and the classical half is the FIPS-validated component, so turning on the hybrid exchange doesn't cost you any FIPS coverage. 

The post-quantum half is on its own validation track, and it's worth being precise about where it sits. Initially, ML-KEM provides the quantum resistance while its formal FIPS validation is still in progress. A connection is FIPS-compliant by virtue of its classical component and quantum-resistant by virtue of ML-KEM, even though the ML-KEM portion isn't yet inside the module's validated boundary. Once the validated module brings ML-KEM inside that boundary, the hybrid exchange is FIPS-validated end to end, with no change in behavior for anyone using it. Either way, you keep FIPS while gaining quantum resistance. The later milestone just brings the post-quantum half under the certificate as well.

What it costs

Not much, and only at connection time. We measured the hybrid key exchange adding roughly 0.4 ms to a connection's handshake, paid once when a connection is established, plus about 2 KB of extra handshake data. ML-KEM's keys and ciphertexts are larger than a classical curve's.

Once the connection is up, there's no difference at all. Bulk data is protected by the same AES-GCM cipher as before, because ML-KEM only touches the handshake and never the established channel. In our testing, classical and hybrid connections negotiated the same cipher and sustained the same throughput, around 1.2 GB/s, with any variation lost in run-to-run noise.

Since the cost is per connection rather than per byte, anything that reuses connections barely notices it. It would only become visible for a workload opening a very high rate of brand-new TLS connections without reuse, where it scales at roughly +0.4 ms and +2 KB per additional handshake.

(Note: Measured on a single AWS c6a.xlarge instance. Absolute timings vary by hardware, so treat them as representative of the relative cost rather than a guarantee for every CPU. What holds everywhere is that the cost is per-handshake, small, and zero once the channel is established.)

This is well within the range that the rest of the industry has already measured and deemed acceptable in production.

Rolling it out

Protection is negotiated automatically for TLS 1.3 connections between PQC-capable endpoints, with no configuration and no certificate changes. When a peer isn't PQC-aware yet, the handshake falls back to a classical curve. That has a few consequences:

• Mixed-version deployments keep working during an upgrade. Capable peers negotiate hybrid, others stay classical, and nothing breaks in between.

• Connections to not-yet-upgraded external services keep succeeding, becoming quantum-resistant on their own as those endpoints adopt the hybrid groups.

Once an environment becomes fully PQC-capable, operators can require the hybrid groups outright, refusing classical fallback to enforce post-quantum protection end to end.

One thing to note about availability: the FIPS-mode PQC described here is delivered in FIPS-mode MCR, where ML-KEM comes from the FIPS 140-3 cryptographic module that MCR links only in its FIPS builds. (Standard, non-FIPS MCR uses the default Go cryptographic stack and can still negotiate hybrid PQC via Go's standard library, but that path isn't FIPS mode and isn't supported for FIPS use). If you're already running MCR in FIPS mode, you're in the right place to receive this.

What this means for you

• Confidentiality is quantum-resistant today, against harvest-now-decrypt-later.

• Nothing to do on certificates or keys. Nothing to regenerate, re-issue, or reconfigure.

• No FIPS regression. You keep FIPS 140-3 compliance.

• Negligible cost. A fraction of a millisecond per connection, and no impact on throughput.

• Graceful rollout. It’s negotiated automatically, with classical fallback so mixed‑version deployments keep running.

A proven, widely adopted approach

MCR's hybrid key exchange is the same design already running across the internet at scale, so adopting it means joining a well‑established approach. 

Hybrid post-quantum key exchange already runs across the ecosystem. Chrome enables it by default, it's in Firefox and OpenSSL 3.5, in Apple's operating systems, and in cloud infrastructure like Cloudflare and AWS' s2n‑tls. Cloudflare reports that more than half of the human web traffic on its network already uses it.

MCR uses the same IETF‑standardized hybrid family these deployments rely on, so it interoperates cleanly with an approach that's already protecting a large and growing share of real‑world traffic.

What's next: post-quantum authentication

The other half of post-quantum cryptography is authentication: quantum-safe digital signatures and certificates, which NIST standardized as ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). These algorithms are already available in our toolchain as callable primitives, but we're treating authentication as a later phase deliberately, for two reasons:

1. Lower urgency. Signatures aren't exposed to harvest-now-decrypt-later the way confidentiality is. A forged signature only helps an attacker in real time, once a quantum computer already exists. There's nothing to capture today and exploit later, so the pressure that makes the key exchange urgent doesn't apply here.

2. Standardization and practicality. Post-quantum certificate and TLS-authentication formats are still being worked out across the industry, and the certificate authorities themselves haven't settled on a path for public PQC certificates yet. Post-quantum signatures are also large, with ML-DSA running to several kilobytes and SLH-DSA reaching tens of kilobytes. Those sizes have real handshake and performance implications worth measuring carefully before committing to them.

That ordering, quantum-safe key exchange first, authentication later, isn't a Mirantis quirk. It's the path the browsers, networks, and standards bodies driving this transition have all taken: secure confidentiality against the threat that's already live, then move on to authentication as the standards mature. Post-quantum key exchange already protects a large and growing share of real traffic, while post-quantum certificates remain essentially unused in production.

In short, we're delivering the protection that matters now: quantum-safe key exchange, FIPS-compliant, with no certificate changes and negligible overhead, while we track post‑quantum authentication for when the standards and the cost/benefit are ready.

To learn more about the upcoming release of Mirantis Container Runtime, reach out to your Account Executive or contact us.