Quantum computing is no longer a theoretical curiosity confined to physics labs. With billions in investment flowing from governments and tech giants worldwide, cryptographically relevant quantum computers (CRQCs) — machines capable of breaking today's public-key cryptography — are projected to arrive within the next 10 to 15 years. Some threat models suggest even sooner.
But here's the uncomfortable truth: you don't need to wait for quantum computers to become a victim of quantum attacks. The threat is already active today.
Nation-state actors and sophisticated adversaries are already executing what the security community calls Harvest Now, Decrypt Later (HNDL) attacks. The strategy is straightforward and chilling:
For any data that retains value over years — trade secrets, medical records, financial data, government communications, intellectual property — the window for protection isn't when quantum computers arrive. It's right now.
The Cloud Security Alliance has identified HNDL as one of the most significant near-term quantum threats facing enterprises. Palo Alto Networks has likewise categorized it as a "present-day risk" that requires immediate mitigation, not future planning.
In August 2024, NIST (the U.S. National Institute of Standards and Technology) took a historic step by releasing the first three finalized post-quantum cryptography standards after an eight-year standardization process:
Among these, ML-KEM is the standard directly relevant to protecting data in transit — it provides quantum-resistant key encapsulation for use in protocols like TLS.
The mathematical hardness of ML-KEM is based on the Module Learning With Errors (MLWE) problem over structured lattices — a problem that remains computationally infeasible for both classical and quantum computers. Unlike RSA and ECC (which rely on integer factorization and discrete logarithm problems easily broken by Shor's algorithm), lattice-based cryptography has no known efficient quantum attack.
Rather than replacing classical cryptography overnight — which would introduce risks from immature implementations or undiscovered weaknesses in new algorithms — the industry has converged on a hybrid approach:
Combine a classical (proven) key exchange with a post-quantum key exchange in a single handshake. The resulting shared secret is secure as long as either component remains unbroken.
The specific hybrid construction gaining universal adoption is:
X25519MLKEM768 = X25519 (classical ECDH) + ML-KEM-768 (post-quantum KEM)
This means:
The IETF has standardized this hybrid key exchange for TLS 1.3 in draft-ietf-tls-ecdhe-mlkem, and major browsers have already shipped support.
Here's where it gets interesting for practitioners. While post-quantum cryptography might sound like something that requires complex migration projects and infrastructure overhauls, Alibaba Cloud ESA (Edge Security Acceleration) has made it a zero-configuration default.
ESA natively integrates X25519MLKEM768 hybrid key exchange across its global edge network. When a client that supports post-quantum key exchange connects to an ESA-accelerated site:
X25519MLKEM768 in its supported_groups extensionThe entire process is transparent — no configuration changes, no certificate replacements, no origin server modifications required.
ESA's post-quantum encryption works with:
Both protocols benefit automatically from post-quantum key exchange when clients support it.
Post-quantum hybrid key exchange is supported by all major modern browsers:
| Browser | Version | Status |
|---|---|---|
| Google Chrome | 131+ | Enabled by default |
| Microsoft Edge | 131+ | Enabled by default |
| Mozilla Firefox | 132+ | Enabled by default |
This means the majority of global web traffic from modern browsers is already capable of post-quantum key exchange. As older browser versions cycle out, coverage will approach 100% organically — without any action required from site operators.
You can verify post-quantum encryption is active on your ESA-accelerated site through two methods:
Browser DevTools:
Open Chrome/Edge DevTools → Security tab → Check the connection details. You'll see X25519MLKEM768 listed as the key exchange mechanism.
Command Line:
curl -vso /dev/null https://your-domain.com 2>&1 | grep -i mlkemIf the output includes X25519MLKEM768, your connection is post-quantum protected.
Traditional security upgrades often require months of planning, testing, and staged rollouts. ESA's approach is fundamentally different — post-quantum protection is a platform capability, not a feature you deploy. The moment your site is accelerated through ESA, all client connections that support PQC automatically receive post-quantum key exchange.
Any data transmitted over an ESA-protected connection using X25519MLKEM768 is immune to future quantum decryption. Even if an adversary captures the encrypted traffic today, the quantum-resistant key exchange ensures they cannot derive the session keys — not now, and not when quantum computers mature.
Regulatory bodies are beginning to mandate quantum-readiness timelines:
By leveraging ESA's built-in PQC capability, organizations gain a measurable compliance data point: "All data in transit to end users is protected by NIST-standardized post-quantum hybrid key exchange."
While post-quantum encryption benefits all web properties, certain sectors face amplified urgency:
Financial Services — Transaction data, customer records, and inter-institution communications retain value for decades. HNDL attacks today could expose sensitive financial data in the future.
Healthcare — Medical records have essentially infinite sensitivity lifetime. Patient data harvested today remains exploitable regardless of when decryption becomes possible.
Government and Defense — Classified and sensitive government communications are prime HNDL targets for nation-state adversaries who invest heavily in long-term intelligence gathering.
Intellectual Property — Companies with high-value trade secrets, R&D data, or competitive intelligence face significant risk from patient adversaries willing to wait years for decryption capabilities.
Automotive and IoT — Connected vehicles and IoT devices deployed today will operate for 10-20 years. Securing their communication channels against future quantum threats is essential during the design phase, not after deployment.
For those interested in the cryptographic details, here's how the hybrid construction works within a TLS 1.3 handshake:
The client generates two independent key pairs:
The client sends both public components concatenated in the key_share extension:
key_share_entry {
group: X25519MLKEM768 (0x4588)
key_exchange: X25519_public (32 bytes) || MLKEM768_encaps_key (1184 bytes)
}Total client key share size: 1,216 bytes (compared to 32 bytes for X25519 alone).
The server:
Total server key share size: 1,120 bytes.
The final shared secret is derived by concatenating both component secrets:
shared_secret = MLKEM768_shared_secret (32 bytes) || X25519_shared_secret (32 bytes)This combined 64-byte secret feeds into TLS 1.3's HKDF-based key schedule to derive the actual encryption keys.
The additional computational cost is minimal on modern hardware:
The slightly larger handshake messages are the only observable difference, and they remain well within typical MTU sizes for a single packet in most network conditions.
Post-quantum encryption is one component of ESA's comprehensive security architecture that also includes:
Post-quantum key exchange integrates seamlessly with all of these — it protects the transport layer while other security features protect the application layer. Together, they form a defense-in-depth posture that addresses both present-day and future threats.
If your site is already on Alibaba Cloud ESA, post-quantum encryption is already active for all clients that support it. There is nothing to configure, enable, or deploy.
If you're evaluating ESA, the built-in post-quantum capability represents a forward-looking security differentiator that requires zero operational overhead — protecting your users' data not just against today's threats, but against tomorrow's quantum-powered adversaries.
The quantum clock is ticking. The good news? Your edge defense is already ahead of it.
References:
4 posts | 1 followers
FollowBryan, Zhang - May 20, 2026
ESA-bigfan-Fred - June 5, 2026
Bryan, Zhang - May 28, 2026
ESA-bigfan-Fred - May 14, 2026
ESA-bigfan-Fred - May 14, 2026
Kidd Ip - September 15, 2025
4 posts | 1 followers
Follow
Cloud Hardware Security Module (HSM)
Industry-standard hardware security modules (HSMs) deployed on Alibaba Cloud.
Learn More
Edge Security Acceleration (Original DCDN)
Edge Security Acceleration (ESA) provides capabilities for edge acceleration, edge security, and edge computing. ESA adopts an easy-to-use interactive design and accelerates and protects websites, applications, and APIs to improve the performance and experience of access to web applications.
Learn More
CDN(Alibaba Cloud CDN)
A scalable and high-performance content delivery service for accelerated distribution of content to users across the globe
Learn More
Security Center
A unified security management system that identifies, analyzes, and notifies you of security threats in real time
Learn More