Post-Quantum Cryptography

Red Hat Enterprise Linux

The foundational cryptographic libraries and security baseline that enable post-quantum cryptography across the Red Hat portfolio — a feature-by-feature look at RHEL's PQC readiness, constraints, and roadmap.

For threat model definitions — Harvest Now, Decrypt Later and Quantum Forgery — and status definitions, see Post-Quantum Cryptography at Red Hat.

PQC overview

As the foundational operating system provider for enterprise infrastructure, Red Hat Enterprise Linux (RHEL) requires a comprehensive Post-Quantum Cryptography (PQC) strategy to protect core computing systems and the layered product portfolio that inherits its security baseline. This assessment covers the PQC roadmap, transitions, and threat landscape across active streams of RHEL.

RHEL serves as the central cryptographic heartbeat by providing standardized primitives through core native libraries, such as OpenSSL, GnuTLS, and NSS. As a result, its release schedules and policy management govern the security posture of downstream applications and supply chain components.

Starting with RHEL 10.1, the system-wide DEFAULT crypto policy automatically prefers and enforces quantum-resistant parameters using hybrid key exchange (for example, ML-KEM combined with classical curves) for standard TLS and SSH traffic. In RHEL 10.2, native OpenSSH 9.9 updates expand default hybrid parameters.

Scope

In-scope components

  • Core cryptographic libraries - OpenSSL 3.5+, GnuTLS, NSS.
  • Remote infrastructure access - OpenSSH 9.9.
  • Network security protocols - IPsec/libreswan, Kerberos.
  • Package and container image verification - Sequoia-PGP.
  • Identity management (IdM) and the Secure Boot chain.

Out-of-scope (already quantum-resistant)

  • Data encryption at rest (AES-256 via LUKS), message digests, and system hashing (SHA-256/384/512). These symmetric and hashing mechanisms are considered safe against quantum cryptanalysis using currently approved key strengths.

Constraints

Transport availability

Base core networks like TLS 1.3 and OpenSSH KEX are quantum-safe by default in RHEL 10.1 via hybrid ML-KEM key encapsulation. RHEL 9.7+ supports opt-in configuration using the system-wide cryptographic policy command DEFAULT:PQ.

FIPS mutual exclusivity

PQC algorithm primitives are not yet validated under the fips provider modules; final FIPS 140-3 validation from NIST is in progress. Consequently, running in strict FIPS compliance mode restricts operations to classical or specific certified hybrid combinations, for example, Secp256r1MLKEM768.

Language ecosystem blocks

Native language stacks like Go (crypto/x509) lag behind core OS C-libraries. Full ML-DSA signing integration won't mature until the Go 1.27 cycles.

Threat: Harvest Now, Decrypt Later (HNDL)

At-a-glance PQC status for each RHEL capability against passive data-harvesting attacks. Expand any capability below the table for notes and references.

Capability Status Min. version Risk
Remote access (SSH)
SSH key exchange		 PQ-Ready RHEL 10.1+ High
Remote access (SSH)
GSSAPI key exchange		 Under active development — —
Web & API access (TLS)
TLS key exchange		 PQ-Ready RHEL 10.1+ High
Web & API access (TLS)
FIPS compliance		 Under active development — —
Network-layer tunnels (IPsec)
IKEv2 key exchange		 PQ-Capable RHEL 10.2 High
Network-layer tunnels (IPsec)
IKEv2 re-keying		 Under active development — High
Data storage (LUKS) PQ-Ready All RHEL versions None

Notes & references

▸ Remote access (SSH) — SSH key exchange

Hybrid key exchange is default and preferred in SSH connections. Algorithm: ML-KEM + x25519. Without it, sessions could be at risk of HNDL attacks and decrypted retroactively once a CRQC (cryptographically relevant quantum computer) is available. Customers running custom libssh-based servers can protect against HNDL by upgrading to libssh 0.12.0 (the SSH C library).

Advancing post-quantum capabilities of SSH in Red Hat Enterprise Linux

▸ Remote access (SSH) — GSSAPI key exchange

Red Hat is working on standardizing GSSAPI key exchange with hybrid PQC methods for implementation in OpenSSH and libssh. When finalized, adopting this will make Kerberos authentication in SSH quantum-safe.

GSS-API Key Exchange with hybrid ML-KEM

▸ Web & API access (TLS) — TLS key exchange

Hybrid key exchange is default and preferred in TLS 1.3 connections. Algorithm: x25519 + ML-KEM-768. Encrypted transport traffic is otherwise prone to continuous harvesting for passive decryption in the future. Applications that use OpenSSL, GnuTLS, NSS, or Go have PQ key exchange enabled by default — the system automatically defaults to hybrid key exchange.

What's new in post-quantum cryptography in RHEL 10.1

▸ Web & API access (TLS) — FIPS compliance

Red Hat is in the process of certifying newer builds of our cryptographic libraries, including PQC. Customers that need strict compliance must currently choose between FIPS compliance and PQC.

▸ Network-layer tunnels (IPsec) — IKEv2 key exchange

Encrypted transport traffic is prone to continuous harvesting for passive decryption in the future. Only the initial handshake uses ML-KEM — there is no support for PQ re-keying in RHEL yet.

▸ Network-layer tunnels (IPsec) — IKEv2 re-keying

Persistent protection with full re-keying support using PQC is currently under development for a future release.

▸ Data storage (LUKS)

Symmetric encryption and hashing standards are structurally safe from quantum attacks. Available across all versions of RHEL.

Threat: Quantum Forgery

At-a-glance PQC status for each RHEL capability against signature-forgery attacks. Expand any capability below the table for notes and references.

Capability Status Min. version Risk
Remote access (SSH)
Authentication		 Under active development — High
Web & API access (TLS)
Authentication		 PQ-Capable RHEL 10.1+ High
Network-layer tunnels (IPsec)
Authentication		 Under active development — High
Package signing (RPM) PQ-Ready RHEL 10.1+ Critical
Identity & authentication (IdM)
Kerberos		 Under active development — High
Secure boot chain
UEFI firmware, shim, GRUB2, kernel		 Under active development — Critical
Container image signing
Podman		 PQ-Capable RHEL 10.2 High

Notes & references

▸ Remote access (SSH) — Authentication

Adversaries could forge signatures with a CRQC. Usage of ML-DSA in SSH is being discussed at the IETF. Implementing these would allow SSH clients and hosts to authenticate with PQ public keys, securing against quantum attacks.

ML-DSA Public Key Algorithms for the Secure Shell (SSH) Protocol
SSH Support of ML-DSA
Advancing post-quantum capabilities of SSH in Red Hat Enterprise Linux

▸ Web & API access (TLS) — Authentication

Adversaries could forge signatures with a CRQC. OpenSSL 3.5+, GnuTLS, and NSS support signatures and TLS certificates with ML-DSA, but no public CA currently offers PQC. Private CAs or self-signed certs can be created with ML-DSA and used, however.

What's new in post-quantum cryptography in RHEL 10.1
Post-quantum cryptography in Red Hat Enterprise Linux 10

▸ Network-layer tunnels (IPsec) — Authentication

Adversaries could forge signatures with a CRQC. Authentication with PQC in IKEv2 is in active development at the IETF.

Signature Authentication in IKEv2 using PQC
Hybrid Post-Quantum and Traditional Authentication for IKEv2

▸ Package signing (RPM)

RPM packages are signed with a hybrid ML-DSA-87 + Ed448 key, and also with RSA for backwards compatibility during transition. Adversaries with a CRQC could otherwise forge signatures to sign malicious software updates that systems trust as authentic Red Hat assets. RPM signing uses Sequoia-PGP tools, in the RPMv6 format.

Signing RPM packages using quantum-resistant cryptography | Red Hat Developer
What's new in post-quantum cryptography in RHEL 10.1
RFC 9580: OpenPGP

▸ Identity & authentication (IdM) — Kerberos

Attackers can forge digital signature credentials to masquerade as high-level cluster or server admins. If you deploy IdM on RHEL 10, your directory replication and admin traffic are already protected against HNDL via ML-KEM TLS/SSH wrappers. Direct PQ token and ticket-signing mechanisms within the Kerberos protocol itself are undergoing upstream standardization at the IETF.

Post-quantum Key Encapsulation with ML-KEM in PKINIT for Kerberos

▸ Secure boot chain

Quantum Forgery allows bypass of the hardware-to-software root of trust, permitting bootloader and kernel module tampering. RHEL 10.2 enabled in image mode (bootc), sealed images (Technology Preview) bring customer-controlled security, offering end-to-end cryptographic integrity protection for the OS — organizations can use their own secure boot keys to sign images at build time and configure target systems to trust only internally certified images.

Red Hat Enterprise Linux 10.2 and 9.8 are here: The intelligent evolution of enterprise Linux

▸ Container image signing — Podman

An attacker could sign a malicious, backdoor-laden container image and push it to your registry. In RHEL 10.2, the container-tools supported cryptographic back-end shifted from traditional OpenPGP to the Sequoia-PGP engine to support PQC-compliant image operations.

Cryptographic policy enforcement

In RHEL 10.1+ the DEFAULT cryptographic policy enables and prefers PQC in the core libraries. This policy is a specific configuration that layers PQC capabilities directly on top of the OS’s standard, production-ready cryptographic libraries. 

This policy primarily targets HNDL attacks by enforcing hybrid key encapsulation mechanisms. TLS 1.3 or SSH will automatically attempt to negotiate x25591 + ML-KEM-768. Additionally, this policy enables system-wide support for ML-DSA, which permits applications using OpenSSL, GnuTLS, NSS or the Go runtime to process and verify PQ certificates and digital signatures.

Cryptographic libraries

OpenSSL & GnuTLS

Fully support hybrid TLS 1.3 handshakes.

NSS

Fully optimized for PQ key exchange and certificate processing.

The Go toolset

The RHEL-packaged Go language runtime includes native, out-of-the-box support for negotiating PQC TLS key exchange.