Integrating Post-Quantum Cryptography for TLS Into Applications

If you find any issues with the instructions then do not hesitate to create an issue here

This document is under European Union Public License 1.2 (EUPL-1.2).

Changelog

Date	Description
2026-08-01	Initial version

Introduction

Post-quantum cryptography is supposed to address the threats to classical cryptography by the development of a future quantum computer. This article does not make any assessment if this future quantum computer is possible or when this would be possible. This is about to your organisation's risk department or your own assessment (There are arguments against it and a lot of advertisement by the technology industry often without evidence). Nevertheless, it is always a good exercise to think about this threats and how one can address them.

One of the main learnings is that you need to be aware where in your enterprise landscape you use cryptographic algorithms and that you need to be agile ("Cryptographic Agility") to replace them in case needed (e.g. new better algorithms or bug fixes to existing ones).

I will start by describing the threat scenarios that post-quantum cryptography tries to address. Then I will explain general solutions to this mainly focusing on asymmetric cryptography used for encryption-in-transit in Transport Layer Security (TLS) applications. Finally, I will give an overview of support for post-quantum cryptography in various programming languages for client and server applications.

Threat Scenarios

Essentially there are the following threat scenarios related to post-quantum cryptography relevant to TLS:

Name	Description	When relevant
Harvest now, decrypt later	Attacker stores all communication using classical asymmetric cryptographic algorithms now in order to decrypt once a quantum computer or alternative is available. This is related mainly to key-agreement/key exchange mechanisms in TLS.	Relevant today assuming current classical asymmetric algorithms can be broken in the foreseeable future
In-the-middle-attack	Attacker has the ability to intercept, decrypt and optionally modify communication encrypted using classical cryptography mechanisms. This is mainly related to authentication mechanisms in TLS.	Relevant when a quantum computer or an alternative is able to break classic asymmetric cryptographic algorithms

General Solutions

There are different solutions for the different threat scenarios - there is not one addressing both (see also Post-Quantum Cryptography Recommendations for TLS-based Applications). As indicated in the previous section, the threat of harvest now, decrypt later is now more relevant compared to in-the-middle attacks. The following general solutions exist to deal with these threats in TLS

Threat Scenario	Solution	Change complexity
Harvest now, decrypt later	Change key agreement (or key exchange) algorithm to a hybrid post-quantum solution or pure post-quantum solution (both provide equivalent protection against the stated security threat)	Medium: Server software: You need to update the server software and enable the post-quantum key exchange by configuring a specific hybrid mechanism (e.g. SecP256r1MLKEM768) or a post-quantum-only one (e.g. ML-KEM-768). You may decide to first update server software communicating with the clients (e.g. load balancer) and later other server software (e.g. backends) for a complete mitigation of the threat scenario. A hybrid mechanism for key exchange means that a classical algorithm and a post-quantum algorithm are combined. This means if only one of them is broken then the attacker cannot break the key exchange. It does not allow clients that do not support post-quantum algorithms to connect in case only hybrid or post-quantum only algorithms are available. Clients: Clients need to be updated and configured with the right algorithms to mitigate the threat per client, but clients not supporting post-quantum algorithms continue to work if you support additionally a classic-only algorithm (not a hybrid one). Their connection though is not protected and you risk downgrading attacks of other clients.
In-the-middle-attack	Change server certificates (and client certificates if client authentication is enabled) to hybrid (supporting classical and post-quantum certificates) or post-quantum only certificates. Change authentication cryptographic algorithms to support hybrid or post-quantum-only authentication. You need to consider the whole trust-chain (including the root and intermediate certificates)	Very high: Certificates and signatures: Certificates of post-quantum authentication algorithms are potentially significantly larger compared to classic certificates. Signatures for authentication for post-quantum algorithms are potentially significantly larger than for classical. This impacts performance of TLS connections. Infrastructure: Public key infrastructure (including Enterprise user directories) is not trivial and they will need to deal with multiple certificates (e.g. in case of hybrid post-quantum deployments) for the same entity (e.g. server) and different authentication algorithms. Additionally multiple different trust anchors (e.g. post-quantum and classical ones in case of hybrid solutions) Hardware: Private certificates are often stored in hardware security modules (HSM). You may need to replace the hardware or at least update their firmware to support storage of potentially larger certificates and to support the new post-quantum algorithms. Server: You need to update the server software, generate one (post-quantum or classic algorithms only) or multiple certificates (hybrid) and configure a specific hybrid mechanism (e.g. Secp256r1 (classic) and ML-DSA (post-quantum)) or post-quantum only one (e.g. ML-DSA or SLH-DSA). The right algorithm needs to be configured including a preferred order of algorithms. Depending on the application you may need to update the server resources to have the same performance as for classic-only authentication. Client: You need to update the client software and configure a post-quantum algorithm only. You need to configure the clients that they only accept for the whole certificate hierarchy (trust anchors) post-quantum certificates, because if they allow only one classical certificate in the chain then it does not protect against the threat. You do not need to update all clients at once, but clients supporting only classic algorithms are at risk if a post-quantum computer that can break classic algorithms exists. If you use client authentication using TLS then you need to update the client certificates and configure the post-quantum algorithms for client authentication.

Generally, you should switch to at least TLS-1.3 to be ready for these threats and additionally activate the post-quantum cryptographic algorithms. This also means you should not enable any more TLS-1.2, while generally safe with the right choice of algorithms, it supports by default a lot of different algorithms of which some have been broken (see here). Furthermore post-quantum support in TLS-v1.2 is poorly supported in the specifications and implementations. In all cases, you need to update your programming languages and/or libraries to a version that supports the post-quantum algorithms (presented later in this document). Additionally, you need to adapt the application configuration and select an adequate algorithm in the security category you need.

Selecting algorithms

When selecting cryptographic algorithms then you can do this by multiple criteria:

How confidential is your data: The more confidential your data is the higher the protection must be. Data that is anyway public often does not need highest confidentiality protection.
How much integrity do you need for your data: if integrity of your data is very important then you need to deploy higher protections.
Compliance: Regulations and/or industry standards may define what algorithms you can use and which ones not.
What is the lifetime of the data: if your data is only confidential and/or requires integrity for the next 40 years then this is different from for the next 5 years as the quantum computing security threat has not materialised yet.
Performance: What is the minimum performance needed for your application? You may choose to provide more resources and/or to use less strong algorithms.
Maturity: How mature is the algorithm and do well-tested as well as widely deployed software exist?

When selecting a post-quantum algorithm for a hybrid or post-quantum only deployment then you need to decide for the security strength category. The National Institute of Standards and Technology (NIST) (US) defined five security strength categories:

Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 128-bit key (e.g., AES-128)
Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for collision search on a 256-bit hash function (e.g., SHA-256/ SHA3-256)
Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 192-bit key (e.g., AES-192)
Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for collision search on a 384-bit hash function (e.g., SHA-384/ SHA3-384)
Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 256-bit key (e.g., AES-256)

Depending on how much your data needs to protected you need to select the security strength category and configure the post-quantum algorithm accordingly. The following table describes the different post-quantum algorithms and the security category for the specific algorithm configuration.

Algorithm	Security Strength Category	Configuration
ML-KEM (FIPS 203)	1	ML-KEM-512
	3	ML-KEM-768
	5	ML-KEM-1024
ML-DSA (FIPS 204)	2	ML-DSA-44
	3	ML-DSA-65
	5	ML-DSA-87
SLH-DSA (FIPS 205)	1	SLH-DSA-SHA2-128s SLH-DSA-SHAKE-128s SLH-DSA-SHA2-128f SLH-DSA-SHAKE-128f
	3	SLH-DSA-SHA2-192s SLH-DSA-SHAKE-192s SLH-DSA-SHA2-192f SLH-DSA-SHAKE-192f
	5	SLH-DSA-SHA2-256s SLH-DSA-SHAKE-256s SLH-DSA-SHA2-256f SLH-DSA-SHAKE-256f

The following table provides a list of hybrid key exchange mechanisms, which have the same categories as the corresponding pure post-quantum key exchange mechanisms (see Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3).

Hybrid Algorithm	Classic Part	Post-Quantum Part
X25519MLKEM768	X25519 curve	ML-KEM-768
SecP256r1MLKEM768	secp256r1 curve	ML-KEM-768
SecP384r1MLKEM1024	SecP384r1 curve	ML-KEM-1024

Post-quantum Algorithm tradeoffs

There are some tradeoffs for post-quantum algorithms compared to classical algorithms.

The following table compares a classical key exchange algorithm with post-quantum ones.

Algorithm	Private Key (Size)	Public Key (Size)	Ciphertext (Size)
X25519 (classic)	256 bits (32 bytes)	256 bits (32 bytes)	256 bits (32 bytes)
ML-KEM-768 (post-quantum)	19200 bits (2400 bytes) - decapsulation key	9472 bits (1184 bytes) - encapsulation key	8704 bits (1088 bytes)
ML-KEM-1024 (post-quantum)	25344 bits (3168 bytes) - decapsulation key	12544 bits (1568 bytes) - encapsulation key	12544 bits (1568 bytes)

The following table compares a classical authentication (signature) algorithm with post-quantum ones.

Algorithm	Private Key (Size)	Public Key (Size)	Signature (Size)
Ed25519 (classic)	256 bits (32 bytes)	256 bits (32 bytes)	512 bits (64 bytes)
ML-DSA-44 (post-quantum)	20480 bits (2560 bytes)	10496 bits (1312 bytes)	19360 bits (2420 bytes)
ML-DSA-65 (post-quantum)	32256 bits (4032 bytes)	15616 bits (1952 bytes)	39708 bits (3309 bytes)
ML-DSA-87 (post-quantum)	39168 bits (4896 bytes)	20736 bits (2592 bytes)	37016 bits (4627 bytes)
SLH-DSA-SHA2-128s SLH-DSA-SHAKE-128s (post-quantum)	512 bits (64 bytes)	256 bits (32 bytes)	62848 bits (7856 bytes)
SLH-DSA-SHA2-128f SLH-DSA-SHAKE-128f (post-quantum)	512 bits (64 bytes)	256 bits (32 bytes)	136706 bits (17088 bytes)
SLH-DSA-SHA2-192s SLH-DSA-SHAKE-192s (post-quantum)	768 bits (96 bytes)	384 bits (48 bytes)	129792 bits (16224 bytes)
SLH-DSA-SHA2-192f SLH-DSA-SHAKE-192f (post-quantum)	768 bits (96 bytes)	384 bits (48 bytes)	285312 bits (35664 bytes)
SLH-DSA-SHA2-256s SLH-DSA-SHAKE-256s (post-quantum)	1024 bits (128 bytes)	512 bits (64 bytes)	238336 bits (29792 bytes)
SLH-DSA-SHA2-256f SLH-DSA-SHAKE-256f (post-quantum)	1024 bits (128 bytes)	512 bits (64 bytes)	398848 bits (49856 bytes)

While the differences in both cases look small, they can have a huge impact for TLS when hundreds to thousands of users execute requests. Additionally, larger key sizes or ciphertext sizes may have impact on resources needed to cater for the same load as with classical-only solutions.

Support in Programming Languages

The following table provides a non-exhaustive list (see here for a more complete list of TLS libraries) of programming languages and libraries supporting post-quantum algorithms. The version numbers are based on official release notes, which may not be complete or accurate. We do not indicate here if the implementations can leverage hardware support for cryptographic operations, which can have a significant impact on performance.

See the TLS configuration guidelines, which are the recommended up-to-date guidelines for TLS configuration.

Note: TLS v1.3 does not yet have a finalised standard for post-quantum key-exchange or post-quantum-authentication. This means the support is currently based on draft specifications.

It is not sufficient to only update your compiler or add a library: You need to programmatically integrate and configure post-quantum algorithms. You need to make sure TLS-v1.3 is supported (only the algorithm is not sufficient).

Programming Language	Library	Supported algorithms
C	s2n-tls 1.5.6+	ML-KEM (TLS-1.3)
	s2n-tls 1.5.19+	ML-DSA (TLS-1.3)
	s2n-tls 1.5.23+	hybrid ML-KEM (TLS-1.3)
	OpenSSL 3.5+	ML-KEM (TLS-1.3) ML-DSA (TLS-1.3) SLH-DSA (TLS-1.3)
C++	Botan 3.6.0+	ML-KEM (TLS-1.3) hybrid ML-KEM (TLS-1.3) ML-DSA (TLS-1.3) SLH-DSA (TLS-1.3)
Java (only LTS versions are considered)	native (JDK 25 LTS)	ML-KEM (algorithm-only) ML-DSA (algorithm-only)
	native (JDK 28 LTS)	ML-KEM (TLS-1.3)
	BouncyCastle 1.80+ (JDK 17 LTS)	ML-KEM (algorithm only, can be made available for Java TLS implementation by registering BouncyCastleJsseProvider) ML-DSA (algorithm only, can be made available for Java TLS implementation by registering BouncyCastleJsseProvider) SLH-DSA (algorithm only, can be made available for Java TLS implementation by registering BouncyCastleJsseProvider)
Python	native (optional ssl module)	Depends on OpenSSL version that is supported by the optional Python ssl module and availability of this OpenSSL version on the installed system (see row OpenSSL for minimal versions)
Python	pyca/cryptography (algorithm-only, no TLS support)	ML-KEM (algorithm-only) (algorithm-only) hybrid ML-KEM (algorithm-only) ML-DSA (algorithm-only) SLH-DSA (algorithm-only)
Rust	Rustls (based on s2n-tls) with additional crate rustls-post-quantum (based on experimental s2n-tls)	ML-KEM (TLS-1.3) (TLS-1.3) hybrid ML-KEM (TLS-1.3) ML-DSA (TLS-1.3)

Your cloud service provider may provide specific services, such as load balancers, for which you must activate post-quantum TLS algorithms if supported.