Inhaltsverzeichnis
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
- Migration (technical) - Detailed steps
- Compliance - Regulatory requirements
- Administrator - Operational implementation
Wolfgang van der Stille @ EMSR DATA d.o.o. - Post-Quantum Cryptography Professional
Zuletzt geändert: on 2026/01/29 at 11:26 PM
