Post Quantum (PQ) Support

s2n-tls supports both post-quantum key exchange and post-quantum authentication for TLS1.3.

Key Exchange: ML-KEM

Currently, only ML-KEM is supported for post-quantum key exchange.

s2n-tls supports both hybrid and pure PQ key exchange.

• Hybrid PQ key exchange involves performing both classic ECDH key exchange and post-quantum key exchange, then combining the two resultant secrets. This strategy combines the high assurance of the classical key exchange algorithms with the quantum-resistance of the new post-quantum key exchange algorithms. If one of the two algorithms is compromised, either because advances in quantum computing make the classic algorithms insecure or because cryptographers find a flaw in the relatively new post-quantum algorithms, the secret is still secure. Hybrid post-quantum key exchange is more secure than standard key exchange, but is slower and requires more processing and more network bandwidth.

• Pure PQ key exchange involves only post-quantum key exchange, without classic ECC components. It is a simpler long-term architecture compared to hybrid PQ algorithms. However, Pure PQ key exchange might lead to potential incompatibility with older devices as it takes no dependence on traditional ECC algorithms.

Careful: An s2n-tls server that enables post-quantum cryptography will mandate post-quantum key exchange with any client advertising post-quantum algorithms. This can result in a retry and an extra round trip if the client does not initially send a post-quantum key share. The rational behind this behavior is that post-quantum users prioritize security over the potential cost of an extra round trip.

Authentication: ML-DSA

Currently, only ML-DSA is supported for post-quantum authentication.

In order to use ML-DSA, you must configure s2n-tls to use an ML-DSA certificate, just as you would configure an RSA or ECDSA certificate. See certificates.

Requirements

AWS-LC

s2n-tls must be built with aws-lc to use post-quantum algorithms. See the s2n-tls build documentation for how to build with aws-lc. For ML-DSA, you will need to use a version of AWS-LC >= v1.50.0 (API version 33).

If you’re unsure what cryptography library s2n-tls is built against, trying running s2nd or s2nc:

> s2nd localhost 8000
libcrypto: AWS-LC
Listening on localhost:8000

Security Policy

Post-quantum algorithms are enabled by configuring a security policy (see Security Policies) that supports post-quantum algorithms.

“default_pq” is the equivalent of “default_tls13”, but with PQ support. Like the other default policies, “default_pq” may change as a result of library updates. The fixed, numbered equivalent of “default_pq” is currently “20250721”. For previous defaults, see the “Default Policy History” section below.

“cnsa_2” is derived from Commercial National Security Algorithm (CNSA) Suite Profile for TLS 1.3. This is a TLS 1.3 PQ only policy that requires pure ML-KEM-1024 for key exchange and ML-DSA-87 for signature and certificate verification.

“cnsa_1_2_interop” is a transitional policy from CNSA 1.0 / RFC 9151 (non-PQ) to CNSA 2.0 (PQ only). It combines all the supported algorithms in the “cnsa_2” and “rfc9151” (see Security Policies) policies. Like other default policies, these CNSA policies are subject to the source RFC definition changes.

Other available PQ policies are compared in the tables below.

Chart: Security Policy Version To PQ Key Exchange Methods (ML-KEM)

Chart: Security Policy Version To Signature Schemes

Chart: Security Policy Version To Classic Key Exchange

If the peer doesn’t support a PQ hybrid key exchange method, s2n-tls will fall back to a classical option.

Note: the “cnsa_2” policy only allows ML-KEM-1024, thus there is no fallback to classic key exchange.

Chart: Security Policy Version To Ciphers

Chart: Security Policy Version To TLS Protocol Version

Default Policy History

Visibility

Call s2n_connection_get_kem_group_name to determine if a TLS handshake negotiated PQ key exchange.