Background
In 1994, Shor’s algorithm showed that widely deployed public-key systems RSA, DSA, and elliptic-curve cryptography would be vulnerable once sufficiently powerful quantum hardware becomes available. This realization triggered decades of research into alternative mathematical foundations for public-key cryptography.
In 2016, NIST launched a public, multi-round standardization effort to evaluate and select quantum-resistant algorithms. After years of cryptanalysis and community review, NIST published its first PQC (Post-quantum cryptography) standards in 2024, centered on module-lattice constructions for key encapsulation and digital signatures, with a hash-based signature scheme as a backup.
| Cryptographic Function | NIST Standard Name | Common Name | FIPS Publication |
|---|---|---|---|
| Key Encapsulation Mechanism (KEM) | ML-KEM (Module-Lattice KEM) | CRYSTALS-Kyber | FIPS 203 |
| Digital Signatures | ML-DSA (Module-Lattice Digital Signature Algorithm) | CRYSTALS-Dilithium | FIPS 204 |
| Digital Signatures (hash-based, backup) | SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) | SPHINCS+ | FIPS 205 |
NIST continues to evaluate and standardize additional algorithms from different families such as code-based and hash-based cryptography to improve long-term resilience and cryptographic diversity.
With industry adoption accelerating, regulatory guidance emerging, and real-world deployments underway, PQC has moved from theory to practice.
Ubuntu 25.10 features
OpenSSL
A prime example of real world deployment is the OpenSSL 3.5 release. It includes support for ML-KEM, ML-DSA, and SLH-DSA.
Cloudflare research offers a useful service where you can quickly see if your client/browser supports ML-KEM for key exchange. Simply visit the URL in your browser to see the result.
You can also test this from an Ubuntu system using curl.
$ curl -v https://pq.cloudflareresearch.com 2>&1 >/dev/null|grep 'SSL connection using'
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
curl is using OpenSSL/3.5.3 as a cryptography backend. You can use curl --version to test this on your system.
However, if you run the same command on Ubuntu 24.04 (Noble), you’ll notice it uses only X25519 (Elliptic-Curve Diffie-Hellman) for key exchange:
$ curl -v https://pq.cloudflareresearch.com 2>&1 >/dev/null|grep 'SSL connection using'
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
Let’s see what this means for a server running Ubuntu 25.10, using nginx as an example.
-
Install Nginx:
$ sudo apt install nginx -
Enable HTTPS:
The default site runs over HTTP. To enable HTTPS, install the ssl-cert package for self-signed certificates:
$ sudo apt install ssl-cert -
Configure Nginx:
Uncomment the following lines in your site configuration (example:
/etc/nginx/sites-available/default):listen 443 ssl default_server; listen [::]:443 ssl default_server; include snippets/snakeoil.confYour sites configuration should look something like this:
server { listen 80 default_server; listen [::]:80 default_server; # SSL configuration # listen 443 ssl default_server; listen [::]:443 ssl default_server; # # Note: You should disable gzip for SSL traffic. # See: https://bugs.debian.org/773332 # # Read up on ssl_ciphers to ensure a secure configuration. # See: https://bugs.debian.org/765782 # # Self signed certs generated by the ssl-cert package # Don't use them in a production server! # include snippets/snakeoil.conf; … -
Reload Nginx:
$ sudo systemctl reload nginx -
Now, test your local site over HTTPS:
$ curl -v https://localhost 2>&1 >/dev/null|grep 'SSL connection using' * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / RSASSA-PSS
You’ll see it is using X25519MLKEM768 for key exchange. This means that if you host your web servers on Ubuntu 25.10 or the upcoming 26.04 LTS, they will use a post-quantum secure key exchange method by default.
Note: This is only a demonstration. Do not use these steps in production. For production use, refer to the official Nginx documentation.
OpenSSH
On Ubuntu 25.10, if you SSH to a server running OpenSSH 10.0(+), it will use post-quantum key exchange by default. In the following example, I connect to sshd on the same host:
$ ssh -v -o PreferredAuthentications=none user@localhost 2>&1 | grep 'kex: algorithm:'
debug1: kex: algorithm: mlkem768x25519-sha256
I used PreferredAuthentications=none to avoid authenticating and just see the default key exchange algorithm. The algorithm used mlkem768x25519-sha256, is the same as in the OpenSSL demo.
If you SSH to 24.04 (Noble), the default algorithm is sntrup761x25519-sha512. mlkem768x25519-sha256 is the new preferred default. I’ll see if I can backport the new algorithm to Noble after 26.04 is released.
Others Libraries
Additionally, Libgcrypt (since 1.11.0) and wolfssl (since 2.7.2), and rustls (since 23.23) also have support for ML-KEM and ML-DSA. All of these are included in Ubuntu 25.10. Please let me know if I have missed any.
A note on Hybrid encryption
You may have noticed X25519MLKEM768 as the name for key exchange in TLS. This means an attacker must break both the classical X25519 exchange and the post-quantum MLKEM768 exchange to compromise the session.
Daniel J. Bernstein’s analysis of cryptographic selection processes explains why this matters. Looking at real-world outcomes, he found that a large fraction of post-quantum schemes, including many that survived multiple NIST rounds, were later broken or weakened below their claimed security level. Post-quantum schemes are young, cryptanalysis is active, and progress often comes in sudden jumps.
A hybrid approach remains secure as long as at least one component holds. This is not a lack of confidence in post-quantum cryptography, but rather an acknowledgment of measured historical failure rates and implementation risks. For this reason, Ubuntu has chosen to retain hybrid key exchange as the default. For those who require a PQ-only configuration, a system-wide profile option will be available, more on this in an upcoming blog post.
Looking Ahead
Next in the NIST pipeline, Lattice based Falcon for Signatures is expected to be included in the standard (FIPS-206). Meanwhile, code-based HQC is a contender for a backup algorithm for KEM, it does not have a FIPS number yet.
As standards mature, Firmware vendors will increasingly offer the ability to add PQC algorithms. My guess is Hybrid Secure Boot (classical + PQ Signatures) could realistically appear around the 28.04 LTS timeframe.
Please experiment with these algorithms, report any bugs, and share your feedback. Your input is greatly appreciated.