Not all RSA is equal: quantifying harvest-now-decrypt-later exposure

Ask any scanner on the market to rank your migration and it will hand you a list sorted by severity or by count. Both are blind to the thing that actually determines urgency. An elliptic-curve handshake in front of a public status page and the same handshake protecting a database of twenty-five-year-retention health records are identical findings to every tool we have seen. They are not the same risk, and pretending they are is why migrations stall on the wrong work.

Exposure, made concrete

We compute an exposure score for each finding as the product of three factors, each between zero and one, scaled to a 0 to 100 number:

• Vulnerability (V): how exploitable and how harvest-relevant the finding is, from its severity and the scanner's confidence, discounted for findings (like signatures) where harvest-now-decrypt-later does not apply.
• Sensitivity (S): the classification weight of the data the finding protects, from public through internal and confidential to regulated.
• Mosca margin (M): (X + Y - Z) / (X + Y), where X is how long the data must stay secret, Y is your migration time, and Z is the years until a capable quantum computer. M greater than zero is exactly Mosca's inequality breached: the data will still be sensitive, under old cryptography, when the machine arrives.

The Mosca factor is what makes the score defensible to a CISO. It says, in one number, that this particular data's confidentiality outlives the window in which you can protect it, which is the entire argument for spending on the migration this year instead of next.

You declare the data, we do the join

The crypto side of the join we already had: the config-scope detectors know where data rests (key stores, secrets at rest, database encryption, message brokers, JOSE and JWE). What was missing was the data side, and only you can supply it. A small `hndl.yml` declares your data assets, each with a classification, a retention period, a secrecy lifetime, and the path globs it covers. Run `qscan ./ --hndl` and each finding is bound to the asset it protects and scored; `qscan hndl init` scaffolds the file, seeding it with the data-adjacent findings the scanner already sees, so you start from a draft rather than a blank page.

Ranking the backlog by risk

Once exposure lands, the inventory and the migration board can sort by it, so the work at the top of the list is the work that reduces real risk fastest. At the organization level, the summary answers the question a board actually asks: how many of our assets hold data whose confidentiality outlives the migration horizon, and what is our worst exposure. That is a sentence a CISO can take upstairs, and it is a very different conversation from "we have 400 findings."

The same finding is trivial on a brochure and catastrophic on a decade of records. Only the data knows which, so we asked the data.

This operationalizes the thesis the whole practice rests on: you cannot predict when a quantum computer arrives, but you can measure how long your secrets must last and migrate the ones that outlive the machine first. The exposure model is documented, so the number is contestable rather than magical. Start by declaring one asset and scanning: npx @quantakrypto/qscan ./ --hndl

References

• Mosca's theorem and harvest-now-decrypt-later - the X + Y greater than Z inequality the exposure score makes concrete.
• Harvest now, decrypt later (Wikipedia) - the adversary model.
• The readiness standard - where data-protection practices sit in the maturity model.