PQC Readiness (Quantum-Vulnerable Public-Key Cryptography)

ID

javascript.pqc_readiness

Severity

info

Remediation Complexity

high

Remediation Risk

medium

Remediation Effort

high

Resource

Cryptography

Language

JavaScript

Tags

ASVS50:v11.2.1, ASVS50:v11.6.1, CWE:327, NIST.IR.8547, OWASP:2025:A04, crypto, pqc, quantum

Description

Use of quantum-vulnerable public-key cryptography that is not post-quantum ready.

Rationale

Classical public-key algorithms — RSA, elliptic-curve schemes (ECDSA, EdDSA, ECDH), finite-field Diffie-Hellman and DSA — are broken by Shor’s algorithm on a cryptographically-relevant quantum computer. Unlike key-size weaknesses, this is not mitigated by a larger key: a perfectly-sized RSA-3072 or ECDSA P-256 key is still a migration target. Confidentiality and key-establishment uses are additionally exposed to "harvest now, decrypt later" — traffic captured today can be decrypted once such a machine exists. NIST IR 8547 deprecates 112-bit-equivalent public-key cryptography by 2030 and disallows it after 2035.

crypto.generateKeyPairSync("rsa", { modulusLength: 3072 }); // Shor-broken
crypto.generateKeyPairSync("ec", { namedCurve: "P-256" });  // Shor-broken

Remediation

Remediation branches on the cryptographic primitive — conflating Shor’s and Grover’s threats produces wrong advice:

  • Public-key (RSA, ECC/ECDSA/EdDSA, DH/ECDH, DSA) — broken by Shor: there is no key-size fix. Migrate to a NIST-standardized post-quantum scheme: ML-KEM (FIPS 203) for key establishment/encryption and ML-DSA (FIPS 204) for signatures, with SLH-DSA (FIPS 205) as a conservative signature alternative. During the transition, prefer a hybrid (classical + PQC) construction so a break in either component is tolerated.

  • Symmetric ciphers and hashes — weakened by Grover: these are hardenable in place by doubling sizes (AES-256, SHA-384/SHA-512); they are not flagged by this rule.

Plan the migration against the regulatory timeline (NIST IR 8547: deprecated 2030, disallowed 2035; EU milestones 2026/2030/2035) and prioritize long-lived confidential data first.

References