Every time you see the padlock in your browser, push code over SSH, or your application connects to a database, TLS or SSH is quietly doing two jobs. First, it proves you are talking to the real server and not an impostor. Second, it lets two machines that have never met agree on a secret encryption key, in public, with eavesdroppers watching.
That second trick, the key exchange, works because the underlying math (RSA, or elliptic curves such as X25519) is easy to compute in one direction and practically impossible to reverse. A conventional computer would need longer than the age of the universe.
The Quantum Computer Era
Quantum computing do not just run the same math faster. They run a different kind of math. In 1994, Peter Shor showed that a sufficiently large quantum computer could reverse exactly the problems our key exchanges depend on, in hours rather than eons. The hypothetical day such a machine exists has a nickname: Q Day. Nobody knows when it arrives. Most estimates cluster in the 2030s. It might be later. It will not be never.
Here is the part that makes this urgent rather than a someday problem: an attacker does not need a quantum computer today to hurt you today. Encrypted traffic can be recorded and stored now, then decrypted the moment the hardware exists. This is called Harvest Now, Decrypt Later (HNDL). If your data still needs to be secret in ten years – health records, contracts, credentials, intellectual property – traffic captured this year is already at risk.
One reassuring note: the encryption of the data itself (AES) is largely fine against quantum attack. It is the handshake, the moment the secret key is agreed, that is vulnerable. That is where the fix goes.
The Fix: Hybrid Key Exchange
The industry answer is post-quantum cryptography (PQC): algorithms built on math problems that even quantum computers cannot efficiently solve. NIST standardized the main key exchange algorithm, ML-KEM (formerly CRYSTALS-Kyber), in August 2024.
Because these algorithms are young, nobody rips out the old ones. The
deployment pattern is a hybrid: run the classical exchange (X25519)
and the post-quantum one (ML-KEM) together, and derive the session key
from both. An attacker must break both. You are never worse off than
classical alone. The common combination is called X25519MLKEM768, and
it already carries a meaningful share of TLS 1.3 traffic on the internet
without users noticing anything.
The important subtlety: this only protects a connection if it is what the two endpoints actually negotiate. Which brings us to the practical part.
SSH: Probably Already Protected (Verify It)
OpenSSH moved early. The two hybrid key exchanges are:
| Algorithm | Since | Notes |
|---|---|---|
sntrup761x25519-sha512 |
OpenSSH 9.0 default (2022) | Streamlined NTRU Prime hybrid |
mlkem768x25519-sha256 |
OpenSSH 9.9, default in 10.x | NIST-standardized ML-KEM hybrid |
Check any connection:
ssh -v yourserver 2>&1 | grep "kex: algorithm"
# debug1: kex: algorithm: mlkem768x25519-sha256
If you see mlkem768 or sntrup761, that session’s key exchange is
quantum-resistant.
What about your SSH keys themselves, the ed25519 or RSA pair in
~/.ssh? Those are signature keys used for authentication, and they are
the less urgent half. A recorded session cannot be retroactively logged
into; forging a login requires a quantum computer to exist at the moment
of the attack. Key exchange is urgent because captured ciphertext is
forever. Keep using Ed25519 keys, keep OpenSSH current, and rotate when
post-quantum signature types land in a future release.
MySQL and PostgreSQL: Inherited Protection via OpenSSL
Neither database implements TLS itself. Both delegate to a TLS library, almost always OpenSSL, which means they largely inherit quantum safety from the library underneath.
The milestone was OpenSSL 3.5 (April 2025): the first release with
ML-KEM built in, no patches or third-party providers required, and with
hybrid post-quantum key exchange (X25519MLKEM768) as the TLS default.
A MySQL or PostgreSQL server and client both built against OpenSSL 3.5+
can negotiate a quantum-safe handshake with no application changes.
The caveat worth stating plainly: a post-quantum handshake on one connection is not end-to-end coverage. Replication links, backups, connection poolers and cloud-managed endpoints each have their own TLS stack and their own OpenSSL. Inventory what each component links against, and verify what each connection negotiates.
Certificates are the slower-moving piece. Publicly-trusted post-quantum certificates are still years away, and that is acceptable: signatures are not the retroactive risk.
The Takeaway
Q Day itself will likely be invisible when it happens, possibly achieved quietly before any announcement. The practical defense is available now and mostly consists of software you already run:
- Upgrade: OpenSSH 9.9+ (ideally 10.x), OpenSSL 3.5+.
- Verify: check the negotiated algorithm on real connections, not the version number on the box.
- Inventory: know every place cryptography lives – clients, servers, poolers, replication, backups – and what each one negotiates.
That second step matters more than you might expect. In a follow-up post, I run the verification against GitHub from a fully-patched Mac and get a result that surprised me: Why My Mac Was Not Using Post-Quantum SSH With GitHub .
