Post-Quantum Readiness – A network perspective

“Harvest now – Decrypt later”
This is the phrase almost here as a concern when discussing post-quantum readiness.

If we focus on “Harvest now” part and understand where exactly is your PII getting harvested, why It could be decrypted later and what can you actually do about it – we are most likely to be a lot ready for post-quantum period.

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?
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 from version 17.5.1. The gap for most organizations is the origin side.

How to check if your CDN/Origin is quantum compatible from browser
Open your website in Chrome. Then Open Dev tools > Security tab.
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]

More details here : https://ashishmgupta.github.io/pqr-research/index.html

Leave a comment