====== 2.3 Strategy & Technology ====== Strategic planning and technology decisions for post-quantum cryptography. ---- ===== Migration Phases ===== Phase 1 Phase 2 Phase 3 Phase 4 ------- ------- ------- ------- Preparation Hybrid Validation PQ-Only Today --------------------------------------------------------------------------> Future Install New certs Validate PQ only library hybrid both sigs (optional) ---- ===== Phase 1: Preparation ===== **Activities:** * Evaluate NuGet package * Deploy OpenSSL 3.6 in test environment * Inventory: Which systems use cryptography? * Risk assessment: Which data has long protection requirements? **Result:** Library installed, in Classic mode (no behavior change) ---- ===== Phase 2: Enable Hybrid ===== **Activities:** * Enable CryptoMode.Hybrid in pilot project * Create new certificates (automatically hybrid) * Compatibility testing with legacy clients * Gradual rollout to additional systems **Result:** New certificates are PQ-protected, old ones continue to work ---- ===== Phase 3: Validation ===== **Activities:** * Enable PQ signature validation * Set up monitoring for validation errors * Gradually replace legacy certificates * Documentation and training **Result:** Full hybrid validation active ---- ===== Phase 4: PQ-Only (optional) ===== **Prerequisite:** All systems PQ-capable **Activities:** * Enable CryptoMode.PostQuantum * Remove legacy support * Full PQ security **Note:** For most organizations, Phase 3 is sufficient. ---- ===== Prioritization ===== ^ Priority ^ Systems ^ Rationale ^ | 1 (immediate) | Long-term archives, contracts | Highest protection requirement | | 2 (short-term) | PKI, certificate infrastructure | Foundation for other systems | | 3 (medium-term) | APIs, web services | Ongoing communication | | 4 (later) | Internal systems | Lower interception risk | ---- ===== Technology Decisions ===== ==== Why OpenSSL 3.6? ==== ^ Criterion ^ OpenSSL 3.6 ^ Alternatives ^ | **FIPS Validation** | FIPS 140-3 validatable | Bouncy Castle: No FIPS | | **PQ Algorithms** | ML-DSA, ML-KEM native | liboqs: Experimental | | **Maintenance** | OpenSSL Foundation, long-term | Small teams, uncertain | | **Performance** | Hardware-optimized (AES-NI, AVX) | Often pure software | ==== Why AES-256-GCM? ==== ^ Criterion ^ AES-256-GCM ^ ChaCha20-Poly1305 ^ | **FIPS Certification** | FIPS 197 (standard) | Not FIPS-certified | | **Hardware Support** | AES-NI on all CPUs | No hardware acceleration | | **PQ Security** | 128-bit post-quantum | 128-bit post-quantum | ==== Why Hybrid instead of PQ-Only? ==== ^ Aspect ^ Hybrid (recommended) ^ PQ-Only ^ | **Risk** | Minimal - two security layers | Higher - only PQ algorithms | | **Compatibility** | Legacy systems work | Breaks legacy | | **NIST Recommendation** | Recommended for transition | Only after migration | ---- ===== Summary for Audits ===== ^ Decision ^ Rationale ^ Reference ^ | OpenSSL 3.6 | FIPS-validatable, industry standard | OpenSSL Foundation | | AES-256-GCM | FIPS 197 certified, hardware-accelerated | NIST FIPS 197 | | ML-DSA/ML-KEM | NIST standardized (FIPS 203/204) | NIST PQC Project | | Hybrid mode | NIST/BSI recommended, defensive | NIST SP 800-227 | ---- ===== Success Factors ===== * **Executive Sponsorship:** Management support * **Early Start:** Don't wait for quantum computers * **Phased Rollout:** Risk minimization through phases * **Monitoring:** Detect and fix validation errors * **Documentation:** For audits and knowledge transfer ---- ===== Further Reading ===== * [[en:int:pqcrypt:developer:migration|Migration (technical)]] - Detailed steps * [[.:compliance|Compliance]] - Regulatory requirements * [[en:int:pqcrypt:administrator:start|Administrator]] - Operational implementation ---- //Wolfgang van der Stille @ EMSR DATA d.o.o. - Post-Quantum Cryptography Professional// {{tag>strategy migration planning technology audit}}