Preparing for Post-Quantum Cryptography in Container Images

Quantum computers pose a theoretical threat to current encryption algorithms (RSA, ECDSA). While quantum computers don't exist yet, organizations should plan post-quantum migration starting now.

CleanStart supports post-quantum algorithms alongside traditional crypto for smooth transition.

The Quantum Threat

Which Algorithms Are at Risk?

Several widely-used cryptographic algorithms face a threat from quantum computers. RSA (all key sizes), ECDSA (elliptic curve), ECDH (key exchange), and Diffie-Hellman are all vulnerable and could be broken within 10-15 years once quantum computers arrive.

However, other algorithms remain secure even against quantum threats. AES-256 (symmetric encryption) and SHA-256 (hashing) are fundamentally resistant to quantum attacks due to their design. Newer lattice-based algorithms and hash-based signatures are also quantum-resistant and form the basis of NIST's post-quantum standards.

Timeline

The migration to post-quantum cryptography follows a long-term roadmap. In 2024, NIST is finalizing post-quantum standards. From 2025-2030, early adoption will occur using hybrid algorithms. After 2030, the majority transition to post-quantum will take place. By 2040 and beyond, legacy RSA will no longer be acceptable.

The key takeaway is to start transitioning by 2025 to be ahead of the curve.

NIST Post-Quantum Standards

NIST standardized post-quantum algorithms in 2022-2024:

ML-KEM (Kyber) - Key Exchange

ML-KEM (also known as Kyber) is standardized as FIPS 203 and serves as the post-quantum replacement for RSA and ECDH key exchange. It uses key sizes of 768-1024 bits and performs very fast with approximately 1000 operations per second. This algorithm has high maturity and is already used in production pilots.

Kyber offers three variants with increasing security levels: Kyber-512 provides 128-bit security, Kyber-768 provides 192-bit security (recommended for most deployments), and Kyber-1024 provides 256-bit security for applications requiring the highest strength.

ML-DSA (Dilithium) - Digital Signatures

ML-DSA (also known as Dilithium) is standardized as FIPS 204 and replaces RSA-PSS and ECDSA for digital signatures. It uses key sizes ranging from 1152 to 2552 bits with fast performance at approximately 100 signing operations per second. The algorithm has high maturity and is ready for production use.

Dilithium offers three variants with increasing security levels: Dilithium2 provides 128-bit security, Dilithium3 provides 192-bit security (recommended), and Dilithium5 provides 256-bit security for maximum protection.

SLH-DSA (SPHINCS+) - Alternative Signature

Status: FIPS 205 (standardized)Purpose: Stateless hash-based signaturesKey Size: 64-135 bytesPerformance: Slower but proven secureMaturity: High (extreme confidence) Use case: Long-term archival, extreme security needs

Hybrid Approach (Recommended)

The recommended strategy uses both post-quantum AND traditional algorithms during the transition period, providing defense in depth against both current and future quantum threats.

For TLS 1.3, use a hybrid key exchange that combines Traditional ECDHE-P256 with Post-Quantum Kyber-768. Both key exchange operations are performed and both ciphertexts are concatenated, meaning an attacker would need to break both algorithms to derive the shared secret.

For certificate signatures, sign with both traditional ECDSA and post-quantum Dilithium-3, including both signatures in the certificate. This ensures the certificate is valid even if one algorithm is broken.

The migration follows a three-phase timeline. From 2025-2028, use hybrid mode to be safe against both classical attacks (using traditional crypto) and future quantum attacks (using post-quantum crypto). From 2028-2035, phase out traditional algorithms as quantum computers remain theoretical. After 2035, use post-quantum only.

Benefits of the hybrid approach include current safety (traditional encryption still works today), future safety (post-quantum provides quantum resistance), gradual transition without false urgency, and insurance against single-algorithm failure.

Implementing Hybrid TLS

Generate Post-Quantum Certificate

# Generate ML-DSA private keyopenssl genpkey -algorithm dilithium3 -out key.pem # Create certificate requestopenssl req -new -key key.pem -out req.csr # Sign certificateopenssl x509 -req -in req.csr \  -signkey key.pem \  -out cert.pem \  -days 365 # Verify post-quantum certificateopenssl x509 -in cert.pem -text -noout# Subject Public Key Info: Dilithium 3 (post-quantum)

Hybrid TLS Configuration (Nginx)

# nginx.conf - Hybrid RSA + Dilithium server {    listen 443 ssl http2;    server_name example.com;     # Primary certificate (post-quantum, for future)    ssl_certificate /etc/nginx/certs/dilithium3.crt;    ssl_certificate_key /etc/nginx/certs/dilithium3.key;     # Additional certificate (traditional, for compatibility)    ssl_certificate /etc/nginx/certs/rsa2048.crt;    ssl_certificate_key /etc/nginx/certs/rsa2048.key;     # Both certificates will be offered to clients    # Clients choose which to accept}

Hybrid TLS Handshake

In a hybrid TLS 1.3 handshake, the client initiates with a ClientHello message that includes both traditional ECDHE parameters and post-quantum Kyber-768 parameters, along with a list of supported ciphers. The server responds with a ServerHello and offers both certificates—a traditional RSA certificate for backward compatibility and a post-quantum Dilithium certificate for future-proofing. The server performs ServerKeyExchange using both ECDHE and Kyber algorithms simultaneously.

The client then performs ClientKeyExchange by sending both the traditional ECDHE shared secret and the Kyber-768 shared secret. Both secrets are combined to create the final session key. The Finished messages confirm the handshake, but decryption of the session requires both shared secrets. Even if one key derivation method is compromised, the other remains intact, ensuring confidentiality is maintained through either algorithm.

Migration Timeline

Phase 1: Evaluation (2024-2025)

During the evaluation phase, test your organization's post-quantum readiness using available tools. Run assessments of your cryptographic infrastructure to understand which systems use vulnerable RSA and ECDSA algorithms. Verify that OpenSSL 3.2+ is available in your environment, as this version provides full support for NIST post-quantum standards. Test whether your infrastructure can generate post-quantum certificates and perform hybrid TLS handshakes. Based on assessment results, develop a timeline for beginning hybrid implementation.

Phase 2: Hybrid Rollout (2025-2028)

During the hybrid rollout phase, deploy systems using both traditional and post-quantum certificates. Configure TLS servers to offer both RSA certificates for backward compatibility and post-quantum Dilithium certificates for future-proofing. Configure both traditional and post-quantum key material, allowing clients to choose which key exchange algorithm they prefer. This dual implementation protects against both current attacks (using traditional cryptography) and future quantum attacks (using post-quantum cryptography).

Phase 3: Full Migration (2028-2035)

Eventually migrate to post-quantum cryptography exclusively. Phase out all traditional RSA and ECDSA certificates in favor of post-quantum Dilithium certificates. Discontinue support for traditional TLS cipher suites, requiring all clients to support post-quantum algorithms. By 2030, major browsers and libraries will support post-quantum cryptography, making this transition feasible at scale.

Current Support Status

Which Systems Support Post-Quantum?

Post-quantum support is rapidly emerging across the technology ecosystem. OpenSSL version 3.0 and higher provide experimental post-quantum support, while OpenSSL 3.2 and later offer full support for NIST FIPS 203, 204, and 205 standards. The Go programming language supports hybrid TLS through liboqs integration, while Python supports it through liboqs wrapper libraries. Node.js provides partial support through libcrypto bindings, and Java offers limited support through the Bouncy Castle cryptography library. Major web browsers including Chrome, Firefox, and Safari are currently in testing phases for post-quantum support and will enable it by default in the 2026-2030 timeframe.

Testing Post-Quantum

Test hybrid TLS handshakes using OpenSSL command-line tools to verify your infrastructure supports both traditional and post-quantum cryptography. Use the openssl s_client tool with parameters specifying both traditional and post-quantum key exchange algorithms. The output will show which algorithms are actually used in the negotiated connection, confirming that hybrid operation works correctly.

Preparing Now for Post-Quantum

1. Inventory Current Keys

Systematically find all RSA and ECDSA keys across your infrastructure. Track expiration dates for existing certificates so you can plan post-quantum replacement before keys expire. Create a comprehensive inventory of cryptographic material so you understand the scope of migration work required.

2. Test Post-Quantum Support

Install post-quantum support libraries like liboqs and libssl-dev on your systems. Configure your build system with post-quantum support enabled so compilation includes the necessary algorithms. Test that your applications can successfully generate, load, and use post-quantum key material.

3. Start Hybrid Implementation

Begin with pilot projects using hybrid certificates before rolling out company-wide. This approach allows you to identify and resolve issues in non-critical systems before affecting production infrastructure. Use pilot results to refine your migration procedures and timelines.

4. Monitor NIST Updates

Track the three finalized NIST post-quantum standards: FIPS 203 for ML-KEM (key encapsulation mechanism), FIPS 204 for ML-DSA (digital signature algorithm), and FIPS 205 for SLH-DSA (hash-based signature algorithm). Check for updates to these standards annually, as NIST may issue guidance, clarifications, or refinements to the standards.

Threat Model

Current (Pre-Quantum)

In the pre-quantum era, an adversary with knowledge of RSA cannot practically factor 2048-bit RSA keys—it would take approximately 300 trillion years. Therefore, TLS is not broken in practice and is currently considered secure.

With Quantum Computer (2030+)

With a functional quantum computer, an adversary can factor 2048-bit RSA in approximately 8 hours using Shor's algorithm. This enables retroactive decryption of all past TLS sessions that were recorded (the "harvest now, decrypt later" attack). Elliptic curve cryptography (ECC) would be similarly broken.

With Post-Quantum (ML-KEM/ML-DSA)

With post-quantum algorithms like ML-KEM (Kyber) and ML-DSA (Dilithium), even a quantum adversary cannot solve lattice problems efficiently. Kyber keys cannot be broken in any practical time frame, Dilithium signatures remain secure, and past sessions cannot be retroactively decrypted.

See Also

FIPS Overview: fips-140-overview.md — Current standards. Regulatory: ../regulatory/fedramp-high.md — Government requirements. Cryptographic Controls: fips-language-implementations.md — Implementation details.

Resources

NIST PQC: https://csrc.nist.gov/projects/post-quantum-cryptography/, liboqs Project: https://openquantumcomputing.org/, and OpenSSL 3.2+ Docs: https://www.openssl.org/docs/.