Post-quantum cryptography in Red Hat Enterprise Linux 10

In their article on post-quantum cryptography, Emily Fox and Simo Sorce explained how Red Hat is integrating post-quantum cryptography (PQC) into our products. PQC protects confidentiality, integrity and authenticity of communication and data against quantum computers, which will make attacks on existing classic cryptographic algorithms such as RSA and elliptic curves feasible. Cryptographically relevant quantum computers (CRQCs) are not known to exist yet, but continued advances in research point to a future risk of successful attacks. While the migration to algorithms resistant against such quantum attacks will take years, the risk today is that state-level actors are likely already storing encrypted communication now to gain access when quantum computers are available. This is called "harvest now, decrypt later", or "steal/store now, decrypt later". The transition to PQC needs to start now.

In this article, I outline the implementations of PQC available in Red Hat Enterprise Linux 10.0 at the time of its release, and how to use them. The first section covers key exchange where PQC protects confidentiality of communication against “harvest now, decrypt later” attacks. The second section explains which PQC signature algorithms are available in Red Hat Enterprise Linux 10.0 to protect data integrity and authenticity.

All PQC algorithms in Red Hat Enterprise Linux 10.0 are available as Technology Preview due to the quickly evolving nature of the relevant standards and implementations. We anticipate providing a staggered roll-out for General Availability for PQC as standards become finalized (TLS, SSH, Kerberos, and so on) and protocol implementation is completed (so several will remain Technology Preview while this occurs.)

Post-quantum key exchange

Key exchange algorithms establish a shared secret between two parties. This shared secret can then be used for higher performance and quantum-resistant symmetric cryptography, which in turn protects confidentiality. PQ key exchange defends against “harvest now, decrypt later” attacks. These attacks work by passively snooping on and storing encrypted communication (for example, TLS connections) now and decrypting them in a few years when a suitable quantum computer is available. Information obtained in this fashion such as long-term passwords, secret keys, or medical records can still be useful to attackers even years later.

For key exchange, the US National Institute of Standards and Technology (NIST) has standardized a key encapsulation mechanism based on the Learning with Errors problem called ML-KEM. It is available in the three variants ML-KEM-512, ML-KEM-768, and ML-KEM-1024 targeting the 128, 192, and 256 bit security levels. In RHEL 10.0, ML-KEM is available for Transport Layer Security (TLS) connections in OpenSSL, GnuTLS and NSS, and for SSH connections in OpenSSH. A future version of Red Hat Enterprise Linux 10 will also use them for SSH connections with libssh.

To enable the use of PQC system-wide, install the crypto-policies-pq-preview and crypto-policies-scripts packages and switch the system-wide cryptographic policy to enable the TEST-PQ module:

# dnf install crypto-policies-pq-preview crypto-policies-scripts
# update-crypto-policies --set DEFAULT:TEST-PQ

Note that the package and system-wide cryptographic policy name are subject to change when post-quantum cryptography exits the technology preview state.

Post-quantum key exchange in TLS

For TLS connections, a draft for hybrid key agreement in TLS 1.3 specifies three combinations. The following table lists them along with their implementation state in Red Hat Enterprise Linux 10.0 by library. Note that only connections with TLS 1.3 are able to use these.

• Algorithm: X25519MLKEM768
  • Classic part: X25519
  • PQC part: ML-KEM 768
  • Compatibility: OpenSSL, GnuTLS, NSS
• Algorithm: SecP256r1MLKEM768
  • Classic part: ECDH secp256r1
  • PQC part: ML-KEM 768
  • Compatibility: OpenSSL, GnuTLS, NSS
• Algorithm: SecP384r1MLKEM1024
  • Classic part: ECDH secp384r1
  • PQC part: ML-KEM 1024
  • Compatibility: OpenSSL, GnuTLS

Support for SecP384r1MLKEM1024 in NSS will come in a later version. Red Hat is also closely monitoring the standardization process of non-hybrid post-quantum key exchange methods in TLS.

Post-quantum key exchange in SSH

In the Secure Shell (SSH) protocol, four different key exchange mechanisms involving PQC are undergoing specification by the Secure Shell Maintenance workgroup at the Internet Engineering Task Force (IETF). Three of them use ML-KEM and one employs streamlined NTRU Prime, a different cryptographic algorithm also based on lattice math, but not standardized or approved by NIST.

OpenSSH in Red Hat Enterprise Linux 10.0 supports the mlkem768x25519-sha256 and sntrup761x25519-sha512 key exchange algorithms which combine ML-KEM-768 or streamlined NTRU Prime with the X25519 classic algorithm. Note that the TEST-PQ crypto-policy module in Red Hat Enterprise Linux 10.0 only enables ML-KEM. It does not enable streamlined NTRU Prime, but it is available and can be manually configured. A version of libssh (for example used by Ansible) that supports ML-KEM is not available in Red Hat Enterprise Linux 10.0 yet, but future versions are going to include support.

Post-quantum signatures

Cryptographic signatures attest that a message or document came from a specific sender and was not modified in flight. Common uses of cryptographic signatures include signatures on software packages or the public key infrastructure that authenticates TLS certificates. Attacks on signatures typically involve an active Machine-in-the-Middle (MitM), for example, during a TLS handshake or a package download and are therefore more complicated than the “harvest now, decrypt later” type addressed by post-quantum key exchange algorithms.

NIST has standardized two post-quantum signature schemes: ML-DSA, based on the same learning with errors problem used by ML-KEM, and SLH-DSA based on cryptographic hash functions. ML-DSA is available in three parameter sets, ML-DSA-44, ML-DSA-65, and ML-DSA-87, where an attack should require computational resources comparable to attacking AES-128, AES-192, or AES-256, otherwise referred to as security categories 1, 3, and 5. SLH-DSA is available in twelve different variants outlined in the following table.

Algorithm

Security category

Signature size

SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s

1

7856 B

SLH-DSA-SHA2-128f, SLH-DSA-SHAKE-128f

1

17088 B

SLH-DSA-SHA2-192s, SLH-DSA-SHAKE-192s

3

16224 B

SLH-DSA-SHA2-192f, SLH-DSA-SHAKE-192f

3

35664 B

SLH-DSA-SHA2-256s, SLH-DSA-SHAKE-256s

5

29792 B

SLH-DSA-SHA2-256f, SLH-DSA-SHAKE-256f

5

49856 B

All choices are available using the SHA-2 family of hash functions, or the SHAKE256 expandable output function from the SHA-3 family of hashes. Finally, the variants differ in whether they are small and fast to verify, but slow to generate (with the s suffix), or fast to generate, but large and slower to verify (f).

SLH-DSA uses functions that have seen decades of cryptanalysis, whereas ML-DSA’s use of lattices is still relatively modern. Many protocols are therefore considering ML-DSA in a hybrid combination with an existing classic algorithm such as EdDSA or ECDSA. ML-DSA signatures are fast and small. In comparison, SLH-DSA signatures take orders of magnitude more processing time to generate and verify and are considerably larger.

For now, only ML-DSA is available in Red Hat Enterprise Linux 10.0.

Signature primitives

To use ML-DSA through OpenSSL, install the oqsprovider package:

# dnf install oqsprovider

Afterwards, OpenSSL can generate keys, sign messages and verify signatures and create X.509 certificates with ML-DSA:

$ openssl genpkey -algorithm mldsa65 -out mldsa-privatekey.pem
$ openssl pkey -in mldsa-privatekey.pem -pubout -out mldsa-publickey.pem
$ openssl dgst -sign mldsa-privatekey.pem -out signature message
$ openssl dgst -verify mldsa-publickey.pem -signature signature message
Verified OK

This functionality is of course also available using OpenSSL’s C API. For example, the following snippet generates an ML-DSA-65 key in pkey:

EVP_PKEY_CTX *ctx = NULL;
EVP_PKEY *pkey = NULL;
if ((ctx = EVP_PKEY_CTX_new_from_name(NULL, "mldsa65", NULL)) == NULL)
    goto err;
if (EVP_PKEY_keygen_init(ctx) <= 0)
    goto err;
if (EVP_PKEY_keygen(ctx, &pkey) <= 0)
    goto err;
EVP_PKEY_CTX_free(ctx);
return pkey;
err:
    ERR_print_errors_fp(stderr);
    EVP_PKEY_CTX_free(ctx);
    EVP_PKEY_free(pkey);
    return NULL;

Using an ML-DSA pkey to sign a message uses the same OpenSSL functions as a classic signature operation.

Signatures in TLS

Signature algorithms are also used in TLS. A typical TLS connection only performs one key exchange and provides a negotiation mechanism for supported key exchange algorithms. Migration of signatures in TLS is much harder in comparison. For example, common TLS connections contain up to six signatures at the moment:

• A signature over the entire TLS handshake in the CertificateVerify message (see RFC 8446, section 4.4.3)
• Signatures along the TLS certificate chain to the root certificate authority (CA), one per level; chains commonly have three levels with a self-signature at the top that is not verified, adding two signatures
• Signed certificate timestamps (SCTs) in the TLS certificate to enable Certificate Transparency, typically two SCTs per connection
• If the issuing CA uses the Online Certificate Status Protocol (OSCP), a signed answer from an OCSP server, or a stapled OSCP response in a TLS CertificateStatus message

The X.509 series of standards govern the format of TLS certificates. To use ML-DSA, combinations of ML-DSA and classic algorithms, or SLH-DSA in X.509 certificates, the IETF LAMPS working group is working on three RFCs:

• draft-ietf-lamps-dilithium-certificates for pure ML-DSA,
• draft-ietf-lamps-x509-slhdsa for pure SLH-DSA, and
• draft-ietf-lamps-pq-composite-sigs for combinations of ML-DSA with RSA, ECDSA, or EdDSA

Three additional draft documents specify use of these post-quantum certificates in TLS:

• draft-ietf-tls-mldsa for pure ML-DSA
• draft-reddy-tls-slhdsa for pure SLH-DSA
• draft-reddy-tls-composite-mldsa for combinations of ML-DSA with RSA, ECDSA, or EdDSA

Of these, Red Hat Enterprise Linux 10.0 only supports pure ML-DSA in OpenSSL if the oqsprovider package is installed. This support is in Technology Preview state because standardization is not yet finalized. Red Hat’s engineers are following and participating in discussions at the IETF. Additional methods will appear in later versions of Red Hat Enterprise Linux 10.

Creating a post-quantum TLS certificate

At the moment, no public CAs support post-quantum signatures. A local CA or local self-signed certificates can be created with ML-DSA signatures, though:

$ openssl req \
    -x509 \
    -newkey mldsa65 \
    -keyout localhost-mldsa.key \
    -subj /CN=localhost \
    -addext subjectAltName=DNS:localhost \
    -days 30 \
    -nodes \
    -out localhost-mldsa.crt

When deploying post-quantum X.509 certificates, existing clients that only support classic algorithms can gracefully fall back to a certificate without post-quantum cryptography if the TLS server is configured with two certificates. The server chooses a certificate based on the client’s signature_algorithms or signature_algorithms_cert extensions in the ClientHello message.

Apache httpd and Nginx enable this behavior by repeating the SSLCertificateFile and SSLCertificateKeyFile options (for Apache httpd) or ssl_certificate and ssl_certificate_key options (for Nginx), once for the classic certificate and key and once with the ML-DSA key pair. OpenSSL’s s_server utility also supports such setups but offers the two options -cert/-dcert and -key/-dkey instead.

With a set of certificates and a system set to the DEFAULT:TEST-PQ crypto-policy, openssl s_server and openssl s_client can establish a post-quantum connection and a classic connection:

$ openssl s_server \
    -cert localhost-mldsa.crt -key localhost-mldsa.key \
    -dcert localhost-rsa.crt -dkey localhost-rsa.key >/dev/null &
# Connection with PQC key exchange and PQC certificate
$ openssl s_client \
    -connect localhost:4433 \
    -CAfile localhost-mldsa.crt </dev/null \
    |& grep -E '(Peer signature type|Negotiated TLS1.3 group)'
Peer signature type: mldsa65
Negotiated TLS1.3 group: X25519MLKEM768
# Connection with classic algorithms only
$ openssl s_client \
    -connect localhost:4433 \
    -CAfile localhost-rsa.crt \
    -sigalgs 'rsa_pss_pss_sha256:rsa_pss_rsae_sha256' \
    -groups 'X25519:secp256r1:X448:secp521r1:secp384r1' </dev/null \
    |& grep -E '(Peer signature type|Server Temp Key)'
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits

Signatures in other protocols

Host keys and user keys in SSH, RPM package signatures with OpenPGP, Kerberos PKINIT, DNSSEC — there is a long list of protocols that currently do not yet support post-quantum signatures. For some of these, like OpenPGP, standardization is already in progress. Others will first have to be updated before implementations will become widely available. No protocols other than TLS and SSH support post-quantum signatures in Red Hat Enterprise Linux 10.0.

Conclusion

Red Hat Enterprise Linux 10.0 provides a significant step towards security against quantum computer attacks. The ML-KEM key exchange algorithm can protect TLS connections established by OpenSSL, GnuTLS and NSS, and SSH connections with OpenSSH against “harvest now, decrypt later” attacks. The ML-DSA signature algorithm is available through OpenSSL for raw signatures, and some support for ML-DSA signatures can be optionally enabled for clients that support them. Environments that need post-quantum key exchange and post-quantum signatures in TLS can achieve this goal with OpenSSL.

Many protocols are still in the standardization phase, and further improvements will be included in Red Hat Enterprise Linux as they become available. Due to the quickly evolving nature of this area of cryptography, all post-quantum cryptography in Red Hat Enterprise Linux is currently in Tech Preview state. Echoing the guidance from many security and compliance authorities that are encouraging organizations to start migrating to PQC capabilities as soon as possible, we invite you to start testing and leveraging these initial PQC features in Red Hat Enterprise Linux 10.0 today.