Post-Quantum Cryptography Roadmap

Purpose

This document outlines Maelstrom AI’s strategy for monitoring post-quantum cryptography (PQC) standards and planning the eventual migration from current cryptographic primitives to quantum-resistant algorithms. It addresses GAP-L002 from the full gap analysis and fulfills OWASP ASVS V11.2.2 [L3] requirements for cryptographic agility.

Document Status: Active monitoring phase Migration Timeline: 2027-2030 (estimated) Next Review: 2026-11-21 (aligned with NIST updates)

Executive Summary

The Quantum Threat

Quantum computers pose a long-term threat to current public-key cryptography:

Shor’s Algorithm (1994):

• Breaks RSA, ECDSA, ECDH, and all elliptic curve cryptography
• Polynomial-time factorization and discrete logarithm computation
• Renders Provii’s BLS12-381 and RedJubjub signatures vulnerable

Grover’s Algorithm (1996):

• Provides quadratic speedup for brute-force attacks
• Reduces effective key strength by 50%
• Example: AES-256 becomes equivalent to AES-128 against quantum adversaries
• SHA-256, BLAKE2s remain secure with current parameters

Store-Now-Decrypt-Later (SNDL) Threat:

• Adversaries may harvest encrypted data today
• Will decrypt using future quantum computers
• Provii’s Risk Profile. LOW - age credentials have issuer-configurable lifetimes (max 10 years, key rotation every 365 days)
• No long-term secrets stored in credentials

NIST Timeline

Maelstrom AI’s Position: Monitor actively, migrate proactively (2027-2030 timeframe)

Current Cryptographic Inventory

Summary

Based on analysis of provii-crypto workspace and cryptographic implementations:

Detailed Assessment

CRITICAL: Zero knowledge Proofs (Groth16 + BLS12-381)

Current Implementation:

• Algorithm: Groth16 SNARK system
• Curve: BLS12-381 pairing-friendly elliptic curve
• Library: bellman 0.14, bls12_381
• Security level: 128-bit (classical), 0-bit (quantum)

Quantum Vulnerability: HIGH

• BLS12-381 discrete logarithm vulnerable to Shor’s algorithm
• Pairing-based cryptography broken by quantum computers
• Proof forgery possible post-quantum

Migration Complexity: VERY HIGH

• No drop-in PQC replacement for Groth16
• Research areas: STARKs, lattice-based ZK (e.g., Ligero, Aurora)
• Requires circuit redesign and parameter regeneration
• Performance impact: STARKs have larger proofs (~100KB vs ~192 bytes)

Timeline: 2028-2030 (depends on PQC ZK-SNARK standardisation)

CRITICAL: Credential Signatures (RedJubjub)

Current Implementation:

• Algorithm: RedJubjub-inspired (custom variant)
• Curve: Jubjub (embedded in BLS12-381 scalar field)
• Library: redjubjub 0.8 (custom implementation)
• Security level: 128-bit (classical), 0-bit (quantum)

Quantum Vulnerability: HIGH

• Jubjub elliptic curve discrete logarithm vulnerable to Shor’s algorithm
• Signature forgery possible post-quantum
• Custom variant not compatible with Zcash RedJubjub

PQC Replacement: ML-DSA (FIPS 204)

• NIST-approved lattice-based signature scheme (August 2024)
• Security levels: ML-DSA-44 (128-bit), ML-DSA-65 (192-bit), ML-DSA-87 (256-bit)
• Signature size: ~2,420 bytes (ML-DSA-44) vs ~64 bytes (RedJubjub)
• Public key size: ~1,312 bytes vs ~32 bytes
• Performance: Fast signing/verification on modern CPUs

Migration Complexity: MEDIUM

• Direct replacement possible (signature verification)
• Requires cryptographic agility in credential format
• Backward compatibility: Hybrid signatures (classical + PQC)

Timeline: 2027-2028 (Rust libraries mature)

CRITICAL: Pedersen Commitments

Current Implementation:

• Algorithm: Pedersen commitment scheme
• Curve: BLS12-381
• Library: crypto-commit crate (custom)
• Security level: 128-bit (classical), 0-bit (quantum)

Quantum Vulnerability: HIGH

• Discrete logarithm problem vulnerable to Shor’s algorithm
• Commitment binding broken post-quantum (hiding is information-theoretic and remains secure)

PQC Replacement: Lattice-based commitments

• Research area: Module-LWE commitments, BDLOP commitments
• Standards: Not yet finalized (active research)
• Performance: Generally slower than elliptic curve commitments

Migration Complexity: HIGH

• Tightly coupled to ZK-SNARK circuit
• Requires ZK system migration first
• Part of broader circuit redesign

Timeline: 2028-2030 (with ZK-SNARK migration)

LOW RISK: Hash Functions (BLAKE2s, SHA-256, SHA-384)

Current Implementation:

• BLAKE2s: In-circuit hashing (ZKP)
• SHA-256: API authentication, general hashing
• SHA-384: Subresource integrity hashes

Quantum Vulnerability: LOW

• Grover’s algorithm provides quadratic speedup only
• Security reduction: 256-bit → 128-bit, 384-bit → 192-bit
• Current parameters sufficient post-quantum

Action: No immediate migration required

• Optional: Upgrade to SHA3-256/SHA3-512 (NIST FIPS 202)
• Optional: Upgrade to BLAKE3 (modern design, faster)

Timeline: Optional, no urgency

MEDIUM RISK: TLS (ECDHE Key Exchange)

Current Implementation:

• Cloudflare Workers TLS termination
• ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) key exchange
• Modern cipher suites (TLS 1.3 preferred)

Quantum Vulnerability: MEDIUM

• ECDHE vulnerable to Shor’s algorithm (SNDL threat)
• Perfect forward secrecy mitigates historical decryption
• Session keys ephemeral (no long-term storage)

PQC Replacement: ML-KEM (FIPS 203)

• NIST-approved lattice-based key encapsulation mechanism
• Security levels: ML-KEM-512, ML-KEM-768, ML-KEM-1024
• Cloudflare already deploying hybrid PQC TLS (50% by end of 2025)

Migration Complexity: NONE (Cloudflare-managed)

• Automatic rollout as Cloudflare deploys PQC
• No code changes required

Timeline: 2025-2026 (Cloudflare roadmap)

NIST PQC Standards Status

Finalized Standards (August 2024)

FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)

Former Name: CRYSTALS-Kyber Purpose: Key exchange (replace ECDHE) Status: FINALIZED (August 13, 2024) Security Levels: ML-KEM-512, ML-KEM-768, ML-KEM-1024 Performance: Fast key generation, encapsulation, decapsulation Provii Use Case: TLS (Cloudflare-managed), future encrypted data exchange

FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA)

Former Name: CRYSTALS-Dilithium Purpose: Digital signatures (replace ECDSA, RedJubjub) Status: FINALIZED (August 13, 2024) Security Levels: ML-DSA-44, ML-DSA-65, ML-DSA-87 Performance: Fast signing and verification Provii Use Case: Credential signing (primary candidate)

Key Parameters (ML-DSA-44):

• Security: 128-bit quantum resistance
• Public key: 1,312 bytes
• Secret key: 2,528 bytes
• Signature: 2,420 bytes
• Performance: ~2,000 signs/sec, ~4,000 verifies/sec (typical CPU)

Migration Path:

1. Implement hybrid signatures (RedJubjub + ML-DSA)
2. Gradually transition to pure ML-DSA
3. Maintain backward compatibility via version field

FIPS 205: Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)

Former Name: SPHINCS+ Purpose: Hash-based signatures (backup to ML-DSA) Status: FINALIZED (August 13, 2024) Security Levels: Multiple (128-bit, 192-bit, 256-bit) Performance: Slower than ML-DSA (milliseconds per signature) Provii Use Case: Backup signature scheme (high security, low volume)

Characteristics:

• Security: Based only on hash function security (conservative)
• Signature size: Large (~7KB to ~50KB depending on parameters)
• Performance: Slow signing, fast verification
• Use case: Long-term signatures, critical operations

Future Standards (Expected 2028)

FIPS 206: Additional Signature Schemes

Candidates: FN-DSA (Falcon), potentially others Status: Draft expected 2025-2026, finalized ~2028 Provii Impact: Alternative to ML-DSA if needed

Standards to Monitor

NIST Publications

Industry Standards

PQC Research (Zero knowledge Proofs)

No NIST standards yet for post-quantum ZK-SNARKs

Active research areas:

• STARKs (Scalable Transparent Arguments of Knowledge): Quantum-resistant, large proofs
• Lattice-based ZK. Research phase (Ligero, Aurora, Hyrax)
• Hash-based ZK. zkSTARK variants
• Hybrid approaches. Classical ZK + PQC signatures

Timeline: 2026-2030 for production-ready implementations

Migration Triggers

When to Begin Migration

Maelstrom AI will initiate PQC migration when THREE or more of the following triggers occur:

TRIGGER 1: NIST Standards Finalized

Status: ✅ ACHIEVED (August 2024)

• FIPS 203, 204, 205 finalized
• Industry consensus on ML-KEM, ML-DSA

Action: Continue monitoring for errata and implementation guidance

TRIGGER 2: Rust Library Maturity

Status: 🔄 IN PROGRESS (60% mature)

Required:

• Production-ready Rust implementation of ML-DSA (FIPS 204)
• Audited by reputable cryptography firm
• Active maintenance and security updates
• WASM compatibility (for browser-based wallet)

Current Status:

• pqcrypto crate: Available but not widely audited
• oqs-rust (Open Quantum Safe): Bindings to liboqs (C library)
• RustCrypto PQC support: In development

Monitoring:

• GitHub: rustcrypto/signatures, rustcrypto/KEMs
• Crates.io: pqcrypto-ml-dsa, ml-dsa

Threshold: Library with 10,000+ downloads/month, 1+ security audit

TRIGGER 3: Performance Benchmarks Acceptable

Status: ⏳ PENDING (benchmarking not yet done)

Requirements:

• Mobile signature verification: <100ms (RedJubjub: ~10ms)
• Mobile proof generation: <5 seconds (Groth16: ~2 seconds)
• Credential size increase: <10KB (current: ~300 bytes)

Action Plan:

• Benchmark ML-DSA on target devices (iOS, Android) when libraries mature
• Benchmark PQC ZK-SNARK candidates when available

Threshold: 5x performance degradation acceptable, 10x unacceptable

TRIGGER 4: Cryptographic Agility Achieved

Status: 🔄 PARTIAL (70% complete)

Requirements:

• Version field in credentials (supports algorithm changes)
• JWKS supports multiple key types
• Verifiers can handle multiple signature algorithms
• Circuit parameter versioning

Current State:

• ✅ Credential format has v (version) field
• ✅ JWKS supports kid (key ID) for rotation
• ⚠️ No multi-algorithm signature support yet
• ❌ No PQC signature verification implemented

Gap: Multi-algorithm signature support not yet implemented

TRIGGER 5: Threat Surface Changes

Status: ⏳ MONITORING (no immediate threat)

Triggers:

• Cryptographically relevant quantum computer (CRQC) demonstration
• Major breakthrough in quantum algorithms (better than Shor’s)
• Nation-state adversary demonstrates quantum cryptanalysis
• Maelstrom AI stores long-lived secrets (>10 years) - NOT APPLICABLE

Current Assessment:

• No CRQC demonstrated (IBM Condor: 1,121 qubits, error-prone)
• Shor’s algorithm requires ~1,000-10,000 logical qubits
• NIST estimates 2030-2035 timeline

Monitoring:

• Quarterly review of NIST/NSA quantum threat assessments
• Annual review of quantum computing milestones

Migration Roadmap

Phase 1: Monitoring and Preparation (Ongoing)

Focus: Research, evaluation, monitoring

Deliverables:

• ✅ Q1 2025: Document PQC roadmap (this document)
• Monitor NIST SP 800-227 (migration guidance) as published
• Evaluate Rust PQC libraries (ml-dsa, pqcrypto) when mature
• Benchmark ML-DSA on mobile devices when libraries are production-ready
• Prototype hybrid signatures (RedJubjub + ML-DSA) when Trigger 2 met
• Implement cryptographic agility (multi-algorithm support) when prototyping validates approach

Resourcing: internal R&D (no dedicated budget) Effort: 2-4 weeks total (spread as triggers are met) Owner: Cryptography Specialist

Success Criteria:

• ML-DSA library selected and benchmarked
• Hybrid signature prototype functional
• Performance acceptable (<5x degradation)

Phase 2: Hybrid Deployment (2027-2028)

Focus: Implement hybrid cryptography (classical + PQC)

Rationale: Hedge against both classical and quantum attacks

• Classical crypto protects against current threats
• PQC protects against future quantum threats
• Maintains backward compatibility

Deliverables:

• Q1 2027: Implement hybrid credential signatures in provii-crypto
• Credential contains both RedJubjub AND ML-DSA signatures
• Verifiers check both (either can validate)
• Update crypto-sig, crypto-sig-redjubjub, crypto-commit, crypto-verifier, crypto-prover crates
• Q2 2027: Deploy to provii-issuer (hybrid signing) and provii-verifier hosted mode (hybrid verification)
• Q3 2027: Update provii-mobile-sdk (hybrid signing/verification) and provii-mobile (iOS + Android)
• Q4 2027: Update provii-verifier (hybrid verification) and provii-agegate (WASM verification bundle)
• Q1 2028: Monitor hybrid deployment across all services (3+ months production data)
• Q2 2028: Gradual rollout to all issuers (100% hybrid by end of Q2)

Cryptographic Agility Implementation:

{
  "v": 3,
  "kid": "provii:2027-q1",
  "c": "<commitment-hex>",
  "iat": 1735689600,
  "exp": 1743552000,
  "schema": "provii.age/1",
  "sig_classical": {
    "alg": "RedJubjub",
    "sig": "<64-byte-signature>"
  },
  "sig_pqc": {
    "alg": "ML-DSA-44",
    "sig": "<2420-byte-signature>"
  }
}

Backward Compatibility:

• Old verifiers (v2): Verify sig_classical only
• Hybrid verifiers (v3): Verify both (accept if either valid)
• PQC-only verifiers (v4): Verify sig_pqc only

Effort: 12-16 weeks total

• Library integration: 4-6 weeks engineering
• Testing: 2-3 weeks QA
• Mobile wallet updates: 3-4 weeks
• Verifier updates: 2-3 weeks
• Documentation: 1 week

Owner: Cryptography Specialist + Developer

Success Criteria:

• 100% of credentials dual-signed (classical + PQC)
• No performance regression >2x
• Zero signature verification failures

Phase 3: Full PQC Migration (2029-2030)

Focus: Transition to pure PQC signatures, deprecate classical crypto

Prerequisites:

• Hybrid deployment stable for 18+ months
• All verifiers support PQC verification
• PQC ZK-SNARK research matured (or alternative approach)

Deliverables:

• Q1 2029: Announce classical signature deprecation (12-month notice)
• Q2 2029: Implement PQC-only credential format (v4)
• Q3 2029: Research PQC ZK-SNARK options (STARKs, lattice-based ZK)
• Q4 2029: Deploy PQC-only issuers (gradual rollout)
• Q1 2030: Prototype PQC ZK-SNARK system
• Q2 2030: Deprecate classical-only verifiers
• Q3-Q4 2030: Evaluate ZK-SNARK migration feasibility

ZK-SNARK Migration Options:

Option 1: STARKs (Scalable Transparent Arguments of Knowledge)

• Quantum-resistant (hash-based security)
• Larger proofs (~100KB vs ~192 bytes for Groth16)
• No trusted setup required (transparency benefit)
• Performance: Slower proving, faster verification
• Libraries: winterfell, cairo-rs (Starkware)

Option 2: Lattice-based ZK (Research Phase)

• Quantum-resistant (lattice assumptions)
• Proof size: Unknown (research ongoing)
• Performance: Unknown (research ongoing)
• Timeline: 2028-2032 for production readiness

Option 3: Hybrid Approach (Most Likely)

• Keep Groth16 for proofs (accept quantum risk)
• Use PQC signatures for credential authenticity
• Rationale: Age credentials are ephemeral (60-90 days)
• Risk: Quantum computers in 2035+ could forge proofs from 2030-2035
• Mitigation: Credential expiry limits exposure window

Decision Point: Q3 2029 (based on PQC ZK research progress)

Effort: 28-43 weeks total

• Engineering: 12-20 weeks
• ZK-SNARK research/prototyping: 8-12 weeks
• Security audit (PQC implementation): included in effort estimate
• Testing and QA: 6-8 weeks
• Documentation: 2-3 weeks

Owner: Cryptography Specialist + Developer + External Cryptography Consultant

Success Criteria:

• 100% of credentials PQC-signed
• Classical signatures deprecated
• ZK-SNARK migration path validated (or hybrid justified)
• Zero cryptographic vulnerabilities identified in audit

Risk Assessment

SNDL (Store-Now-Decrypt-Later) Threat

Attack Scenario:

1. Adversary harvests encrypted age credentials today (2025)
2. Stores encrypted data for 10-15 years
3. Decrypts using quantum computer in 2035+
4. Recovers age verification proofs and commitments

Maelstrom AI’s Exposure: LOW

Mitigating Factors:

1. Credential Lifecycle: Age credentials have issuer-configurable lifetimes with key rotation every 365 days (annually)

• Credentials contain no PII (only a Pedersen commitment and signature)
• No long-term value to adversary even if harvested

2. No PII in Credentials: Zero knowledge design

• Commitment c is cryptographically random
• No name, DOB, ID number stored
• Proof reveals only age threshold (e.g., “over 18”)

3. Perfect Forward Secrecy: TLS with ECDHE

• Session keys destroyed after use
• Historical traffic not decryptable (even with quantum)

4. Short Validity Window: Proofs valid for minutes

• Generated just-in-time for verification
• No replay value after expiry

Residual Risk: Adversary could forge NEW credentials post-quantum

• Requires breaking RedJubjub signing key
• Requires issuer key compromise (additional layer)
• Risk window: 2030-2035 (before Maelstrom AI migrates to PQC)

Mitigation: Accelerate PQC migration if quantum threat materialises earlier than 2030

Quantum Computer Timeline Uncertainty

NIST Estimate: 2030-2035 (medium confidence) Optimistic Estimate: 2040+ (conservative cryptographers) Pessimistic Estimate: 2028-2030 (rapid quantum progress)

Maelstrom AI’s Strategy: Plan for 2030 (middle estimate)

• Hybrid deployment by 2028 (2 years before threat)
• Full PQC migration by 2030 (at estimated threat)
• Hedge against uncertainty with hybrid approach

Contingency Plan: If CRQC demonstrated before 2028:

1. Accelerate hybrid deployment (6-month emergency timeline)
2. Prioritise PQC signatures over ZK-SNARK migration
3. Accept larger credential sizes (pragmatism over optimisation)

Performance Impact on Mobile Devices

Current Performance (Groth16 + RedJubjub):

• Proof generation: ~2 seconds (mobile)
• Proof verification: ~500ms (mobile)
• Signature verification: ~10ms (mobile)
• Credential size: ~300 bytes

Estimated PQC Performance (ML-DSA + Groth16):

• Proof generation: ~2 seconds (unchanged)
• Proof verification: ~500ms (unchanged)
• Signature verification: ~50ms (5x slower, acceptable)
• Credential size: ~2.7KB (9x larger, acceptable)

Estimated PQC Performance (ML-DSA + STARKs):

• Proof generation: ~10 seconds (5x slower, marginal)
• Proof verification: ~200ms (faster than Groth16)
• Signature verification: ~50ms (5x slower)
• Credential size: ~103KB (343x larger, problematic)

Risk: STARKs may be too slow/large for mobile wallets Mitigation: Hybrid approach (PQC signatures + Groth16 proofs)

Cryptographic Agility Gaps

Current State: Partial agility

• ✅ Credential version field (v)
• ✅ Key rotation support (JWKS kid)
• ⚠️ Single signature algorithm (RedJubjub only)
• ❌ No multi-algorithm verification

Gap: Cannot deploy PQC without breaking old verifiers

Remediation (Phase 1):

1. Implement multi-algorithm signature support
2. Update credential schema to support sig_classical and sig_pqc
3. Update verifiers to check both signatures (accept if either valid)
4. Maintain backward compatibility via version negotiation

Timeline: When Rust PQC libraries mature (prerequisite for hybrid deployment)

Resources and Dependencies

Rust PQC Libraries to Monitor

Primary Candidates

1. RustCrypto PQC Implementations

• Repository: https://github.com/RustCrypto/signatures
• Status: In development (ML-DSA support planned)
• Audit Status: RustCrypto generally well-audited
• Our Preference: HIGH (native Rust, idiomatic API)

2. pqcrypto crate

• Repository: https://github.com/rustpq/pqcrypto
• Algorithms: ML-KEM, ML-DSA, SLH-DSA, FN-DSA (Falcon)
• Status: Maintained, but bindings to C code
• Audit Status: Unknown
• Our Preference: MEDIUM (fallback if RustCrypto unavailable)

3. oqs-rust (Open Quantum Safe)

• Repository: https://github.com/open-quantum-safe/liboqs-rust
• Algorithms: Full NIST PQC suite
• Status: Actively maintained, bindings to liboqs (C)
• Audit Status: liboqs audited by multiple firms
• Our Preference: MEDIUM (mature, but C dependencies)

4. Custom Implementation

• Option: Implement ML-DSA in pure Rust
• Status: Not started
• Effort: 12-16 weeks + external audit
• Our Preference: LOW (high effort, unnecessary)

Evaluation Criteria

Decision: Prefer RustCrypto implementations when available (H1 2026 target)

ZK-SNARK PQC Research

No production-ready post-quantum ZK-SNARKs exist (as of 2025)

Research Surface

1. STARKs (Scalable Transparent Arguments of Knowledge)

• Security: Hash-based (quantum-resistant)
• Proof Size: ~100KB (vs ~192 bytes for Groth16)
• Performance: Slower proving, faster verification
• Trusted Setup: None required (transparency benefit)
• Status: Production-ready (Starkware, Polygon Miden)
• Libraries: winterfell (Rust), cairo-rs

2. Lattice-based ZK (Research Phase)

• Security: Lattice assumptions (quantum-resistant)
• Examples: Ligero, Aurora, Hyrax, Spartan
• Proof Size: Variable (10KB-1MB)
• Performance: Highly variable
• Status: Academic research, no production implementations
• Timeline: 2028-2032 for production readiness

3. Post-Quantum Bulletproofs

• Security: Lattice assumptions
• Proof Size: ~10KB (vs ~192 bytes for Groth16)
• Performance: Slower than Groth16
• Status: Research phase
• Timeline: Unknown

Monitoring

Academic Conferences:

• CRYPTO. Annual cryptography conference (August)
• Eurocrypt. European cryptography conference (April)
• IEEE S&P. Security and Privacy symposium (May)
• IACR ePrint. Preprint archive (continuous)

Industry Initiatives:

• zkSummit. Annual ZK conference
• Starkware Blog. STARK developments
• Polygon Labs. zkEVM PQC research
• Aztec Protocol. Privacy-focused ZK (monitoring PQC)

Quarterly Review: Cryptography Specialist reviews latest PQC ZK research Annual Decision: Re-evaluate ZK-SNARK migration feasibility

Budget Estimates

Effort Notes:

• Effort estimates assume senior cryptography engineering resourcing
• Security audit engagement is included within Phase 3 effort
• Effort may decrease if open source libraries mature (reducing engineering scope)

Compliance and Regulatory Drivers

Monitoring and Review Process

Quarterly Reviews (Q1, Q2, Q3, Q4)

Responsible: Cryptography Specialist Duration: 2-3 hours Deliverable: Quarterly PQC Status Report

Review Checklist:

1. NIST Standards Updates:

• Check NIST CSRC for new publications (SP 800-227, FIPS 206)
• Review errata for FIPS 203, 204, 205
• Note any algorithm deprecations or security advisories

2. Quantum Computing Milestones:

• Review IBM, Google, IonQ quantum roadmaps
• Check for CRQC demonstrations or breakthroughs
• Update threat timeline if necessary

3. Rust Library Maturity:

• Check RustCrypto PQC implementation status
• Review crates.io downloads for pqcrypto, oqs-rust
• Monitor security advisories (RustSec, GitHub)

4. Industry Adoption:

• Survey competitor PQC adoption (privacy-preserving identity systems)
• Review Cloudflare PQC TLS rollout status
• Note any major PQC deployments (Google, Meta, AWS)

5. ZK-SNARK Research:

• Review IACR ePrint for post-quantum ZK papers
• Check STARK implementations (Starkware, Polygon)
• Note any production-ready PQC ZK systems

6. Migration Trigger Assessment:

• Re-evaluate five migration triggers (see above)
• Update trigger status (achieved, in progress, pending)
• Recommend acceleration if multiple triggers met

Output: One-page status report with recommendations

Annual Review (Q4)

Responsible: Cryptography Specialist + ISMS Owner Duration: 4-6 hours Deliverable: Annual PQC Roadmap Update

Review Scope:

1. Roadmap Timeline Adjustment:

• Re-evaluate Phase 1, 2, 3 timelines
• Accelerate or defer based on threat surface
• Update budget estimates

2. Risk Reassessment:

• Re-score SNDL threat (based on quantum progress)
• Update performance impact estimates (new benchmarks)
• Reassess cryptographic agility gaps

3. Standards Compliance:

• Verify compliance with new NIST guidance
• Update OWASP ASVS compliance status
• Prepare for ISO 27001 annual review

4. Budget Planning:

• Allocate budget for next phase
• Adjust estimates based on actual costs
• Approve external consultants/audits if needed

Output: Updated PQC roadmap document (this document)

Emergency Review Triggers

Immediate review required if:

1. CRQC Demonstrated: Cryptographically relevant quantum computer breaks RSA-2048 or ECDSA-256
2. Zero-Day in Current Crypto: Critical vulnerability in BLS12-381, RedJubjub, or Groth16
3. NIST Deprecation: NIST deprecates current algorithms earlier than expected
4. Regulatory Mandate: New regulation requires PQC by specific date

Response Time: 48 hours Action: Convene emergency review, assess impact, update roadmap, communicate to stakeholders

Success Criteria

Phase 1 Success Criteria (Ongoing)

✅ Monitoring:

• Quarterly PQC status reports delivered
• NIST standards tracked (FIPS 203-206, SP 800-227)
• Rust library surface surveyed

✅ Prototyping:

• ML-DSA library selected (RustCrypto preferred)
• Hybrid signature prototype functional
• Performance benchmarks completed (mobile devices)

✅ Cryptographic Agility:

• Multi-algorithm signature support implemented
• Credential schema updated (v3 with sig_classical, sig_pqc)
• Backward compatibility tested

✅ Documentation:

• PQC roadmap published (this document)
• Developer documentation updated
• Stakeholder communication completed

Phase 2 Success Criteria (2027-2028)

✅ Hybrid Deployment:

• 100% of credentials dual-signed (RedJubjub + ML-DSA)
• Issuer-api updated (hybrid signing)
• Wallet-mobile updated (hybrid verification)
• Verifier-api updated (hybrid verification)

✅ Performance:

• Signature verification: <100ms (mobile)
• No user-visible performance degradation
• Credential size: <5KB (acceptable)

✅ Stability:

• 6+ months production deployment
• Zero signature verification failures
• No cryptographic vulnerabilities identified

✅ Backward Compatibility:

• Old verifiers (v2) still functional
• Hybrid verifiers (v3) accept both signatures
• Gradual rollout completed (no breaking changes)

Phase 3 Success Criteria (2029-2030)

✅ PQC-Only Deployment:

• 100% of credentials PQC-signed (ML-DSA only)
• Classical signatures deprecated (12-month notice)
• All verifiers support PQC verification

✅ ZK-SNARK Migration:

• Decision made: STARK migration, hybrid approach, or defer
• If migrating: PQC ZK-SNARK prototype functional
• If hybrid: Groth16 quantum risk accepted and documented

✅ Security Audit:

• External cryptography audit completed
• Zero high/critical findings
• All recommendations addressed

✅ Compliance:

• NIST SP 800-227 compliance achieved
• OWASP ASVS V11.2.2 [L3] fully compliant
• ISO 27001 Control A.8.24 updated

Related Documents

• Cryptography Policy - Current cryptographic standards
• Gap Analysis - GAP-L002 identified
• Statement of Applicability - Control A.8.24
• provii-crypto README - Cryptographic implementation details
• Gap Analysis - Full compliance gaps

External References

• NIST PQC Project
• NIST FIPS 203 (ML-KEM)
• NIST FIPS 204 (ML-DSA)
• NIST FIPS 205 (SLH-DSA)
• NSA CNSA 2.0
• Cloudflare PQC
• RustCrypto
• Open Quantum Safe

Document Information

• Version. 2.0
• Effective Date. 2025-11-08 (initial), 2026-05-21 (updated)
• Owner. ISMS Owner
• Maintained By. Cryptography Specialist
• Review Frequency. Quarterly (NIST updates), Annual (roadmap)
• Next Review. 2026-11-21
• Classification. Public
• Related Gap. GAP-L002 (Post-Quantum Cryptography Roadmap)