Frequently Asked Questions

Plain-language answers to the questions teams ask most often when starting a post-quantum migration. For deeper treatment, follow the cross-links in each answer.

Threat and timing

Is my data at risk right now?

Possibly. No public quantum computer can break RSA or ECC today, but the Harvest Now, Decrypt Later (HNDL) threat is real: an adversary can record your encrypted traffic now and decrypt it once a cryptographically relevant quantum computer (CRQC) exists. If your data must stay confidential for 10+ years, treat it as already at risk and prioritize it for migration.

When will RSA be broken?

Nobody knows the exact date. Most migration guidance does not rely on a precise prediction but uses Mosca's inequality: it weighs the relationship between how long your data must stay confidential, the time needed to migrate, and when a CRQC might appear to decide whether to act now. The honest planning answer comes from Mosca's inequality: if the time your data must stay secret, plus the time to migrate, exceeds the time until a CRQC arrives, you are already late. Plan against the inequality, not a calendar date.

Do I need to do anything if a quantum computer doesn't exist yet?

Yes — migration takes years, and harvest-now-decrypt-later means waiting forfeits the confidentiality of today's data. Start inventory and crypto-agility work now.

The technology

Do I need a quantum computer to run PQC?

No. Post-quantum algorithms run on ordinary classical computers — laptops, servers, phones, smartcards. They are simply new math problems believed to resist quantum attack. The "quantum" refers to the threat they defend against, not the hardware they run on.

What is the difference between QKD and PQC?

QKD (quantum key distribution) uses quantum physics over special hardware and fiber/optical links to exchange keys; it has range and infrastructure limits and does not provide authentication on its own. PQC is software/math that runs everywhere on existing hardware and replaces today's public-key algorithms directly. NIST, NSA, and most standards bodies recommend PQC as the general solution; QKD typically suits specific scenarios with dedicated links and high-assurance needs, and cannot replace authentication or general protocol-stack upgrades. They are not interchangeable.

Is symmetric cryptography safe from quantum computers?

Largely yes. Grover's algorithm gives only a quadratic speedup against symmetric ciphers and hashes, so the fix is to use larger sizes: AES-256 instead of AES-128, and SHA-384/512-class hashes. There is no Shor-style break for AES, SHA-2, or SHA-3. The same applies to China's SM4/SM3 (see sm-algorithms.html).

Are PQC algorithms slower than RSA/ECC?

For computation, the standardized lattice schemes (ML-KEM, ML-DSA) are often faster than RSA. The main cost is size: larger keys, ciphertexts, and signatures, which increases bandwidth and can affect protocols with tight packet budgets. See performance.html.

Choices and standards

Which algorithm should I use?

For most uses: ML-KEM-768 for key establishment and ML-DSA-65 for signatures. Use Falcon/FN-DSA when signature size is critical, stateful LMS/XMSS for firmware signing, and SLH-DSA when you want a hash-only security assumption. Note, however, that FN-DSA/Falcon is not yet a final FIPS standard and is more complex to implement. See comparison.html.

Why use hybrid (classical + PQC) instead of PQC alone?

Hybrid combines a well-understood classical algorithm with a post-quantum one so that the connection stays secure if either holds. It hedges against an undiscovered flaw in the still-young PQC schemes while delivering quantum resistance today. Many deployments (e.g., TLS) start hybrid for this reason. See hybrid.html.

Are the standards final?

The core ones are. NIST published FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA) as final standards in August 2024. FN-DSA (Falcon) is forthcoming as FIPS 206, which is still a draft and not yet a final standard as of June 2026 — its Initial Public Draft has not yet been published, remaining in NIST / U.S. Department of Commerce clearance (publication of the draft and then the final standard is expected around 2026–2027), and additional KEMs such as HQC are progressing. Stateful hash signatures are covered by SP 800-208. See standards.html.

Can I just swap RSA for a PQC algorithm and be done?

Rarely. Larger sizes, new failure modes, protocol negotiation, certificate formats, and library support all change. The durable answer is crypto-agility: architect so algorithms can be replaced without re-engineering. See crypto-agility.html.

What about Bitcoin / blockchain and Web3?

Blockchains rely heavily on ECDSA/EdDSA signatures, which Shor breaks. Exposed public keys (e.g., reused addresses) are particularly vulnerable. Web3 projects should track PQC signature standards and plan key-rotation and migration paths early.

Does China need PQC if it uses SM algorithms?

Yes. SM2 and SM9 are classical public-key algorithms broken by Shor exactly like RSA/ECC. Adopting SM is a sovereignty/compliance step, not a quantum-safety one. See china-overview.html.

Where do I start?

Inventory your cryptography (build a CBOM), identify Shor-vulnerable, long-lived assets, adopt crypto-agility, pilot hybrid key exchange, and follow a phased playbook.html.

Standards & references

• NIST PQC project — the authoritative source for algorithms and transition guidance.
• FIPS 203 (ML-KEM) — the standardized key-establishment KEM.
• ETSI Quantum-Safe Cryptography — migration, hybrid, and crypto-agility guidance.
• Resources — full standards register