From ceacc6e1720a4c6b993062941f502d7423d8ec3c Mon Sep 17 00:00:00 2001 From: m-khan-97 Date: Fri, 7 Aug 2026 18:02:33 +0100 Subject: [PATCH 1/2] Merge QS01/QS02 into a single HNDL entry; move signature content to QS03 Per the discussion in #11: QS01 (Harvest-Now-Decrypt-Later Exposure) and QS02 (Long-Lived Sensitive Data) covered the same underlying exposure - ciphertext an adversary can obtain now, protected by an algorithm that fails later - differing only in whether the ciphertext was in transit or already at rest. The merged QS01 uses Mosca's inequality as a single prioritisation frame covering both surfaces. QS02's integrity content (long-lived signed artefacts, identity and credential records, the forged-release scenario) moves to QS03, applying the same Mosca's-inequality logic to signature trust rather than confidentiality - QS03 was already the entry covering signature forgery. Net effect: ten entries become nine, opening a slot for Sprint 1. The README table and a note on the freed slot are updated accordingly; no other entries are touched. --- README.md | 10 ++++- ...QS01_Harvest-Now-Decrypt-Later-Exposure.md | 35 +++++++++------- .../QS02_Long-Lived-Sensitive-Data.md | 42 ------------------- ..._Vulnerable-Signatures-and-Code-Signing.md | 12 +++++- 4 files changed, 38 insertions(+), 61 deletions(-) delete mode 100644 quantum-top-10/QS02_Long-Lived-Sensitive-Data.md diff --git a/README.md b/README.md index 6ad7780..b4263f3 100644 --- a/README.md +++ b/README.md @@ -74,10 +74,16 @@ existing classical cryptography must be replaced with post-quantum equivalents. QS08-QS10 address the **platform surface** - risks to organisations running workloads on quantum computing platforms. +> **Candidate restructuring under Sprint 1 discussion (see #11):** QS01 and +> QS02 have merged into a single Harvest-Now-Decrypt-Later entry covering both +> in-transit and at-rest confidentiality exposure under Mosca's inequality; +> QS02's signature and credential-lifetime content moved into QS03. This frees +> a slot pending the Sprint 1 candidate list - not a claim that any specific +> replacement is already decided. + | ID | Risk | Primary anchor | |----|------|----------------| -| [QS01](quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md) | Harvest-Now-Decrypt-Later Exposure | EU Roadmap end-2030; NCSC 2031; NSM-10 | -| [QS02](quantum-top-10/QS02_Long-Lived-Sensitive-Data.md) | Long-Lived Sensitive Data | Mosca's inequality; EU Roadmap end-2030 | +| [QS01](quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md) | Harvest-Now-Decrypt-Later Exposure | Mosca's inequality; EU Roadmap end-2030; NCSC 2031; NSM-10 | | [QS03](quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md) | Vulnerable Signatures and Code-Signing | NSA CNSA 2.0 by 2030; CRA Annex I | | [QS04](quantum-top-10/QS04_Absent-Cryptographic-Inventory-and-CBOM.md) | Absent Cryptographic Inventory and CBOM | NCSC 2028; EU Roadmap end-2026 | | [QS05](quantum-top-10/QS05_Crypto-Agility-Failures.md) | Crypto-Agility Failures | NIS2 Article 21(2)(h); IETF PQUIP/TLS WG | diff --git a/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md b/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md index d8e1194..242b6fc 100644 --- a/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md +++ b/quantum-top-10/QS01_Harvest-Now-Decrypt-Later-Exposure.md @@ -2,40 +2,45 @@ **Description:** -Adversaries are already capturing encrypted traffic and stored ciphertext today, retaining it for future decryption once a cryptographically relevant quantum computer (CRQC) exists. The relevant operation is typically a key-establishment step protected by RSA, finite-field Diffie-Hellman, or elliptic-curve Diffie-Hellman - all broken in polynomial time by Shor's algorithm. Once the session key is recovered, the symmetric ciphertext follows. Any organisation whose data has meaningful confidentiality lifetime - financial records, health data, source code, intelligence material, contractual or commercial secrets - must treat current TLS, VPN, and at-rest encryption based on these primitives as future-readable. The risk is concrete now, not contingent on quantum hardware availability. +Adversaries are already capturing encrypted traffic and stored ciphertext today, retaining it for future decryption once a cryptographically relevant quantum computer (CRQC) exists. The relevant operation is typically a key-establishment step protected by RSA, finite-field Diffie-Hellman, or elliptic-curve Diffie-Hellman - all broken in polynomial time by Shor's algorithm. Once the session key or wrapping key is recovered, the symmetric ciphertext it protects follows. This entry covers the full harvest surface: data captured **in transit**, where an adversary records ciphertext as it crosses an untrusted network boundary, and data already sitting **at rest**, where an adversary can exfiltrate an existing encrypted store at any point before a CRQC exists and simply wait. Both are the same exposure - ciphertext an adversary can obtain now, protected by an algorithm that fails later - differing only in where the ciphertext currently resides. + +Mosca's inequality is the operative planning frame for both surfaces: if the time to migrate to quantum-safe cryptography (X) plus the required confidentiality lifetime of the data (Y) exceeds the time until a CRQC exists (Z), the data is already exposed regardless of exactly when a CRQC arrives. For in-transit data this determines how urgently a channel needs migrating; for at-rest data - archives, backups, regulated personal data, identity records, intellectual property - it determines how urgently existing stores need re-encryption, since a record with a multi-decade retention requirement can fail this inequality today even if migration starts immediately. Any organisation whose data has meaningful confidentiality lifetime - financial records, health data, source code, intelligence material, contractual or commercial secrets - must treat current TLS, VPN, and at-rest encryption based on these primitives as future-readable. The risk is concrete now, not contingent on quantum hardware availability. **Common Examples of Vulnerability:** -1. Data sets whose confidentiality requirement extends beyond 2030 - health records, intellectual property, regulated personal data with long retention, government and defence data - protected only by classical public-key cryptography. -2. Transport and channel protection using vulnerable key establishment: TLS endpoints, VPN tunnels, encrypted backup channels, archival storage encryption, and satellite or microwave links relying on RSA, ECDH, or finite-field DH. -3. Encrypted traffic transiting an untrusted boundary where it can be passively recorded and retained for later decryption. -4. Session encryption migrated to PQC while long-validity certificates and key-wrapping keys are left on classical algorithms. +1. Data sets whose confidentiality requirement extends beyond the CRQC planning horizon most regulators use (2030-2035) - health records, intellectual property, regulated personal data with long retention, government and defence data - protected only by classical public-key cryptography, whether in transit or already stored. +2. Transport and channel protection using vulnerable key establishment: TLS endpoints, VPN tunnels, encrypted backup channels, and satellite or microwave links relying on RSA, ECDH, or finite-field DH, traversing an untrusted boundary where they can be passively recorded and retained. +3. Archives and backups that pre-date current crypto policy, held under long retention requirements, where confidentiality lifetime plus migration lead time already exceeds the CRQC horizon by Mosca's inequality. +4. Data at rest encrypted with AES-256 but wrapped with an RSA or ECC key - the quantum-vulnerable layer sits above the symmetric key, so the attacker's target is the wrapping key, not the cipher. +5. Session encryption migrated to PQC while long-validity certificates and key-wrapping keys protecting archived data are left on classical algorithms. **How to Prevent:** 1. Migrate vulnerable channels to hybrid post-quantum TLS using ML-KEM (FIPS 203) where the platform supports it. -2. For data at rest, layer a PQC-protected encryption envelope over existing classical encryption for the highest-sensitivity datasets. -3. Rotate symmetric data keys protected by quantum-vulnerable wrapping more frequently to reduce the volume exposed by any single recovered key. -4. Reduce data retention where the business case allows - data not retained cannot be decrypted later. +2. Classify data by confidentiality lifetime, not just sensitivity - a medium-sensitivity record with a 30-year retention requirement may outrank a high-sensitivity record retained for two years, and Mosca's inequality is the tool for making that ranking explicit. +3. For the highest-priority archives identified by that classification, layer a PQC-protected encryption envelope over the existing classical encryption, sequenced against migration capacity. +4. Rotate symmetric data keys protected by quantum-vulnerable wrapping more frequently, to reduce the volume of data exposed by the recovery of any single wrapping key. +5. Reduce data retention where the business case allows - data not retained cannot be harvested or decrypted later. **Example Attack Scenarios:** Scenario #1: An adversary passively records TLS-protected traffic as it crosses an untrusted network boundary today. The handshake used RSA or ECDH key establishment. The captured ciphertext is archived. Once a CRQC becomes available, the adversary recovers the session key via Shor's algorithm and decrypts years of previously confidential traffic retroactively. -Scenario #2: An organisation encrypts long-retention backups at rest with AES-256, but the AES data key is wrapped with RSA. An attacker exfiltrates the encrypted backups and the wrapped keys. Because the quantum-vulnerable layer is the RSA key-wrapping - not the symmetric cipher - the attacker recovers the wrapping key with a future CRQC and unwraps the AES keys, exposing the entire archive. +Scenario #2: A regulated entity retains personal records for a statutory 30-year period, encrypted with an RSA-wrapped AES key, held at rest rather than transmitted. An adversary exfiltrates the encrypted store today - no interception is needed, since the ciphertext already sits somewhere reachable. Applying Mosca's inequality, the confidentiality lifetime alone exceeds the CRQC horizon, so the records are effectively already compromised: the attacker recovers the wrapping key once a CRQC exists and decrypts the full archive, well within its required protection window. **Reference Links:** - + 1. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final): Key-establishment standard for post-quantum migration. -2. [UK NCSC - Timelines for migration to post-quantum cryptography (March 2025)](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines): Migration timelines calling out long-lived sensitive data as a priority class. -3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 deadline prohibiting standalone quantum-vulnerable PKC for high-risk use cases. -4. [White House National Security Memorandum 10 (NSM-10)](https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/) and [OMB M-23-02](https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf): Cite HNDL as the primary driver of US migration urgency. +2. [NIST IR 8547 (Draft) - Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd): Transition planning guidance referencing Mosca's inequality. +3. [UK NCSC - Timelines for migration to post-quantum cryptography (March 2025)](https://www.ncsc.gov.uk/guidance/pqc-migration-timelines): Migration timelines calling out long-lived sensitive data as a priority class. +4. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 deadline prohibiting standalone quantum-vulnerable PKC for high-risk use cases. +5. [White House National Security Memorandum 10 (NSM-10)](https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/) and [OMB M-23-02](https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf): Cite HNDL as the primary driver of US migration urgency. +6. [EU Cyber Resilience Act - Regulation (EU) 2024/2847, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): State-of-the-art protection required through the product support period, which for many products extends past 2030. **Standards and Regulatory Mapping:** > **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. -NIST FIPS 203 (ML-KEM) for key establishment. NCSC Timelines for migration to post-quantum cryptography (March 2025). EU Coordinated Implementation Roadmap (June 2025), end-2030 high-risk deadline. NSA CNSA 2.0 prioritises network encryption and long-lived secrets. NIS2 Article 21(2)(h) cryptographic policy obligation; DORA Article 9 confidentiality and integrity at rest, in use and in transit. NSM-10 and OMB M-23-02 cite HNDL as the migration driver. - +NIST FIPS 203 (ML-KEM) for key establishment. NIST IR 8547 (Draft) on transition planning and Mosca's inequality. NCSC Timelines for migration to post-quantum cryptography (March 2025), long-lived data prioritisation. EU Coordinated Implementation Roadmap (June 2025), end-2030 high-risk deadline and standalone-PKC prohibition. NSA CNSA 2.0 prioritises network encryption and long-lived secrets. NIS2 Article 21(2)(h) cryptographic policy obligation; DORA Article 9 confidentiality and integrity at rest, in use and in transit. NSM-10 and OMB M-23-02 cite HNDL as the migration driver. CRA Annex I requires state-of-the-art protection through the product support period. diff --git a/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md b/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md deleted file mode 100644 index 3022fd6..0000000 --- a/quantum-top-10/QS02_Long-Lived-Sensitive-Data.md +++ /dev/null @@ -1,42 +0,0 @@ -## QS02:2026 - Long-Lived Sensitive Data - -**Description:** - -Data with a confidentiality requirement that extends past the projected arrival of a CRQC cannot be protected by today's public-key primitives alone. Mosca's inequality is the operative planning frame: if the time to migrate to quantum-safe cryptography (X) plus the required confidentiality lifetime of the data (Y) exceeds the time until a CRQC exists (Z), the organisation is already exposed. For data with multi-decade confidentiality requirements - archives, backups, regulated personal data, identity records, intellectual property, signed material whose integrity must hold for years - current public-key protection is insufficient regardless of exactly when a CRQC arrives. This is distinct from QS01: it focuses on stored data and signed artefacts whose protection requirements outlast any reasonable migration window, rather than in-flight traffic. - -**Common Examples of Vulnerability:** - -1. Major data categories where confidentiality lifetime plus migration lead time exceeds published government CRQC planning horizons (2030-2035 for most regulators). -2. Archives and backups that pre-date current crypto policy and may contain quantum-vulnerable encryption under long retention requirements. -3. Signed artefacts whose validity must persist for years: contracts, regulatory filings, evidentiary records, signed software releases, blockchain transactions. -4. Identity and credential records with multi-year lifetimes: government identity issuance, professional credentials, root certificates. -5. Data-at-rest encrypted with AES-256 but wrapped with an RSA or ECC key - the quantum-vulnerable layer sits above the symmetric key. - -**How to Prevent:** - -1. Establish data classification by confidentiality lifetime, not just sensitivity - a medium-sensitivity record with a 30-year retention requirement may outrank a high-sensitivity record retained for two years. -2. Plan re-encryption programmes for high-priority archives, sequenced against migration capacity. -3. For long-lived signed artefacts, plan re-signing or counter-signing with PQC schemes (ML-DSA, SLH-DSA) before classical signature schemes are deprecated. -4. Where re-encryption is not feasible, reduce retention to the minimum legally and operationally required. - -**Example Attack Scenarios:** - -Scenario #1: A regulated entity retains personal records for a statutory 30-year period, encrypted with an RSA-wrapped AES key. An adversary harvests the encrypted store today. Applying Mosca's inequality, the confidentiality lifetime far exceeds the CRQC horizon, so the records are effectively already compromised: the attacker recovers the wrapping key once a CRQC exists and decrypts the full archive, well within its required protection window. - -Scenario #2: A vendor issues software releases signed with ECDSA, with signatures expected to remain valid for the product's decade-long support lifetime. An attacker records the signed artefacts and, after a CRQC becomes available, forges signatures on malicious updates that still validate against the long-lived, un-rotated trust anchor. - -**Reference Links:** - - - -1. [NIST IR 8547 (Draft) - Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd): Transition planning guidance referencing Mosca's inequality. -2. [UK NCSC - Next steps in preparing for post-quantum cryptography](https://www.ncsc.gov.uk/paper/next-steps-in-preparing-for-post-quantum-cryptography): Long-lived data prioritisation for PQC migration. -3. [EU Coordinated Implementation Roadmap for PQC (June 2025)](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 high-risk deadline and standalone-PKC prohibition. -4. [EU Cyber Resilience Act - Regulation (EU) 2024/2847, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): State-of-the-art protection required through the product support period. - -**Standards and Regulatory Mapping:** - -> **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. - -NIST IR 8547 (Draft) on transition planning. NCSC migration guidance on long-lived data prioritisation. EU Coordinated Implementation Roadmap end-2030 high-risk deadline; explicit prohibition on standalone quantum-vulnerable PKC for high-risk cases after 2030. CRA Annex I requires state-of-the-art protection through the support period, which for many products extends past 2030. - diff --git a/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md b/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md index 016fa0d..aff97a6 100644 --- a/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md +++ b/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md @@ -4,12 +4,16 @@ Public-key signatures underpin code signing, supply-chain integrity, document validity, identity certificates, transactions, and long-term non-repudiation. RSA, DSA, ECDSA, and EdDSA are all broken by Shor's algorithm, so any system that verifies these signatures to establish trust - software updates, container images, firmware, package managers, TLS certificate hierarchies, SBOM attestations, signed documents, blockchain transactions - is at risk once a CRQC exists. Unlike confidentiality breaches, signature forgery enables active attacks: malicious updates, fake identities, fraudulent transactions, supply-chain compromise. The post-quantum signature standards (ML-DSA / FIPS 204 and SLH-DSA / FIPS 205) have larger keys and signatures and different operational profiles, with non-trivial impact on hardware roots of trust, constrained devices, and certificate ecosystems. +The same Mosca's-inequality logic that governs confidentiality exposure (QS01) applies to signature trust, with the inequality read against integrity rather than secrecy: if the time to migrate (X) plus the period a signature or credential must remain trustworthy (Y) exceeds the time until a CRQC exists (Z), that signature is already exposed. Contracts, regulatory filings, evidentiary records, signed software releases, and long-lived identity or credential issuance - government identity, professional credentials, root certificates - routinely carry validity periods long enough to fail this test today, independent of when a CRQC actually arrives. + **Common Examples of Vulnerability:** 1. Certification authority hierarchies (root, intermediate, issuing CA) signing with RSA-2048 or ECDSA P-256 over multi-year validity periods. 2. Code-signing keys: OS update signing, firmware signing, container image signing (Sigstore, cosign, Notary), package signing, mobile app signing, CI/CD signing. 3. Other long-lived signature trust anchors: UEFI Secure Boot keys, TPM endorsement keys, JWT/SAML issuer keys, document-signing certificates, blockchain wallet keys. 4. Large verifier populations - devices, services, or artefacts - that trust a classical key and cannot easily be upgraded. +5. Long-lived signed artefacts whose validity must persist for years - contracts, regulatory filings, evidentiary records, signed software releases, blockchain transactions - where confidentiality-style Mosca's-inequality reasoning applied to integrity shows the artefact is already exposed. +6. Identity and credential records with multi-year lifetimes - government identity issuance, professional credentials, root certificates - signed with a classical algorithm and expected to remain trustworthy well past any reasonable migration window. **How to Prevent:** @@ -18,6 +22,7 @@ Public-key signatures underpin code signing, supply-chain integrity, document va 3. Use ML-DSA (FIPS 204) for general digital signatures; use SLH-DSA (FIPS 205) for very long-lived, high-assurance signatures where stateless hash-based security is preferred. 4. Plan for shorter certificate lifetimes during transition (e.g. the CA/Browser Forum 47-day TLS maximum effective 2029) to reduce the exposure window. 5. Engage PKI, code-signing, and certificate-authority vendors on PQC roadmaps - failure here is a supply-chain blocker. +6. For long-lived signed artefacts and credentials already failing the Mosca's-inequality test, plan re-signing or counter-signing with PQC schemes (ML-DSA, SLH-DSA) before the classical signature scheme is deprecated, rather than treating the artefact as settled once issued. **Example Attack Scenarios:** @@ -25,19 +30,22 @@ Scenario #1: An attacker with a future CRQC recovers the private key of a code-s Scenario #2: An organisation migrates its leaf TLS certificates to PQC but leaves the root and intermediate CAs on RSA. An attacker forges an intermediate CA signature with a CRQC and issues trusted certificates for arbitrary domains - the chain is only as strong as its weakest classical link. +Scenario #3: A vendor issues software releases signed with ECDSA, with signatures expected to remain valid for the product's decade-long support lifetime. An attacker records the signed artefacts today and, after a CRQC becomes available, forges signatures on malicious updates that still validate against the long-lived, un-rotated trust anchor - the artefact was exposed from the day it was signed, under the same Mosca's-inequality logic that governs confidentiality. + **Reference Links:** - + 1. [NIST FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Module-lattice digital signature standard. 2. [NIST FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final): Stateless hash-based signature standard for high-assurance, long-lived use. 3. [NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)](https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/): Software and firmware signing exclusively CNSA 2.0 by 2030. 4. [IETF LAMPS Working Group](https://datatracker.ietf.org/wg/lamps/about/): PQC X.509 and CMS extensions. 5. [EU Cyber Resilience Act, Annex I](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng): State-of-the-art integrity and authenticity requirements. +6. [NIST IR 8547 (Draft) - Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd): Transition planning guidance referencing Mosca's inequality, applied here to signature and credential lifetime. **Standards and Regulatory Mapping:** > **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. -NIST FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). NSA CNSA 2.0: software and firmware signing exclusively CNSA 2.0 by 2030. NCSC recommends ML-DSA-65 for most use cases. EU CRA Annex I requires state-of-the-art mechanisms for integrity and authenticity. IETF LAMPS working group on PQC X.509 and CMS extensions. DORA Articles 28-44 on third-party risk management apply to PKI and signing service vendors. +NIST FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). NIST IR 8547 (Draft) on transition planning and Mosca's inequality. NSA CNSA 2.0: software and firmware signing exclusively CNSA 2.0 by 2030. NCSC recommends ML-DSA-65 for most use cases. EU CRA Annex I requires state-of-the-art mechanisms for integrity and authenticity, applicable through the product support period for long-lived signed artefacts. IETF LAMPS working group on PQC X.509 and CMS extensions. DORA Articles 28-44 on third-party risk management apply to PKI and signing service vendors. From 1881adac3a9f6ba600bb3288fb84252813145d0e Mon Sep 17 00:00:00 2001 From: m-khan-97 Date: Fri, 7 Aug 2026 22:02:27 +0100 Subject: [PATCH 2/2] QS03: split artefact vs credential remediation; fix Scenario 3 (per nmcitra) Re-signing is the right remedy for fixed-content artefacts (contracts, releases): the content is unchanged, so a new signature only re-attests something already true. It is not equivalent remediation for a credential, which asserts that a named subject controls a key - a PQC re-signature re-asserts that claim with stronger cryptography but does not re-establish it. Splits former Prevention 6 into an artefact case (re-signing/counter-signing) and a credential case (re-issuance must rest on evidence independent of the outgoing key: fresh proofing, a still-trusted anchor, or hardware attestation). Also fixes Scenario 3: forging a malicious update needs the recovered signing key, not copies of prior signed artefacts, so the "records the artefacts today" framing overstated what the harvest step contributes. --- .../QS03_Vulnerable-Signatures-and-Code-Signing.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md b/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md index aff97a6..ecf0af6 100644 --- a/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md +++ b/quantum-top-10/QS03_Vulnerable-Signatures-and-Code-Signing.md @@ -22,7 +22,8 @@ The same Mosca's-inequality logic that governs confidentiality exposure (QS01) a 3. Use ML-DSA (FIPS 204) for general digital signatures; use SLH-DSA (FIPS 205) for very long-lived, high-assurance signatures where stateless hash-based security is preferred. 4. Plan for shorter certificate lifetimes during transition (e.g. the CA/Browser Forum 47-day TLS maximum effective 2029) to reduce the exposure window. 5. Engage PKI, code-signing, and certificate-authority vendors on PQC roadmaps - failure here is a supply-chain blocker. -6. For long-lived signed artefacts and credentials already failing the Mosca's-inequality test, plan re-signing or counter-signing with PQC schemes (ML-DSA, SLH-DSA) before the classical signature scheme is deprecated, rather than treating the artefact as settled once issued. +6. For long-lived signed artefacts already failing the Mosca's-inequality test - contracts, filings, releases, and other fixed-content documents - plan re-signing or counter-signing with PQC schemes (ML-DSA, SLH-DSA) before the classical signature scheme is deprecated, rather than treating the artefact as settled once issued. Re-signing is sufficient here because the artefact's content is unchanged; the new signature only re-attests something that was already true. +7. For long-lived credentials failing the same test, do not treat re-signing as equivalent to remediation. A credential asserts that a named subject controls a key, and a PQC signature over the same claim only re-asserts it with stronger cryptography - it does not re-establish the claim itself. Require re-issuance to rest on evidence independent of the credential being replaced (fresh identity proofing, a still-trusted anchor, or hardware attestation), not on the outgoing key vouching for its own successor. **Example Attack Scenarios:** @@ -30,7 +31,7 @@ Scenario #1: An attacker with a future CRQC recovers the private key of a code-s Scenario #2: An organisation migrates its leaf TLS certificates to PQC but leaves the root and intermediate CAs on RSA. An attacker forges an intermediate CA signature with a CRQC and issues trusted certificates for arbitrary domains - the chain is only as strong as its weakest classical link. -Scenario #3: A vendor issues software releases signed with ECDSA, with signatures expected to remain valid for the product's decade-long support lifetime. An attacker records the signed artefacts today and, after a CRQC becomes available, forges signatures on malicious updates that still validate against the long-lived, un-rotated trust anchor - the artefact was exposed from the day it was signed, under the same Mosca's-inequality logic that governs confidentiality. +Scenario #3: A vendor issues software releases signed with ECDSA, with signatures expected to remain valid for the product's decade-long support lifetime. Once a CRQC exists, an attacker recovers the signing key and forges signatures on malicious updates that still validate against the long-lived, un-rotated trust anchor - the artefact was exposed from the day it was signed, under the same Mosca's-inequality logic that governs confidentiality. **Reference Links:**