NIST Post-Quantum
Compliance Checklist

Cryptographic Inventory

• Catalog all public-key algorithms in use. Document every RSA, ECDSA, ECDH, Ed25519, and DH instance across all systems, libraries, and services. Include TLS configs, certificate chains, API auth, VPNs, email encryption, code signing, and document signing.
• Identify key sizes and security levels. Map each algorithm to its effective security level. RSA-2048: ~112-bit classical. ECDSA-P256: 128-bit classical. Neither provides meaningful post-quantum security.
• Classify data sensitivity and longevity. Healthcare records: 50+ years. Financial records: 7-25 years. Auth tokens: minutes. Prioritize migration based on longest-lived data.
• Map third-party dependencies. Identify cryptographic operations by third-party libraries or cloud services requiring vendor coordination.

Risk Assessment

• Evaluate harvest-now-decrypt-later exposure. Calculate: (data confidentiality lifetime) - (years until quantum computers) = migration urgency.
• Assess regulatory requirements. Map post-quantum requirements from CNSA 2.0, HIPAA, PCI DSS, GDPR as applicable.
• Quantify migration complexity. Systems with crypto-agile abstractions migrate quickly. Hard-coded dependencies require significant refactoring.

Architecture Preparation

• Implement cryptographic abstraction layers. All operations through abstract interfaces, enabling algorithm swapping without code changes.
• Update key management systems. Handle larger post-quantum keys: ML-DSA-65 public keys are 1,952 bytes (vs. 32 bytes for Ed25519).
• Plan certificate infrastructure changes. Post-quantum certificates will be larger. Verify chain sizes work with existing infrastructure.
• Test protocol compatibility. Verify post-quantum key/signature sizes work with TLS 1.3, SSH, IPsec message size limits.

Algorithm Selection

• Key encapsulation: ML-KEM-768 (FIPS 203) for general use. ML-KEM-1024 for maximum security.
• Digital signatures: ML-DSA-65 (FIPS 204) for general use. Consider SLH-DSA (FIPS 205) as secondary family for defense-in-depth.
• Hash functions: SHA-3 or SHA-256. Both quantum-resistant. H33 uses SHA3-256 in its STARK proof system.
• Symmetric encryption: AES-256. No migration needed. 128-bit quantum security via Grover.

Implementation and Testing

• Validate against NIST KATs. Known Answer Tests are the gold standard for correctness. Run all published KAT vectors before deploying.
• Constant-time operations. All secret-dependent operations must be constant-time. Use timing analysis tools to verify.
• Memory zeroization. Private keys and intermediates securely erased after use. Rust: zeroize crate with ZeroizeOnDrop.
• Performance testing. Measure latency/throughput under production load. Ensure SLAs are met with post-quantum algorithms.
• Hybrid deployment testing. Test classical + post-quantum end-to-end. Verify combined scheme is secure if either layer fails.

Deployment

• Deploy hybrid mode first. Classical and post-quantum simultaneously for backward compatibility plus quantum resistance.
• Monitor NIST announcements. Algorithm recommendations may change as cryptanalysis advances.
• Document compliance status. Track which systems are migrated, algorithms in use, and pending migrations for audit purposes.
• Plan for future algorithm updates. NIST is evaluating additional algorithms (HQC). Ensure architecture accommodates additions.

H33 Compliance Mapping

Checklist Item	H33 Coverage
ML-DSA implementation	ML-DSA-65 in production attestation pipeline
ML-KEM implementation	Kyber-768 in key exchange layer
SLH-DSA implementation	SLH-DSA-SHA2-128f in three-key signer
Constant-time operations	All operations constant-time Rust
Memory zeroization	Zeroize + ZeroizeOnDrop on all key material
KAT validation	All implementations validated against NIST KATs
Crypto agility	Multi-engine architecture, algorithm swapping
Hybrid deployment	Three independent PQ families per attestation