Formalize Quantum Top 10 entry template - #40
Conversation
|
This is a constructive direction. Simplifying and streamlining conventions used in existing entries rather than adding burdens. On QS05, I have two observations. The now-formalised "Standards and Regulatory Mapping" section addresses an open question I've raised in #35, whereby QS05 previously listed this mapping as a "TODO" marked as "not yet included in _template.md." Moreover, on "Evidence". A single risk in the migration domain might simultaneously span across a couple of maturity levels. QS05, for instance. It indicates that failures caused by hard-coded algorithms are already detected, meanwhile the likelihood for future parameter-set breaches remains an emerging/theoretical concern. Therefore, will this classification be applied on per entry basis? And can a single entry represent a primary level while incorporating nuances specific to individual examples? Happy to stand behind whichever decision is made. |
|
Flagging something before this goes further, rather than leaving it for review to catch. #18 independently built Yours is the more complete version - it's part of a full template revision with Scope, Detection, and Related Risks alongside it, rather than a standalone document, and it already has the "author guidance" tie-in the standalone version doesn't. I'd rather defer to this one than have two conventions asking to both be canonical. Once #40 lands I'll drop the evidence-convention file from #18 and keep only what doesn't overlap - the One question worth raising here since it affects both: your classification guidance separates the attack class from every step needed to exploit it, with the HNDL example landing on "Demonstrated, with a note about CRQC dependency" as the overall classification. That's a judgment call - CRQC-dependent risks could just as reasonably be read as the CRQC dependency capping the classification rather than being a footnote on it. Worth the leads confirming which reading is intended, since it decides how most of QS01-QS07 get tagged. |
|
On the same page with m-khan-97. It converges with the Evidence question I asked above. Both went down to one call the leads urge to make. Whether a single Evidence tag classifies the attack class, as demonstrated with the CRQC dependency noted. Or whether the CRQC dependency caps the tag outright, and whether one entry may carry a primary tier with per-example nuance. That decision will, I strongly think, determine how QS01 to QS07 are tagged. In short, it's worth settling before #40 lands rather than per entry afterwards. |
|
Weighing in as a contributor; the call here is the leads'. The housekeeping half looks settled: #18's The substance, the CRQC-capping question, is the real decision, and I don't read it as closed: m-khan-97 flagged it himself as a judgment call, and both readings are coherent. One observation that might help. The binary in the question, a single tag for the class versus the CRQC dependency capping the tag, may be a false choice, because HNDL is asymmetric. The collection capability is readily available today, while decryption is gated on a CRQC that does not exist. A single "demonstrated" tag risks reading as "decryption is demonstrated," which it is not, and that is the legitimate worry behind capping: not overstating that the quantum consequence is realizable. But capping the entry to theoretical has the opposite cost: it hides that the collection exposure is live now and that the mitigation, protecting the data now, is warranted now. #18's own phrasing already threads this without a global rule: "demonstrated as collection; the decryption step is not," with the distinction stated in the entry text. That scopes the qualifier inside the tag rather than resolving it by either a class-level tag or an outright cap. If the leads want one convention for QS01 through QS07, that qualify-in-the-tag pattern looks like the option that keeps the tag honest without dropping the live-collection signal. But that is a judgment for the leads, and either of the other two readings is defensible. If useful, I'm happy to stress-test whichever wording you settle on against the migration-domain entries, including the downgrade/fallback one I've worked on, which carries one demonstrated failure mode and one CRQC-gated one in a single entry. That is the same shape as goubach's QS05 point (hard-coded-algorithm failures detected today, future parameter-set breaks staying emerging/theoretical). |
|
The qualify-in-the-tag reading answers the question I've brought into the table above. To be honest, it looks like the cleaner way through. A primary tier is carried by the entry, with the point where that tier stops stated plainly rather than left implied. Let me try it on QS05, since @ossumpossum flags it as the same shape. Evidence: Demonstrated as an agility failure. The parameter-set break that would force the rotation is emerging. Hard-coded algorithms, untested rotation paths, non-updatable firmware. All of them are observed today, and none needs a CRQC at all. What's still emerging is the trigger. If QS05 is classified as emerging, a failure mode that is already costing organisations time goes unnoticed. Tag it demonstrated with no qualifier, and how soon the forcing event turns up gets rather overstated. Eager to stress-test the pattern across the migration-surface entries alongside @ossumpossum if the leads go this way. |
|
This is exactly the reading I had in mind when I wrote it that way in #18, and seeing it work cleanly on QS05 and QS06 as well as HNDL is a good sign it's a pattern, not a one-off fix. The reason I'd push for qualify-in-the-tag over either alternative: the whole point of tagging demonstrated/emerging/theoretical is to make urgency legible, and QS01 closes on "the risk is concrete now, not contingent on quantum hardware availability." A single cap to theoretical buries that. A single tag of demonstrated with no qualifier overclaims the part that actually depends on a CRQC. The qualifier is what lets the tag be honest in both directions at once, which a binary choice can't do. I went ahead and checked it against the rest of the migration surface rather than just agreeing in the abstract. Three shapes show up, not one: Clean two-part split, same as HNDL - structural exposure demonstrated now, exploitation gated on a CRQC. QS07 fits this exactly: a device with no re-anchoring path is a demonstrated fact today; forging a signature against its stuck anchor needs Shor's algorithm. QS03's Mosca-based content (long-lived signed artefacts already failing X+Y>Z) is the same shape read against integrity instead of secrecy. No CRQC dependency at all, in content sitting inside an otherwise CRQC-gated entry. QS06's implementation-risk layer - KyberSlash, Clangover - is a classical timing attack recovering an ML-KEM key on conventional hardware. No CRQC anywhere in the chain. Same entry's negotiation-risk layer is the two-part HNDL shape above. That's two different evidence textures in one entry, not one tag plus one qualifier. QS03 has the same problem from the other direction: the re-establishment-failure paragraph (a migration accepting weak proof-of-possession during re-issuance) isn't CRQC-gated either - it's exploitable classically, any time, and only exists because a migration is happening. A single entry-level tag can't honestly cover a layer that needs the qualifier and a layer that doesn't need one at all. A future-break dependency that isn't quite CRQC-shaped. QS05's split, as goubach worked it, is hardcoded-algorithm failures demonstrated now versus a parameter-set break that's emerging. But that trigger isn't "wait for a CRQC" - it's "wait for any break, quantum or classical." Worth naming as its own texture rather than folding it into the CRQC-qualifier pattern, since the uncertainty is a different shape. And QS04 is the cleanest case of all in the other direction: nothing in it depends on a CRQC at any point. Absence of inventory is a demonstrated, present-day organisational failure, full stop - a flat tag, no qualifier machinery needed. Net: the convention needs to support tagging below the entry level, at least for QS03 and QS06, because a single primary tier plus one qualifier can't represent two genuinely different evidence textures inside the same entry. That's a stronger version of the "primary tier with per-example nuance" question you raised, goubach - based on what's actually in these entries today, at least two of them need it, not just permit it. Happy to write this up as a short table (entry, texture, worked example) if that's more useful to the leads than prose. |
|
Spot on. QS05 isn't CRQC-shaped. That distinction matters more than the tag I proposed. The trigger there is a parameter-set break that can land at any time and owes nothing to quantum hardware. Labelling it a CRQC qualifier would have smuggled in a timing assumption the entry can't support. In addition, the sub-entry point is the sharper version of what I was circling. If QS03 and QS06 carry two evidence textures in one entry, a single tier plus a qualifier, to be honest, can't represent that, and pretending otherwise just moves the fudge somewhere less visible. Feel free to write the table. Entry, texture, along with worked examples, are exactly the kind of shape the leads need to decide from, and prose won't carry five cases as clearly. QS05 is yours to use as the future-break row if that helps. |
|
Thanks all, great input. One possible approach would therefore be to apply the Evidence classification at the level of materially distinct technical claims, attack classes, or failure classes, rather than necessarily to the entry as a whole. For example, QS05 could contain something along these lines: Evidence
So rather than classifying QS05 itself as "Demonstrated", we would distinguish the evidence maturity of materially different aspects of the risk. However, I also see a disadvantage with this approach. We risk making the Evidence section too granular and burdensome. It may become unclear what constitutes a separate claim that deserves its own classification, and different authors could choose very different levels of granularity. In the extreme, we could end up classifying individual examples rather than providing a concise Top 10 entry. There is also a subtle distinction between the maturity of the risk/failure itself and the maturity of a future trigger or scenario. A non-agile system, for example, can be a demonstrated engineering failure today even if the cryptanalytic development that eventually forces an emergency migration has not occurred yet. We should avoid introducing false precision by mixing those concepts. Most importantly, I think the Evidence section should remain actionable for the reader. The classification should help someone understand which aspects of a risk are already supported by practical evidence, which are still emerging, and where assumptions or future dependencies exist so that this information can inform prioritisation, architecture decisions, mitigation and further investigation. If the classification becomes too granular to support those decisions, we are probably adding complexity without much practical value. Perhaps the principle should therefore be:
This would preserve the simplicity of the Top 10 while allowing nuance where it actually improves understanding and actionability. What do you think? |
|
Weighing in as a contributor; the call here is the leads'. +1 to classifying at the level of materially distinct claims where it helps, and to the principle as worded. To make your "relevant to the reader's security decisions" clause operational and give the split a stopping point: separate a claim out only when a different classification would change what a defender does about it (prioritization, architecture, or mitigation); otherwise fold it back under the entry-level tag. That keeps "materially distinct" a reader-decision test rather than author taste, which is the part most likely to drift between authors and slide toward per-example over-classification. Your risk-vs-trigger distinction is the one I'd most want stated explicitly, since it's a common false-precision trap: classify the maturity of the weakness itself, not the maturity of a hypothetical future event that would exploit it. A non-agile system is a Demonstrated engineering failure today; the cryptanalytic break that eventually forces migration is a separate, Emerging trigger. Tagging the weakness by its trigger's maturity understates present, actionable risk. One way to encode it: classify the weakness, and if a future trigger matters, describe its maturity in the entry text rather than letting it set the tag. If useful, I'm happy to stress-test whichever wording you settle on against the migration-domain entries, including the downgrade/fallback one I've worked on: it pairs a demonstrated coercion mechanism (downgrade/fallback, cf. FREAK/Logjam) with a CRQC-gated decryption step, so it exercises exactly this Demonstrated-plus-Future split in one entry. |
4 participants
Formalize the Quantum Security Top 10 Entry Template
Summary
This PR updates the Quantum Security Top 10 entry template to formalize conventions that have already emerged during the development of the v0.1 entries and the subsequent community discussions.
The goal is not to increase the amount of content required for each entry, but to improve consistency, clarify scope boundaries, and make the guidance more useful for practitioners.
This PR follows the discussion in #15 and incorporates subsequent community feedback.
Motivation
While reviewing the current Top 10 entries, several concepts repeatedly appear despite not being part of the current template.
Examples include:
Rather than leaving these as ad hoc additions, this PR incorporates them into the common authoring template.
The changes are intended to codify conventions that are already emerging across the project rather than introducing entirely new concepts.
Proposed Changes
Scope
Introduce an explicit Scope section to clearly define what an entry covers and, where useful, what it explicitly does not cover.
This helps reduce overlap between entries and makes the taxonomy more consistent.
Evidence
Introduce an Evidence section together with a common evidence convention.
Each entry classifies the maturity of the attack class using one of:
The detailed definitions are maintained in a separate
EVIDENCE.mddocument to keep the Top 10 concise while ensuring consistent classification across entries.Detection
Introduce a Detection section describing practical ways organisations can determine whether they are exposed to the risk.
Examples include:
Mitigation Guidance
Clarify that, where practical, mitigations should be:
The intention is to encourage engineering-oriented guidance while leaving detailed verification procedures to future supporting guidance rather than the Top 10 itself.
Standards & Regulatory Mapping
Formalize this section within the template.
Every current migration entry already contains standards and regulatory mapping, making it a de facto part of the project. Including it in the template improves consistency and strengthens the usefulness of the Top 10 for regulated industries.
Related Risks
Introduce a Related Risks section allowing entries to reference adjacent Quantum Security Top 10 risks and briefly explain the relationship.
This improves navigation and helps clarify scope boundaries.
Benefits
These additions make the Top 10:
Non-goals
This PR intentionally does not rewrite the existing Top 10 entries.
The revised template can be adopted incrementally as entries continue to evolve.
Related Discussions
This PR implements the template improvements discussed in #15.
The proposed evidence field is designed to work together with a separate evidence convention, should the project decide to adopt one.