Post-Quantum-Ready SSH: ML-KEM Hybrid Explained

The practical concern behind post-quantum key exchange is "harvest now, decrypt later." An attacker may record encrypted traffic today and hope that a future quantum-capable system can break parts of the classical key exchange that protected it.

Post-quantum key exchange tries to reduce that future risk by using algorithms designed to resist known quantum attacks. In the SSH world, that appears as newer key-exchange methods when the installed OpenSSH stack supports them.

Hybrid means the connection does not rely on only the post-quantum side. A classical exchange, such as X25519, runs alongside the post-quantum mechanism. The goal is to gain future-facing protection without dropping the classical security properties that are trusted today.

That is why "post-quantum-ready" is better language than "quantum-proof." The feature depends on the SSH implementation, the negotiated algorithm, and the environment. It is a safer available path, not a magic word.

ML-KEM is the module-lattice key-encapsulation mechanism standardized in NIST FIPS 203. OpenSSH has added hybrid key-exchange support in newer releases using ML-KEM with X25519. When that support exists, a gateway can prefer the stronger negotiated option.

For a Mac remote-access product, the responsible claim is narrow: use OpenSSH hybrid ML-KEM key exchange when the installed SSH stack supports it. Do not claim that every part of the product is post-quantum. Do not imply a separate FIPS validation unless there is one.

HearthGate treats post-quantum-ready SSH as a transport hardening feature. If the Mac-side SSH stack is new enough, it can auto-enable the ML-KEM hybrid key-exchange path. If not, the connection still uses the available SSH security model.

The practical goal is simple: today's remote screen traffic should not be easier to understand just because someone records it and waits for tomorrow.