Post-Quantum Cryptography
Mirantis Container Runtime (MCR) protects its TLS 1.3 connections with a post-quantum hybrid key exchange. MCR negotiates the exchange automatically, requires no changes to your certificates or keys, and preserves FIPS compliance.
Post-quantum protection applies to the TLS 1.3 connections MCR makes, including the Swarm control plane, the Engine API (when exposed over TLS), and outbound connections such as registry operations.
Threat model
An attacker can record encrypted traffic today and decrypt it later, once a cryptographically relevant quantum computer exists. This is the harvest now, decrypt later threat. A quantum- resistant TLS key exchange prevents an attacker from later recovering the session keys from traffic captured today.
Hybrid key exchange
MCR uses the NIST-standardized ML-KEM algorithm (FIPS 203) combined with a classical elliptic curve in a hybrid TLS 1.3 key exchange. Under FIPS, MCR negotiates one of two hybrid groups during the handshake:
Hybrid group |
Classical component |
Post-quantum component |
|---|---|---|
|
NIST P-256 (ECDH) |
ML-KEM-768 |
|
NIST P-384 (ECDH) |
ML-KEM-1024 |
MCR derives the session key from both components combined, so an
attacker must break both to recover it. The IETF
draft-ietf-tls-ecdhe-mlkem specification defines the groups.
Post-quantum protection applies only to the key exchange. In TLS 1.3, the key exchange uses ephemeral keys generated fresh on every handshake, so this protection does not touch long-term certificate or identity keys. Authentication continues to use your existing classical certificates (ECDSA or RSA), and your existing PKI, CAs, and certificates remain unchanged.
FIPS compliance
Each hybrid group pairs a FIPS-validated classical curve (P-256 or P-384) with ML-KEM. As a result, a connection is FIPS-compliant through its classical component and quantum-resistant through ML-KEM. Enabling the hybrid exchange does not affect FIPS coverage.
Note
The ML-KEM component currently sits outside the cryptographic module’s CMVP-validated boundary. The classical component carries FIPS compliance.
Configuration
By default, MCR requires no configuration: it negotiates ML-KEM automatically for any TLS 1.3 connection where both endpoints support the hybrid groups. Use the following environment variables to change this behavior.
CC_PQC_TLS_MODE
Set this variable in the daemon’s environment. The daemon reads it once at start and applies it to every TLS connection it makes.
Value |
Behavior |
|---|---|
|
MCR prefers hybrid groups, with classical fallback, so
connections to peers that are not post-quantum-capable
still succeed. Under FIPS, MCR offers the two hybrid groups
plus the classical curves |
|
Restricts negotiation to the hybrid groups
( |
|
Defers curve selection to the toolchain’s standard defaults. Intended for non-FIPS builds. See the warning below. |
Important
Do not set CC_PQC_TLS_MODE=off on a FIPS-mode daemon. The
standard default curve list leads with X25519-based groups that
FIPS does not permit, so every TLS handshake fails. On FIPS-mode
MCR, use migrate or strict.
Note
strict applies to all of the daemon’s connections,
including outbound connections to registries. Use it only
where every TLS peer the daemon reaches is post-quantum-capable;
otherwise those connections fail.
GODEBUG (non-FIPS builds)
These controls apply to non-FIPS builds only. On FIPS-mode MCR,
use CC_PQC_TLS_MODE instead; the GODEBUG curve controls
have no effect there.
Builds that use the standard Go cryptographic stack follow the standard Go controls:
Setting |
Behavior |
|---|---|
|
Disables ML-KEM and uses classical curves only. |
|
Drops the SecP hybrid groups and keeps |
Handshake performance
The post-quantum hybrid key exchange affects only the TLS handshake, not the established connection. Once MCR establishes a connection, throughput and latency are unchanged, because bulk data uses the same symmetric cipher as a classical connection.
The handshake itself carries a small, one-time overhead: slightly more computation and a modestly larger handshake message. This cost applies per connection, not per byte. It is negligible for workloads that reuse connections. It becomes noticeable only for workloads that open a high rate of new, non-reused TLS connections.
Availability
Post-quantum hybrid TLS is available in FIPS-mode MCR, beginning with MCR 29.6.1. Non-FIPS MCR can also negotiate the hybrid post-quantum key exchange, through the standard Go cryptographic stack. Mirantis does not support that path for FIPS use.