“Harvest now – Decrypt later”
You’ll hear this phrase come up almost every time post-quantum readiness enters the conversation, and for good reason.
If we focus on the “Harvest Now” part – where exactly is your PII getting harvested, why it could be decrypted later, and what you can actually do about it – we’re already most of the way there. Because if we make the encryption harder to break, the “Decrypt Later” part becomes a lot less relevant. Attackers may still harvest the data today, but making future decryption harder is very much something we can work on right now.
Where in traffic flow exactly is your PII could get harvested
One way to capture the PII data is capture the data on the wire for web apps. Financial web apps, for example would transmit PII potentially and that would be available to be harvested in below points over the internet.
- Between user and CDN (e.g. Cloudflare/Akamai/F5 Distributed cloud)
- Between CDN and the Load Balancers at the datacenter (e.g. F5 LTM /Citrix) or the Cloud (AWS/Azure)
- Between the user and the load balancer directly — for applications not fronted by a CDN
Why the harvested data is vulnerable
These TLS connections use classical key exchange ECDH or RSA, which quantum computers can break using Shor’s algorithm.
What you can do about it?
Scan your external facing networks. Ensure your TLS inspection points – CDNs and load balancers support TLS 1.3 with ML-KEM, the NIST post-quantum standard. Cloudflare already supports it by default. F5 BIG-IP supports it from version 17.5.1.
How to quickly check if your CDN/Origin is quantum compatible from the browser
Open your website in Chrome. Then Open Dev tools > Security tab > Click on thwe website unde “Main Origin”.
Specifically look for X25519MLKEM768 in the key exchange. That’s the hybrid post-quantum key exchange.
| Key exchange [not post quantum ready] |
 |
| Key exchange [post-quantum ready with X25519MLKEM768 ] |
 |
Testing using OpenSSL
You can verify this with openssl – swap in any domain you want to check.
openssl s_client -connect <your-domain>:443 -tls1_3 -groups X25519MLKEM768:X25519:P-256 </dev/null 2>&1 | grep -E "Protocol|Temp Key|group|Cipher is"
The first example above comes back with X25519MLKEM768 (highlighted in green), which means post-quantum key exchange is happening. the second example comes back with plain old ECDH, prime256v1(highlighted in red). Both are on TLS 1.3, but one is more post-quantum ready than the other.
In the first example, both client and server supported ML-KEM, so it negotiated ML-KEM. In the second, the client supported it but the server didn’t, so it fell back to classical ECDH.
Note: ML-KEM negotiation may require a newer OpenSSL build, for example 3.5. Older versions may not reproduce these results. See my repo for setup details.
If this interests you, dear reader, please check out more here: https://ashishmgupta.github.io/pqr-research/index.html
Ashish Gupta 