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

In May 2025, Red Hat Enterprise Linux 10 (RHEL) shipped with the first steps toward post-quantum cryptography (PQC) to protect against attacks by quantum computers, which will make attacks on existing classic cryptographic algorithms such as RSA and elliptic curves feasible. Cryptographically relevant quantum computers (CRQC) are still not known to exist, but that does not mean the risk is zero. For example, "harvest now, decrypt later" attacks do not need a quantum computer now, one only needs to become available before the stored encrypted data loses its value, and depending on the transferred data, decades might pass before that happens.

To prepare for a quantum future, RHEL 10.1 improves defenses against such “harvest now, decrypt later” attacks and introduces post-quantum signatures for its packages.

The next section covers changes to PQC in Transport Layer Security (TLS), followed by a section explaining a change in the default cryptography policies of RHEL. Did you know RHEL is the first major Linux distribution to sign its packages with hybrid post-quantum keys?

The third section covers the details of these changes, before finishing with recommended next steps for users and third-party software vendors.

Post-quantum cryptography in TLS

TLS can use post-quantum cryptography in two places: Key exchange, where it protects against "harvest now, decrypt later" attacks, and signatures, preventing machine-in-the-middle attacks that use quantum computers. With the release of RHEL 10.1, applications that use OpenSSL, GnuTLS, NSS, or the Go programming language have support for post-quantum key exchange enabled by default.

The OpenSSL, GnuTLS, and NSS cryptography libraries additionally support signatures and TLS certificates with Module-Lattice-Based Digital Signature Algorithm (ML-DSA), a NIST-standardized PQC algorithm. Note that no public Certificate Authorities (CAs) currently offer post-quantum cryptography, but private CAs or self-signed certificates can be created with ML-DSA today.

In RHEL 10.0, this functionality was released as technology preview due to the quickly evolving nature of standards and implementations. This is now changing: post-quantum cryptography with Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) and ML-DSA in TLS is generally available and fully supported in Go, OpenSSL, GnuTLS and NSS.

In the lead-up to RHEL 10.1, Red Hat developers have run a product-wide testing effort of PQC key exchange and PQC certificates. This helped identify several issues, which the package maintainers fixed in upstream open source projects and downstream in RHEL. We encourage you to start testing hybrid PQC key exchange in your TLS deployments today, and make plans for dual classic/PQC TLS certificate servers (see “Creating a post-quantum TLS certificate”).

PQC by DEFAULT policy

Cryptography settings on RHEL are managed using system-wide cryptographic policies, with DEFAULTbeing the standard policy. In RHEL 10.1, this policy has changed to enable and prefer post-quantum cryptography by default. This means TLS and SSH connections from and to RHEL 10.1 or later will automatically use post-quantum key exchange where available. These 2 protocols are widely used and likely account for the majority of encrypted data transfers, making this a significant increase in security posture.

Applications on RHEL 9.7 based on OpenSSL or NSS can also use PQC in TLS if the system-wide cryptographic policy module “PQ” is enabled using sudo update-crypto-policies --set DEFAULT:PQ.

To verify the policy your system uses, run update-crypto-policies --show.

Package updates with post-quantum signatures

Finally, Red Hat developers have been working to introduce protections against quantum computer-based attacks for our software distribution paths. This is important because package updates through these paths will be how Red Hat delivers future improvements in the post-quantum transition.

Red Hat Enterprise Linux 10 uses the Sequoia-PGP implementation of OpenPGP to verify package signatures. A specification to use PQC in OpenPGP is in its final stages, and Red Hat has contributed funding to its implementation in Sequoia-PGP, which is now available as a pre-release. Some operating environments face regulatory requirements for PQC software signing on short timescales, so after thorough testing, RHEL 10.1 now includes this implementation.

In the same project, the sq-cryptoki and sq tools gained support for accessing post-quantum keys through PKCS#11. This enables integration with hardware security modules. Red Hat has modernized its signing infrastructure, created a post-quantum signing key that uses a hybrid of ML-DSA-87 and Ed448, and has started signing its RPM packages with this key. RHEL is the first and currently only major Linux distribution to achieve this milestone.

The first post-quantum signed package was ipmitool-1.8.19-10.el10_1 in RHBA-2025:23156:

# dnf download ipmitool
ipmitool-1.8.19-10.el10_1.aarch64.rpm                                                                                                                                                                           
# rpm -Kv ipmitool-1.8.19-10.el10_1.aarch64.rpm | head -3
ipmitool-1.8.19-10.el10_1.aarch64.rpm:
    Header V6 ML-DSA-87+Ed448/SHA512 Signature, key ID 05707a62: OK
    Header V4 RSA/SHA256 Signature, key ID fd431d51: OK

Note that this package is also still signed by our RSA key. Systems that understand the RPM 6 header format and OpenPGP v6 signatures will verify both the RSA and PQC signatures. Older systems will only validate the classic RSA signature.

Conclusion

Red Hat has made major steps in its post-quantum transition to prepare our customers for coming risks and regulatory requirements. TLS with hybrid ML-KEM key exchange is no longer in technology preview and can mitigate “harvest now, decrypt later” attacks today. Support for ML-DSA certificates and signatures in RHEL’s core cryptography libraries OpenSSL, GnuTLS, and NSS is also generally available now.

Aligning with recent industry pushes (e.g., the European Cyber Resilience Act) for secure by default, the standard configuration changed to enable and prefer post-quantum algorithms in TLS and SSH. More protocols will follow in the future. We encourage all our users to roll out PQC key exchange, and test dual classic/PQC TLS certificate setups with their TLS servers. You may also want to learn how to prepare your organization for the quantum future.

Finally, RHEL is the first major distribution to add hybrid post-quantum signatures to its packages. For our partners, my colleague Jakub Jelen has documented how to sign RPM packages with post-quantum keys. Integration with Hardware Security Modules through PKCS#11 3.2 is possible today for RPM signing—our support and engineering teams can help you get started with that.

Go currently only supports ML-KEM as of 1.24. ML-DSA support is anticipated in a future release.