> ## Documentation Index
> Fetch the complete documentation index at: https://threatbasis.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Post-Quantum Cryptography

> Quantum-resistant algorithms, hybrid migration strategies, crypto agility, and NIST PQC standardization timeline for practical adoption.

Post-quantum cryptography (PQC) addresses the threat that large-scale quantum computers pose to current public-key cryptography including RSA and elliptic curve cryptography (ECC). Security engineers build cryptographic agility and plan migrations to [NIST-selected PQC algorithms](https://csrc.nist.gov/projects/post-quantum-cryptography) with minimal business disruption.

Effective PQC migration requires:

* **Cryptographic inventory** of all algorithm usage across systems
* **Hybrid approaches** combining classical and quantum-resistant algorithms during transition
* **Coordination** across dependencies, partners, and certificate authorities

Quantum computers capable of breaking RSA and ECC do not yet exist at scale, but the harvest-now-decrypt-later threat requires action today for long-lived confidential data.

## Quantum Threat to Cryptography

### Vulnerable vs. Resistant Algorithm Classes

Understanding which cryptographic primitives are vulnerable to quantum attacks guides migration prioritization:

| Algorithm Type | Quantum Vulnerability | Attack Vector                                                                                       | Mitigation                    |
| -------------- | --------------------- | --------------------------------------------------------------------------------------------------- | ----------------------------- |
| RSA            | **Critical**          | [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm) breaks integer factorization   | Replace with ML-KEM or ML-DSA |
| Diffie-Hellman | **Critical**          | Shor's algorithm solves discrete logarithm                                                          | Replace with ML-KEM           |
| ECDSA/ECDH     | **Critical**          | Shor's algorithm solves elliptic curve discrete logarithm                                           | Replace with ML-DSA/ML-KEM    |
| AES-128        | Moderate              | [Grover's algorithm](https://en.wikipedia.org/wiki/Grover%27s_algorithm) provides quadratic speedup | Upgrade to AES-256            |
| AES-256        | Low                   | Grover's reduces effective security to 128-bit                                                      | Generally acceptable          |
| SHA-256/SHA-3  | Low                   | Grover's provides quadratic speedup                                                                 | Consider SHA-384 or SHA-512   |

### Harvest-Now-Decrypt-Later (HNDL) Threat

Adversaries can capture encrypted data today and decrypt it when cryptographically-relevant quantum computers (CRQCs) become available. This threat model affects:

* **Government classified data** with multi-decade confidentiality requirements
* **Healthcare records** protected under long-term privacy regulations
* **Financial data** including long-term contracts and trade secrets
* **Intellectual property** with extended competitive value

Data with confidentiality requirements beyond 10-15 years should be protected with PQC now. Waiting until quantum computers exist is too late.

## NIST Post-Quantum Cryptography Standards

The [NIST Post-Quantum Cryptography Standardization Project](https://csrc.nist.gov/projects/post-quantum-cryptography) finalized its first standards in August 2024, providing the foundation for quantum-resistant cryptography adoption.

### Key Encapsulation Mechanisms (KEMs)

KEMs replace Diffie-Hellman and RSA key exchange, enabling quantum-resistant key establishment for TLS, SSH, and other protocols.

| Algorithm            | NIST Standard                                         | Use Case                     | Key Size       | Ciphertext Size |
| -------------------- | ----------------------------------------------------- | ---------------------------- | -------------- | --------------- |
| **ML-KEM** (Kyber)   | [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final) | General-purpose key exchange | 800-1568 bytes | 768-1568 bytes  |
| **Classic McEliece** | Under consideration                                   | Conservative alternative     | \~1 MB         | 128-240 bytes   |

**ML-KEM (formerly CRYSTALS-Kyber)** is the primary standard for general use, offering strong security with practical performance characteristics suitable for high-volume TLS deployments.

### Digital Signatures

Signature algorithms replace RSA and ECDSA, enabling quantum-resistant authentication, code signing, and document integrity verification.

| Algorithm              | NIST Standard                                         | Use Case                            | Public Key      | Signature Size   |
| ---------------------- | ----------------------------------------------------- | ----------------------------------- | --------------- | ---------------- |
| **ML-DSA** (Dilithium) | [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) | General-purpose signatures          | 1312-2592 bytes | 2420-4627 bytes  |
| **FN-DSA** (Falcon)    | Draft standard                                        | Bandwidth-constrained applications  | 897-1793 bytes  | 666-1280 bytes   |
| **SLH-DSA** (SPHINCS+) | [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final) | Conservative hash-based alternative | 32-64 bytes     | 7856-49856 bytes |

**ML-DSA** is recommended for most applications. **SLH-DSA** provides a conservative fallback based on well-understood hash function security.

### Standardization Timeline

1. **August 2024**: NIST published final FIPS 203, 204, and 205 standards
2. **2024-2025**: Additional algorithms under evaluation (including HQC for KEMs)
3. **Ongoing**: [IETF PQC Working Group](https://datatracker.ietf.org/wg/pquip/about/) developing protocol integrations

## Migration Strategy

### Step 1: Cryptographic Inventory

Before migrating, conduct a comprehensive inventory of all cryptographic usage:

* **Protocols**: TLS versions, SSH configurations, IPsec/VPN tunnels, QUIC implementations
* **Libraries**: OpenSSL, BoringSSL, libsodium, platform-specific crypto providers
* **Key material**: RSA/ECC keys, certificates, tokens, API keys
* **Data stores**: Encrypted databases, key management systems, HSMs

Prioritize inventory items by:

1. **Confidentiality duration** — data requiring 10+ years protection
2. **Algorithm type** — RSA/ECC before symmetric/hash
3. **Exposure** — internet-facing services before internal systems

### Step 2: Establish Cryptographic Agility

Cryptographic agility enables algorithm changes without code modifications—essential for any PQC migration:

* **Version algorithms and key types** in configuration rather than code
* **Use pluggable cryptographic providers** (e.g., [OpenSSL 3.x provider architecture](https://www.openssl.org/docs/man3.0/man7/provider.html))
* **Eliminate hardcoded algorithms** that prevent migration
* **Abstract cryptographic operations** behind interfaces that support algorithm negotiation

### Step 3: Implement Hybrid Approaches

Hybrid cryptography combines classical and PQC algorithms, providing security if either algorithm remains secure:

| Hybrid Type           | Example Combination | Use Case                   |
| --------------------- | ------------------- | -------------------------- |
| Hybrid KEM            | X25519 + ML-KEM-768 | TLS 1.3 key exchange       |
| Hybrid Signature      | Ed25519 + ML-DSA-65 | Code signing, certificates |
| Composite Certificate | ECDSA + ML-DSA      | X.509 certificate chains   |

Hybrid approaches are **recommended during transition** because:

* They hedge against undiscovered weaknesses in new PQC algorithms
* They maintain classical security if PQC implementations have bugs
* [IETF draft standards](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) are maturing for protocol integration

### Step 4: Performance Testing

PQC algorithms have different performance characteristics than classical algorithms. Test for:

* **Key and signature sizes** — ML-DSA signatures are \~40x larger than ECDSA
* **MTU fragmentation** — larger TLS handshakes may exceed 1500-byte MTU limits
* **Latency impacts** — some PQC operations are slower than classical equivalents
* **Memory pressure** — larger keys affect embedded and IoT devices

> **Testing guidance**: Conduct performance testing in production-representative environments. Lab testing often underestimates real-world impacts from network conditions and concurrent load.

## Dependencies and Supply Chain

### Library Support Status

Cryptographic library support is a prerequisite for PQC migration. Track these implementations:

| Library                                                    | PQC Status                | Notes                                                                 |
| ---------------------------------------------------------- | ------------------------- | --------------------------------------------------------------------- |
| [OpenSSL 3.x](https://www.openssl.org/)                    | Provider-based support    | Via [OQS provider](https://github.com/open-quantum-safe/oqs-provider) |
| [BoringSSL](https://boringssl.googlesource.com/boringssl/) | ML-KEM integrated         | Used by Chrome, Android                                               |
| [AWS-LC](https://github.com/aws/aws-lc)                    | ML-KEM, ML-DSA            | FIPS-validated builds available                                       |
| [liboqs](https://openquantumsafe.org/)                     | Reference implementations | [Open Quantum Safe Project](https://openquantumsafe.org/)             |
| [wolfSSL](https://www.wolfssl.com/)                        | ML-KEM, ML-DSA            | FIPS 140-3 path available                                             |

**FIPS 140-3 validation** for PQC algorithms is in progress through NIST's [Cryptographic Module Validation Program (CMVP)](https://csrc.nist.gov/projects/cryptographic-module-validation-program). Environments requiring FIPS validation should track validation timelines closely.

### Partner and Vendor Coordination

Protocol interoperability requires both parties to support PQC—unilateral migration is insufficient:

* **Request vendor PQC roadmaps** for all cryptographic dependencies
* **Participate in industry working groups** through [IETF](https://www.ietf.org/), [CA/Browser Forum](https://cabforum.org/), and sector-specific bodies
* **Test interoperability early** using reference implementations
* **Plan for asymmetric migration** where some partners migrate faster than others

### Certificate Authority Support

Certificate Authorities must issue PQC certificates for quantum-resistant TLS:

* **Track CA timelines** for PQC certificate issuance support
* **Consider hybrid certificates** combining classical and PQC signatures as interim solution
* **Plan for certificate chain impacts** — PQC certificates are significantly larger
* **Monitor [CA/Browser Forum](https://cabforum.org/) developments** for baseline requirements updates

## Migration Timeline and Prioritization

### Risk-Based Prioritization Matrix

Prioritize migration based on data sensitivity and exposure:

| Priority     | Data Characteristics                                                 | Timeline  |
| ------------ | -------------------------------------------------------------------- | --------- |
| **Critical** | National security, 25+ year confidentiality, state-level adversaries | Immediate |
| **High**     | Financial, healthcare, 10-25 year confidentiality                    | 2025-2026 |
| **Medium**   | Business sensitive, 5-10 year confidentiality                        | 2026-2028 |
| **Lower**    | Short-lived session data, public data with integrity requirements    | 2028-2030 |

High-value targets including government, defense, finance, and healthcare face greater threat actor interest and should accelerate timelines accordingly.

### Phased Migration Approach

Avoid big-bang migrations. Phase implementation to manage risk:

1. **Phase 1 — Foundation** (Current)
   * Establish cryptographic agility architecture
   * Deploy hybrid key exchange in non-critical systems
   * Complete cryptographic inventory
   * Train security and development teams

2. **Phase 2 — Priority Systems** (2025-2027)
   * Migrate systems protecting long-lived confidential data
   * Implement hybrid TLS for internet-facing services
   * Update certificate infrastructure for hybrid certificates

3. **Phase 3 — Complete Migration** (2027-2030+)
   * Migrate remaining systems to PQC-only where appropriate
   * Deprecate classical-only cryptographic paths
   * Achieve full quantum resistance across infrastructure

### Standards and Compliance Tracking

Track these authoritative sources for PQC requirements:

* [NIST PQC Project](https://csrc.nist.gov/projects/post-quantum-cryptography) — algorithm standards and updates
* [NSA CNSA 2.0](https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF) — requires PQC for National Security Systems by 2030-2035
* [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/) — protocol integration standards
* [CISA PQC Initiative](https://www.cisa.gov/quantum) — guidance for critical infrastructure

> **Warning**: Avoid non-standardized PQC algorithms in production. Algorithms without NIST standardization lack sufficient peer review and may contain undiscovered vulnerabilities.

## Implementation Considerations

### Key and Certificate Management

PQC keys and certificates are significantly larger than classical equivalents:

| Component          | Classical Size | PQC Size              | Impact             |
| ------------------ | -------------- | --------------------- | ------------------ |
| ECDSA public key   | 64 bytes       | ML-DSA-65: 1952 bytes | 30x increase       |
| RSA-2048 signature | 256 bytes      | ML-DSA-65: 3309 bytes | 13x increase       |
| X.509 certificate  | \~1-2 KB       | \~5-10 KB with PQC    | Storage, bandwidth |

Key management considerations:

* **Update KMS systems** to support PQC key types and larger key sizes
* **Review HSM capabilities** for PQC algorithm support
* **Adjust certificate lifecycle processes** for larger certificate chains
* **Plan for increased bandwidth** in certificate distribution

### Protocol-Specific Changes

| Protocol        | PQC Impact                            | Considerations                        |
| --------------- | ------------------------------------- | ------------------------------------- |
| **TLS 1.3**     | Larger handshakes (3-5 KB additional) | MTU fragmentation, connection latency |
| **SSH**         | Larger key exchange messages          | May require protocol version updates  |
| **IPsec/IKEv2** | Larger IKE\_SA\_INIT exchanges        | VPN gateway updates required          |
| **S/MIME, PGP** | Larger encrypted messages             | Email system compatibility            |

### Backward Compatibility

During the transition period, systems must maintain interoperability:

* **Implement algorithm negotiation** supporting both classical and PQC options
* **Use hybrid modes** where protocol support exists
* **Plan time-limited classical fallback** for legacy system compatibility
* **Monitor and log algorithm negotiation** to track migration progress

## Conclusion

Post-quantum cryptography addresses the existential threat that quantum computers pose to current public-key cryptography. Security engineers must build cryptographic agility now and execute phased migrations to NIST-selected PQC algorithms, prioritizing long-lived confidential data and leveraging hybrid approaches during transition.

**Key success factors**:

* Comprehensive cryptographic inventory across all systems
* Library and dependency updates aligned with vendor roadmaps
* Partner coordination for protocol interoperability
* Risk-based prioritization focusing on harvest-now-decrypt-later threats

Organizations investing in PQC migration today protect sensitive data against future quantum threats while building the cryptographic flexibility needed for long-term security resilience.

## References

* [NIST Post-Quantum Cryptography Project](https://csrc.nist.gov/projects/post-quantum-cryptography)
* [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final), [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final), [FIPS 205 (SLH-DSA)](https://csrc.nist.gov/pubs/fips/205/final)
* [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/) — TLS, SSH, X.509 PQC integration
* [NSA CNSA 2.0 Announcement](https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF) — National Security Systems requirements
* [CISA Post-Quantum Cryptography Initiative](https://www.cisa.gov/quantum)
* [Open Quantum Safe Project](https://openquantumsafe.org/) — reference implementations and testing tools
* [Cloud Security Alliance PQC Guidelines](https://cloudsecurityalliance.org/research/topics/quantum-safe-security)