Post-quantum SSH

In one paragraph

For SFTP, BlazeSCP agrees on session keys using a hybrid of a post-quantum algorithm and classical X25519. Someone recording your traffic today can’t decrypt it later with a quantum computer, and if the post-quantum algorithm were ever broken, the session would still be as strong as classical SSH. Servers that don’t support it get classical SSH in the same handshake.

The algorithms

BlazeSCP offers these, best first:

Key exchange	Post-quantum part	Servers
mlkem768x25519-sha256	ML-KEM-768 (NIST FIPS 203)	OpenSSH 9.9 and later
sntrup761x25519-sha512	Streamlined NTRU Prime 761	OpenSSH 9.9 and later (standard name)
sntrup761x25519-sha512@openssh.com	(same algorithm, original name)	OpenSSH 8.5 and later; the default in 9.0 to 9.8
curve25519-sha256, ECDH, Diffie-Hellman	none (classical fallback)	everything else

SSH picks the first algorithm both sides support, so the fallback happens within one handshake, without retrying or failing.

Checking a connection

• A PQC tag next to the server in the sidebar means the current connection is quantum-safe.
• The shield icon in the pane’s toolbar is orange for post-quantum and grey for classical. Hover it to see the exact algorithm.

To see what a server offers, run this on the server:

sshd -T | grep -i kexalgorithms

Getting PQC on your servers

Any OpenSSH server from 8.5 onwards supports NTRU Prime, and 9.9 onwards also ML-KEM, unless the administrator turned them off. Check with the command above; if neither appears, update OpenSSH. If you’ve customised KexAlgorithms in sshd_config, put mlkem768x25519-sha256 and sntrup761x25519-sha512@openssh.com at the front of the list.

What it doesn’t cover

• Host key and user key signatures are still classical (Ed25519, ECDSA, RSA), as in OpenSSH today. They protect the connection while it’s being made; a future quantum computer can’t use them to decrypt recorded traffic.
• FTPS, WebDAVS and S3 use TLS. Whether those get post-quantum key exchange depends on the server and the TLS library.