Listen to this Post
Introduction
The cryptographic foundations that secure the internet—RSA, Elliptic Curve Cryptography (ECC), and Diffie-Hellman key exchange—are facing an existential threat. A sufficiently powerful quantum computer running Shor’s algorithm could factor large integers and solve discrete logarithm problems in polynomial time, effectively breaking these classical encryption schemes. The U.S. National Institute of Standards and Technology (NIST) responded by finalizing the first three post-quantum cryptographic standards in August 2024, with ML-KEM (formerly CRYSTALS-Kyber) emerging as the flagship key-encapsulation mechanism based on the computational difficulty of the Module Learning with Errors (MLWE) problem. The migration from classical to post-quantum cryptography is no longer a theoretical discussion—it is an operational imperative for every organization handling data with long-term confidentiality requirements.
Learning Objectives
- Understand the fundamental cryptographic differences between classical RSA/ECC and post-quantum ML-KEM, including the mathematical hardness assumptions that underpin each system
- Learn how to practically implement ML-KEM for key encapsulation using open-source tools, including OpenSSL 3.5, liboqs, and Python implementations
- Develop a migration strategy that prioritizes crypto-agility, hybrid deployments, and cryptographic inventory management to transition legacy systems to quantum-safe alternatives
- Understanding the Quantum Threat: Why RSA and ECC Must Go
Classical public-key cryptography relies on mathematical problems that are computationally infeasible for classical computers but tractable for quantum machines. RSA’s security depends on the difficulty of factoring large integers, while ECC and Diffie-Hellman rely on the discrete logarithm problem. Shor’s algorithm, discovered in 1994, provides a quantum method to solve both problems in polynomial time.
The threat is not speculative. Researchers have demonstrated that Shor’s algorithm could potentially operate at cryptographically relevant scales using as few as 10,000–26,000 qubits—significantly lower than earlier estimates that required millions. Meanwhile, quantum hardware roadmaps from vendors target hundreds to thousands of logical qubits by the end of this decade. The timeline has compressed: what was once a 2035 problem is now a 2030 deadline.
The most urgent and underappreciated risk is the “harvest now, decrypt later” (HNDL) attack. Adversaries are already capturing encrypted traffic today, storing it, and waiting for a cryptographically relevant quantum computer to decrypt it. Any data with confidentiality requirements extending beyond approximately 2032–2035—intellectual property, health records, government communications, PKI root material, and firmware signing keys—is already exposed if protected only by classical public-key cryptography. NIST IR 8547 formally deprecates RSA-2048 and ECC-256 by 2030, with complete disallowance by 2035.
2. ML-KEM: The Post-Quantum Replacement for Key Exchange
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), standardized as FIPS 203, is derived from the CRYSTALS-Kyber submission and represents the primary NIST-approved algorithm for general key encapsulation. Unlike RSA and ECC, which rely on integer factorization and discrete logarithms, ML-KEM’s security is related to the computational difficulty of the Module Learning with Errors problem—a problem believed to be hard even for quantum computers.
NIST specifies three parameter sets for ML-KEM, offering a trade-off between security strength and performance:
| Parameter Set | Security Level | Public Key Size | Ciphertext Size |
||-|–|–|
| ML-KEM-512 | NIST Level 1 | ~800 bytes | ~768 bytes |
| ML-KEM-768 | NIST Level 3 | ~1,184 bytes | ~1,088 bytes |
| ML-KEM-1024 | NIST Level 5 | ~1,568 bytes | ~1,568 bytes |
The encryption process with ML-KEM follows a key-encapsulation mechanism (KEM) pattern rather than traditional public-key encryption. A KEM is a set of algorithms that two parties can use to establish a shared secret key over a public channel. The workflow consists of three core operations:
- ML-KEM.KeyGen(): Generates a public encapsulation key and a private decapsulation key
- ML-KEM.Encaps(pk): Takes a public key and produces a shared secret and a ciphertext
- ML-KEM.Decaps(sk, c): Takes a private key and ciphertext to recover the shared secret
The underlying mathematical structure uses polynomial arithmetic over a ring, with the Number Theoretic Transform (NTT) providing efficient multiplication.
3. Practical Implementation: ML-KEM with OpenSSL 3.5
OpenSSL 3.5, released in 2025, brings NIST-standardized post-quantum algorithms into the mainstream OpenSSL toolkit. This enables quantum-safe TLS handshakes and cryptographic operations without rewriting applications against new APIs.
Step-by-step: Building OpenSSL 3.5 with PQC Support on RHEL 9.6
The following procedure builds OpenSSL 3.5 from source without replacing the system OpenSSL:
Install build dependencies sudo dnf groupinstall "Development Tools" sudo dnf install perl-IPC-Cmd perl-Test-Harness perl-FindBin \ perl-File-Compare perl-File-Copy perl-Pod-Html Download and extract OpenSSL 3.5 wget https://www.openssl.org/source/openssl-3.5.0.tar.gz tar -xzf openssl-3.5.0.tar.gz cd openssl-3.5.0 Configure with post-quantum algorithms enabled ./config --prefix=/opt/openssl-3.5 --openssldir=/opt/openssl-3.5/ssl \ enable-ec_nistp_64_gcc_128 enable-tls1_3 Build and install make -j$(nproc) make install Verify available KEM algorithms /opt/openssl-3.5/bin/openssl list -kem-algorithms
Expected output should include ML-KEM-512, ML-KEM-768, and `ML-KEM-1024` among the available key-exchange methods.
Testing ML-KEM Key Encapsulation
Generate an ML-KEM-768 key pair /opt/openssl-3.5/bin/openssl genpkey -algorithm ML-KEM-768 \ -out private_key.pem Extract the public key /opt/openssl-3.5/bin/openssl pkey -in private_key.pem -pubout \ -out public_key.pem Encapsulate a shared secret using the public key /opt/openssl-3.5/bin/openssl pkeyutl -encrypt -pubin -inkey public_key.pem \ -out ciphertext.bin Decapsulate using the private key /opt/openssl-3.5/bin/openssl pkeyutl -decrypt -inkey private_key.pem \ -in ciphertext.bin -out shared_secret.bin
4. Hybrid Deployment: Dual-Stack Cryptography for Safe Transition
The recommended migration approach uses hybrid cryptography—combining classical and post-quantum algorithms in parallel. This preserves backward compatibility while adding quantum protection. OpenSSL 3.5 supports hybrid key exchanges such as X25519MLKEM768, which combines X25519 with ML-KEM-768 in a single TLS handshake.
Hybrid TLS 1.3 Handshake Configuration
Start a TLS 1.3 server with hybrid PQC support /opt/openssl-3.5/bin/openssl s_server -accept 4433 -tls1_3 \ -groups X25519MLKEM768 \ -cert server.crt -key server.key Connect with hybrid key exchange /opt/openssl-3.5/bin/openssl s_client -connect localhost:4433 -tls1_3 \ -groups X25519MLKEM768
For certificate hierarchies, dual-algorithm certificates embed cryptographic artifacts of both traditional and post-quantum algorithms. The Keyfactor PQC Lab provides a pre-configured environment for issuing hybrid X.509 certificates signed with both RSA/ECC and ML-DSA. This Chimera CA approach ensures that certificates remain valid for classical clients while providing quantum resistance for PQC-capable clients.
5. Python Implementation of ML-KEM for Rapid Prototyping
For developers and security engineers who need to experiment with ML-KEM programmatically, the `py-acvp-pqc` repository provides self-contained Python implementations of FIPS 203, 204, and 205.
Installation and Basic Usage
Clone the repository
git clone https://github.com/mjosaarinen/py-acvp-pqc.git
cd py-acvp-pqc
Install dependencies
pip3 install pycryptodome
Run the self-contained ML-KEM implementation
python3 -c "
from fips203 import ML_KEM
import secrets
Generate key pair (ML-KEM-768)
ek, dk = ML_KEM.keygen()
Encapsulate: generate shared secret and ciphertext
ss, c = ML_KEM.encaps(ek)
Decapsulate: recover shared secret from ciphertext
ss2 = ML_KEM.decaps(dk, c)
assert ss == ss2
print('ML-KEM encapsulation/decapsulation successful!')
"
The `fips203.py` implementation is self-contained and passes all NIST test vectors, making it suitable for understanding the algorithm’s internals and integration testing.
6. Cryptographic Inventory and Migration Planning
The first practical step toward post-quantum readiness is a comprehensive cryptographic inventory. Organizations must map where keys, certificates, and signatures are used across services, libraries, and devices, with particular attention to:
- TLS certificates and keys: Web servers, API gateways, load balancers, and internal service meshes
- Code-signing pipelines: Firmware, software updates, and container image signatures
- Identity systems: JWTs, SAML assertions, OAuth tokens, and FIDO2 passkeys
- VPN and secure tunnels: WireGuard, IPsec, and OpenVPN configurations
- Cloud KMS: AWS KMS, Azure Key Vault, and GCP Cloud KMS key operations
AWS has already enabled ML-KEM automatically in Secrets Manager Agent 2.0.0+, Lambda Extension v19+, and CSI Driver 2.0.0+ as of April 2026. Major cloud providers now support ML-KEM-based asymmetric key operations in preview.
Step-by-step migration framework:
- Discover and inventory: Use automated tools to identify all cryptographic assets and their dependencies
- Prioritize by risk: Focus on long-lived secrets, publicly exposed services, and data with 10+ year confidentiality requirements
- Adopt hybrid cryptography: Deploy dual-stack TLS with classical + PQC key exchange for all new services
- Test and validate: Use OpenSSL 3.5 and liboqs to validate PQC performance and interoperability in staging environments
- Crypto-agile design: Centralize cryptographic decisions in libraries and configuration, avoiding hard-coded algorithm choices
- Phased deprecation: Replace RSA/ECC certificates with hybrid or PQC-only certificates according to NIST IR 8547 timelines
7. Performance Considerations and Operational Impact
Post-quantum algorithms produce larger keys and signatures, requiring more bandwidth and memory. ML-KEM public keys are several times larger than current elliptic curve keys, and signature sizes for some schemes are an order of magnitude larger.
However, performance benchmarks show that ML-KEM-768 encapsulation completes in approximately 2.8 ms compared to 4.1 ms for ECDH key agreement—a 32% latency reduction while providing NIST Level 3 post-quantum security. The primary operational hurdle is payload volume, not computational overhead. Organizations should:
- Test infrastructure for larger handshakes and payload sizes
- Consider ML-KEM-512 for bandwidth-constrained environments
- Use ML-KEM-1024 for the highest-security archival applications
- Implement hybrid modes to minimize disruption during transition
What Undercode Say
- Key Takeaway 1: Classical cryptography (RSA, ECC, Diffie-Hellman) is mathematically vulnerable to Shor’s algorithm on quantum computers. The “harvest now, decrypt later” attack makes this a present-day threat, not a future concern. Organizations must begin migrating long-lived secrets immediately.
-
Key Takeaway 2: ML-KEM (FIPS 203) provides a NIST-standardized, quantum-resistant replacement for key exchange based on lattice mathematics. With OpenSSL 3.5, Python implementations, and cloud provider support now available, practical deployment is achievable today without waiting for perfect interoperability.
Analysis: The cryptographic transition from RSA/ECC to PQC represents one of the largest infrastructure overhauls in the history of computing. Unlike previous cryptographic migrations (e.g., SHA-1 to SHA-2), this transition requires replacing the fundamental mathematical foundations of public-key infrastructure. The timeline is compressed: NIST IR 8547 targets RSA-2048 and ECC-256 deprecation by 2030, with full disallowance by 2035. Organizations that delay inventory and planning face compressed timelines, uncontrolled dependencies, and increased operational risk. The hybrid deployment model—combining classical and post-quantum algorithms—provides the safest migration path, preserving backward compatibility while building quantum resistance incrementally. Crypto-agility, the ability to swap cryptographic algorithms without rewriting applications, has transitioned from a best practice to a baseline requirement.
Prediction
- +1 By 2028, hybrid TLS with ML-KEM will become the default configuration for major cloud providers and CDNs, making post-quantum key exchange transparent to most internet users without application changes.
-
+1 The first production ransomware campaign using post-quantum encryption has already been observed in March 2026, signaling that attackers are adopting PQC faster than many defenders. This will accelerate enterprise migration timelines by 12–18 months.
-
-1 Organizations that fail to complete cryptographic inventory by 2027 will face significant operational disruption as certificate lifetimes shorten and regulatory compliance deadlines approach.
-
-1 The performance overhead of PQC—particularly larger certificate chains and handshake payloads—will cause unforeseen latency issues in latency-sensitive applications, requiring architectural redesign for microservices and edge computing.
-
+1 NIST’s selection of HQC for standardization in March 2025 provides a second lattice-based KEM option, increasing cryptographic diversity and reducing single-algorithm dependency risk for high-security deployments.
▶️ Related Video (72% Match):
https://www.youtube.com/watch?v=-fA-BduJT5Q
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Dhari Alobaidi – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
