Harvest-Now-Decrypt-Later, Brought to You by DEFAULT

Good news: nobody has a cryptographically relevant quantum computer yet. Shor’s against RSA-2048 still wants more error-corrected qubits than anyone has shipped, and the public roadmaps remain firmly in “soon” territory. Pop the champagne — your AES-256 backups are safe. For now.

The “for now” is doing the heavy lifting, of course, which is why the responsible adults have spent the last few years rolling out hybrid post-quantum key exchange like X25519MLKEM768 to defang harvest-now-decrypt-later. AWS is visibly doing the work: Secrets Manager now negotiates hybrid X25519+ML-KEM on a simple client-side bump (Agent 2.0.0, Lambda extension 19, recent SDKs), and they’ve even shipped Cachee, a Rust in-process cache built specifically to swallow the new oversized PQC keys — because ML-KEM-1024 publics are 1,568 bytes versus ECDH’s 32, SLH-DSA-256f signatures are nearly 50 KB, and Redis was choking on 0.9 ms reads for a 17 KB signature. The migration is real and the engineering is impressive.

And then CVE-2026-2673 lands. If your OpenSSL 3.5 or 3.6 server config uses the DEFAULT keyword in its groups list, an implementation bug flattens the tuple structure, the server skips the Hello Retry Request, and the handshake quietly settles for whatever classical curve the client led with. No error, no warning — just a harvestable session and a future quantum adversary sending you a thank-you card. Upgrade to 3.5.6 / 3.6.2 the moment they ship, audit anything using DEFAULT, and remember the eternal lesson of crypto migrations: the algorithm is almost never the weakest link. The config is.