deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Post-quantum crypto migration stalls on endpoint inventories, not algorithms, dev.to post argues

A dev.to essay argues that standardized post-quantum algorithms are the easy part: the real work is inventorying every endpoint that terminates a handshake and cannot be updated, from load balancers to forgotten firmware.

Post-quantum crypto migration stalls on endpoint inventories, not algorithms, dev.to post argues

The algorithms were the easy part

A post on dev.to argues that post-quantum cryptography migration has a deceptive shape: the technically hard work is largely finished. Algorithms have been standardized, libraries shipped, and browser vendors have already rolled out hybrid key exchange. What remains, according to the author, is inventory — locating every endpoint that terminates a cryptographic handshake and was built on the assumption that the algorithm would never change. That collection spans load balancers, service meshes, VPN concentrators, industrial gateways and device firmware installed years ago that no one still holds credentials to update.

Two migrations at different speeds

The post describes two migrations running at very different speeds. At the edge, things move quickly: browsers have shipped hybrid key exchange, major CDNs have turned it on, and the fraction of TLS handshakes negotiating a post-quantum key agreement has already reached double digits and keeps climbing. Inside the perimeter, internal services, device fleets and code-signing chains advance on procurement timelines rather than library release cycles.

That divergence is where the risk lives, the author writes. A system's post-quantum security is capped by its weakest link — frequently a device still speaking TLS 1.2 to a broker nobody owns — and the widening gap between edge and interior is the period during which harvesting traffic now to decrypt later is a worthwhile attack.

The cost is bytes, not cycles

Performance arguments about the new algorithms are, in the author's view, mostly a distraction. On modern hardware, the CPU cost of ML-KEM and ML-DSA sits close enough to elliptic-curve operations that it vanishes into per-request noise. The size penalty does not: public keys, signatures and ciphertexts are all substantially larger than their elliptic-curve counterparts, and the difference shows up in the handshake, the certificate chain and packet counts.

Signature size is the painful one. The author notes that a chain carrying three post-quantum signatures can add several kilobytes to a handshake — no rounding error on a lossy mobile link, where it means extra round trips, retransmissions and measurably worse time-to-first-byte for users on the worst connections. Hence the recommended ordering: key exchange first, signatures second. Key exchange appends a bounded amount of data to a handshake you were performing anyway; signatures bloat a chain that every client, including the old ones, has to validate.

Firmware signing is where incidents will land

The author expects the serious incidents to come from code signing and firmware update chains. A typical chain pairs a root key with a ten-to-twenty-year life and a signing key rotated yearly, with a verifier burned into hardware that cannot be changed. Migrating it requires either a device that supports algorithm agility or a dual-signing window long enough to outlive the fleet — and most fleets have neither. The predictable outcome, the author writes, is an installed base able to accept only signatures from algorithms that will eventually be regarded as broken, a situation compared to SHA-1 deprecation except that the devices sit in factories and the replacement cycle is measured in decades.

A recommended sequence

The post's advice is to start with measurement rather than surveys: a week of passively observing handshake metadata at egress points beats a quarter of asking teams, who genuinely do not know what their predecessors deployed. Next, classify endpoints by whether they can be updated at all; anything that cannot is a candidate for network isolation and compensating controls, not a migration deadline. And before enabling post-quantum signatures, measure the byte cost against the real user population — CPU headroom is rarely the problem, while users on weak connections reveal the truth quickly.

On hybrid versus pure post-quantum deployments, the author treats hybrid as the correct default for the next few years, since it covers weaknesses in the new algorithms and preserves interoperability, at roughly additive byte cost. The choice is per-link rather than organization-wide: a consumer-facing edge may already support pure post-quantum, while an industrial protocol stack may not get there until around 2032. The author also estimates, without publishing figures, that professional-services spending on inventory and remediation will run several times larger than software licence spending for at least five years.

Why it matters

The piece reframes post-quantum migration from a cryptography problem into a fleet problem, and the lesson generalizes. Writing the new code is a sprint; retiring the old algorithm is capped by whatever device in the fleet is hardest to update. The question for any standards transition is not whether an organization can implement the new scheme, but whether it can retire the old one everywhere — and for most, the honest answer is no. Starting inventory work now, before deprecation dates push it onto the critical path, is what separates a controlled migration from an audit finding.

  • #cryptography
  • #security
  • #tls
  • #post-quantum
  • #infrastructure

Related posts