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 fulfils OWASP ASVS V11.2.2 [L3] requirements for cryptographic agility.

Document Status: Active monitoring phase (Provii migration); downpipes archive sealing already post-quantum Migration Timeline: 2027-2030 (estimated, Provii) 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 factorisation 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
• downpipes’ Risk Profile. ALREADY MITIGATED - backup archives are long-lived data and would otherwise be the obvious SNDL target, but they are sealed at rest with post-quantum hybrid encryption under customer-held keys before they leave the source tenant. Harvested archive bytes are not decryptable by a future quantum adversary.

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 finalised (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)

downpipes: Already Post-Quantum

The inventory above covers Provii’s classical primitives, which sit on the migration curve. downpipes is on the other side of that curve already: it was designed post-quantum from the outset, so it has no migration to schedule for the data it protects.

downpipes is no-custody backup & disaster recovery for the Cloudflare data layer. The backup engine runs in the customer’s own Cloudflare account, under the customer’s own keys; Maelstrom holds no customer keys, data or Cloudflare tokens.

Archive Sealing (Post-Quantum at Rest)

The engine reads sources (Workers KV, D1, R2, Secrets Store and 51 zone/account configuration surfaces) and seals each archive with post-quantum hybrid encryption before fanning it out (3-2-1) to two or more customer-controlled destinations. Because sealing is hybrid (a classical and a post-quantum key-encapsulation mechanism combined), harvested archive bytes resist both current and future quantum cryptanalysis — the store-now-decrypt-later threat to backed-up data is mitigated today, not on a future timeline.

Customer-Held Keys (No-Custody)

Archives are sealed under customer-held keys (break-glass, operational and archive-signer keys), generated by the customer through a guided in-browser key ceremony and stored offline (encrypted USB, password manager, or Shamir split; a printed recovery sheet is produced during the ceremony). Maelstrom cannot decrypt, recover or rotate these keys — by design. Safeguarding them is a complementary user-entity control (CUEC) borne by the customer.

Vendor-Side Signing Keys

Maelstrom holds two vendor-side downpipes signing keys, neither of which protects customer archive contents:

• downpipes Licence Signer — held in Cloudflare Secrets Store (control-plane account); the licence is fail-open and never gates backup or restore.
• downpipes Update Signer — held offline by the operator and never deployed to any Worker. The engine verifies update signatures against a pinned public key before applying, and pulls (never receives a push) from the signature-pinned update channel (updates.downpipes.io).

These two signers are classical signature keys, so they are tracked under the same NIST monitoring and cryptographic-agility discipline as Provii’s classical signatures (a candidate ML-DSA/SLH-DSA migration when the libraries mature). They present no SNDL exposure: neither signs data with a decades-long confidentiality requirement, and the update signer is held offline and never deployed.

Dogfooding

Maelstrom’s entire Cloudflare estate is backed up by our own production instance of downpipes (we run downpipes as a customer of our own product). In that deployment the post-quantum archive sealing described above protects Maelstrom’s own backups. See Cloudflare Backup Evidence.

NIST PQC Standards Status

Finalised Standards (August 2024)

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

Former Name: CRYSTALS-Kyber Purpose: Key exchange (replace ECDHE) Status: FINALISED (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 downpipes Use Case: A post-quantum KEM of this class is already in use as the post-quantum half of downpipes’ hybrid archive sealing (see downpipes: Already Post-Quantum)

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

Former Name: CRYSTALS-Dilithium Purpose: Digital signatures (replace ECDSA, RedJubjub) Status: FINALISED (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: FINALISED (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, finalised ~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 Finalised

Status: ✅ ACHIEVED (August 2024)

• FIPS 203, 204, 205 finalised
• 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

downpipes (already mitigated): Backup archives are the natural SNDL target — they are long-lived and contain the customer’s actual KV/D1/R2/Secrets Store/configuration data. Unlike Provii’s ephemeral credentials, downpipes does not rely on a future migration: archives are already sealed with post-quantum hybrid encryption under customer-held keys before leaving the source tenant (see downpipes: Already Post-Quantum). Because the protecting keys are no-custody (customer-held), Maelstrom holds nothing a quantum adversary could later decrypt. The downpipes vendor-side signers (licence, update) sign no confidential, long-lived data, so they carry no SNDL exposure.

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 for both platforms (incl. the downpipes post-quantum archive-sealing profile)
• Gap Analysis - GAP-L002 identified
• Statement of Applicability - Control A.8.24
• Cloudflare Backup Evidence - downpipes dogfooding evidence
• 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.1
• Effective Date. 2025-11-08 (initial), 2026-05-21 (updated)
• Last Updated. 2026-06-19
• 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)
• Change History. v2.1 (2026-06-19) — downpipes added as second in-scope platform (already post-quantum: archives sealed with post-quantum hybrid encryption under customer-held keys); the legacy backup worker retired in favour of self-hosted downpipes.