Case Study 2: The Deadline That Already Passed

DataField.Dev

Case Study 2: The Deadline That Already Passed

The meeting

A security team is asked when they need to migrate to post-quantum cryptography. They do the obvious research and arrive at a defensible answer.

The machine does not exist. RSA-2048 needs roughly 25 million physical qubits running for a day and a half (§23.6). The largest devices today have around a thousand physical qubits, with no error correction at scale.

That is four to five orders of magnitude.

Expert estimates for closing that gap cluster somewhere in the 2030s, with wide error bars. The team's conclusion: revisit in five years. Their systems have a normal refresh cycle, post-quantum algorithms are still being standardized and will be better supported later, and migrating early means migrating twice.

Every step of that reasoning is sound. The conclusion is wrong, and the error is in what question they answered.

The question they answered

"When will a quantum computer be able to break our encryption?"

The question that decides the deadline

"How long does data we transmit today need to stay secret?"

Encrypted traffic can be captured now and decrypted later. An adversary who records ciphertext today needs no quantum computer today — they need one before your data stops being sensitive.

This is harvest now, decrypt later, and it inverts the timeline:

$$\text{migration deadline} = (\text{arrival of the machine}) - (\text{data confidentiality lifetime})$$

Not "when does the machine arrive." Minus how long your data matters.

Working it out

Suppose the machine arrives in 2040 — deliberately conservative relative to most estimates.

   data must stay secret for   safe to transmit until   migrate by
                     5 years                     2035        2035
                    10 years                     2030        2030
                    20 years                     2020        ALREADY PASSED
                    30 years                     2010        LONG PASSED

For anything with a twenty-year confidentiality requirement, the deadline is in the past.

And plenty of data has that lifetime:

medical records — a lifetime, and beyond it for genetic information
government and diplomatic communications — routinely classified for decades
legal and financial records — statutory retention often exceeds twenty years
industrial and pharmaceutical R&D — patent horizons plus development timelines
identity documents and biometrics — not revocable

Session cookies and quarterly earnings do not have this problem. Genomic data does.

Why "revisit in five years" fails specifically

The team's plan assumed the migration decision could be deferred without cost. It cannot, for traffic already in flight.

Every day of delay adds another day of ciphertext to whatever an adversary is storing. Migration protects future traffic; it does nothing for traffic already sent. So the cost of waiting is not "we migrate later" — it is "an additional five years of our most sensitive communications are permanently exposed to a future decryption."

That cost is incurred now and paid later, which is exactly the structure that makes it easy to under-weight.

The counter-arguments, taken seriously

"The machine may never arrive." Possible. But §23.7 measured that the algorithmic side is settled — Shor is polynomial, GNFS is sub-exponential, and at 2048 bits that is $2^{33}$ against $2^{117}$. The gap is manufacturing and fidelity, which is the kind of gap that has historically closed. Betting against it for thirty-year data is a large bet.

"Estimates keep changing." They do, and Chapter 15 Case Study 1 noted the direction: Gidney and Ekerå's 20-million-qubit figure was more than an order of magnitude below earlier estimates, achieved entirely through better constructions rather than better hardware. The number has moved downward. A forecast built on today's resource estimate is built on a quantity that has only ever gotten smaller.

"Post-quantum algorithms are immature." This was a much better argument before standardization. It remains true that the algorithms are younger than RSA and have had less cryptanalysis — which is a real risk, and the standard response is hybrid deployment: run a post-quantum key exchange alongside a classical one, so an attacker must break both. That removes most of the "what if the new algorithm is flawed" objection at modest cost.

"Migrating twice is wasteful." True, and cheaper than the alternative for long-lived data. It is also less likely than it sounds — hybrid deployments are designed to be swapped.

What the team should have produced

Not a date. A data inventory sorted by confidentiality lifetime.

   1. What do we transmit, and how long must each class stay secret?
   2. Which of those classes are already past their deadline?
   3. Migrate those first, hybrid, now.
   4. Everything else follows the normal refresh cycle.

That is a tractable afternoon's work, and it produces an ordering rather than a date — which is the right shape of answer, because the input (when the machine arrives) is genuinely unknown while the other input (how long your data matters) is something you already know.

And the ordering is robust to the uncertainty. It does not matter much whether the machine arrives in 2035 or 2045; it matters enormously whether a given data class has a two-year or a thirty-year lifetime. The team was uncertain about the parameter they could not control and confident about the one they had not measured.

What this does not say

It is not "panic." Most traffic genuinely does not need protection for twenty years, and for that majority the normal refresh cycle is the right answer.

And Grover is not part of this argument. Chapter 21 §21.7: symmetric encryption loses half its key strength, which doubling the key length answers completely. AES-256 is fine. The urgency here is specific to public-key cryptography — RSA, Diffie–Hellman, and ECC — which Shor does not weaken but breaks, with no key-length response available because the algorithm is polynomial in key length.

Use AES-256. Migrate the public-key layer. Prioritize by data lifetime.

The lessons

Answer the question that determines the decision, not the one that sounds relevant. "When does the machine arrive" feels like the crux and is only one term in the expression.

Costs incurred now and paid later are systematically under-weighted. Every day of delay permanently exposes another day of traffic, and nothing about that cost is visible when it is incurred.

Sort by the parameter you know. Data lifetime is knowable today; the arrival of the machine is not. An ordering built on the knowable parameter is robust to uncertainty in the other.

Hybrid deployment dissolves the maturity objection at modest cost, which removes the strongest practical reason to wait.

And the resource estimate has only ever moved downward — which means a plan calibrated to today's figure is calibrated to an upper bound, not a fixed point.

Reproduce it: code/example-03-where-the-cost-is.py computes the resource requirements and the GNFS comparison the timeline rests on; Chapter 38 covers the migration itself.