Preparing for the Quantum Future: A Practical Guide to Post-Quantum Cryptography
TL;DR
Advances in quantum processing capabilities are rapidly bringing forward the estimated date that a cryptographically relevant quantum computer (CRQC) will be available and previously strong encryption algorithms will be broken. With the recommended date for ceasing the use of traditional asymmetric cryptography now only years away in 2030, “Harvest now, decrypt later” attacks mean switching to Post-Quantum Cryptography (PQC) strong encryption algorithms is something to do today.
The good news is that this is relatively simple (and possibly already in place on sufficiently up-to-date systems) with key algorithm ML-KEM production-ready and supported by both OpenSSL and OpenSSH, so adopting PQC is a matter of upgrading and configuration for most systems.
Understanding the Threat
What’s at Risk?
Public-key cryptography relies on mathematical problems that are hard for computers to solve. With the likelihood of a cryptographically relevant quantum computer (CRQC) becoming available in the next 10 years and the existence of attacks like Shor‘s algorithm older algorithms which defeated classical computers are at risk.
The Timeline
- Now-2025: Harvest now, decrypt later data harvesting likely already underway for sensitive/high-value data. Anything of value in the next 10 years is relevant.
- 2027-2029: Expected widespread adoption of PQC encryption
- 2030-2035: Traditional cryptography likely to be deprecated
- 2030: ASD recommends PQC compliance deadlines by 2030
Post-Quantum Cryptography: The Solution
The National Institute of Standards and Technology (NIST) completed its PQC standardization process in 2024, selecting algorithms that are believed to be resistant to both classical and quantum computing attacks.
Key Algorithm: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)
Formerly known as CRYSTALS-Kyber, ML-KEM is the primary algorithm for key establishment:
- Based on lattice mathematics (difficult for both classical and quantum computers)
- Production-ready and standardized
- Available in multiple security levels (512, 768, 1024-bit)
- Currently deployed in hybrid mode with traditional algorithms
Hybrid Approach: The Current Best Practice
Rather than replacing classical cryptography entirely, the industry standard is to use hybrid algorithms that combine traditional and post-quantum methods.
This approach provides “defense in depth”—your communications remain secure even if one algorithm is broken.
Implementation Guide: OpenSSH
OpenSSH has included PQC support since version 9.0 (released April 2022).
Current Support Status
Key Exchange Algorithms:
sntrup761x25519-sha512@openssh.com(hybrid Streamlined NTRU Prime + X25519)- Default in OpenSSH 9.0+ but not mandatory
What This Means:
- Sufficiently up-to-date OpenSSH already uses PQC for key exchange by default
- No configuration changes needed for basic protection
- Both client and server must support the algorithm for it to be used
- PQC algorithm sntrup761 added in 8.0 through to current latest version 10 enabling the NIST standardised ML-KEM (mlkem768x25519) being enabled and preferred for all connections by default. See release notes.
Checking Your OpenSSH Configuration
1. Verify OpenSSH Version
ssh -V
Look for version 9.0 or higher. If you’re running an older version, upgrade when possible.
2. Check Supported Algorithms
ssh -Q kex
Look for sntrup761x25519-sha512 and/or mlkem768x25519-sha256 the output. If present, PQC is available for your ssh client.
3. Test an SSH Connection
ssh -vvv user@hostname 2>&1 | grep -B1 "kex"
This will show both client and server KEX algorithm lists and the final agreed kex algorithm chosen.
User Authentication Keys (key exchange) unchanged for the time being
The “store now, decrypt later” attack applies only to key exchange, not authentication. Authentication is interactive—the attacker would need quantum computing power at connection time to break it, and by that point, you will have migrated to post-quantum signature algorithms
An attacker recording SSH traffic cannot retroactively break authentication by later obtaining a quantum computer. The OpenSSH project explicitly states: “There is no risk to existing traffic in this situation (i.e. there is no analogous ‘store now, decrypt later’). The only urgency for signature algorithms is ensuring that all classical signature keys are retired in advance of cryptographically-relevant computers becoming a reality.” See OpenSSH Post-Quantum Cryptography.
Implementation Guide: TLS/OpenSSL
TLS implementation is more complex due to the number of platforms, clients, and servers involved, but the ecosystem is rapidly maturing.
OpenSSL Version Requirements
OpenSSL 3.5.0 and Later (Released 2025)
- Native support for ML-KEM algorithms
- No additional plugins required
- Includes
X25519MLKEM768andSecP256r1MLKEM768
OpenSSL 3.0-3.4
- Requires OQS (Open Quantum Safe) provider plugin
- More complex setup
- Experimental support
OpenSSL 1.1.1 and Earlier
- No PQC support
- Upgrade strongly recommended (also for security patches)
Platform-Specific Support Status
Web Browsers:
- Chrome 131+ / Edge 131+: Native ML-KEM support, enabled by default
- Firefox: Experimental support (enable via flags)
- Safari: In development
Operating Systems:
- Linux: OpenSSL 3.5+ provides full support
- macOS: Currently uses BoringSSL (Google’s fork), PQC support rolling out
- Windows: Native support coming in future Windows Server versions
- iOS/Android: Browser-dependent, following Chrome/Safari schedules
Resources and Further Reading
Official Standards:
- NIST Post-Quantum Cryptography: csrc.nist.gov/projects/post-quantum-cryptography
- FIPS 203 (ML-KEM): Final standard published August 2024
Open Source Projects:
- Open Quantum Safe (liboqs): openquantumsafe.org
- OpenSSL: openssl.org
- OpenSSH: openssh.com
Conclusion
Post-quantum cryptography is no longer theoretical—it’s a practical reality that’s ready for deployment today. While the full transition will take years, the foundations are already in place, and early adoption provides crucial protection against current and future threats.
The hybrid approach offers a smooth path forward: you can implement PQC now without breaking compatibility, gaining quantum resistance while maintaining classical security guarantees. As the ecosystem matures, transitioning to purely post-quantum systems will be a natural evolution rather than a disruptive change.
Start with the low-hanging fruit: ensure your OpenSSH installations are up to date, as PQC is already enabled by default. Then plan your TLS upgrade path, prioritizing systems that handle sensitive or long-lived data. Use the testing tools and commands provided in this guide to validate your implementations and track your progress.
The quantum threat is real, but the solution is here. The time to act is now—not out of panic, but as part of a measured, strategic approach to long-term cryptographic security.