Post Quantum (PQ) Support

s2n-tls supports post-quantum key exchange for TLS1.3. Currently, only Kyber is supported. See the draft IETF standard: https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design

Specifically, s2n-tls supports hybrid key exchange. PQ hybrid key exchange involves performing both classic ECDH key exchange and post-quantum Kyber 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.

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.

Requirements

AWS-LC

s2n-tls must be built with aws-lc to use post-quantum key exchange. See the s2n-tls build documentation for how to build with aws-lc.

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 key exchange is enabled by configuring a security policy (see Security Policies) that supports post-quantum key exchange 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 "20240730". For previous defaults, see the "Default Policy History" section below.

Other available PQ policies are compared in the tables below.

Chart: Security Policy Version To PQ Hybrid Key Exchange Methods

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.

Chart: Security Policy Version To Ciphers

Chart: Security Policy Version To Signature Schemes

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.