Cryptographic Parameter Calculator
Use Case
Security Level
Quantum Readiness Required
Current Algorithms in Use
10 years
TLS Version in Use
Security Target256-bit
"Harvest Now, Decrypt Later" Risk Assessment
Harvest Now RiskHIGH
Must Migrate By2030
Your data needs protection until 2036, past quantum availability estimates. While AES-256 provides 128-bit post-quantum security, asymmetric key exchanges are still vulnerable. Begin hybrid PQC migration now.
Quantum Threat Timeline
Recommended Algorithms
symmetricAES-256-GCM
Key size: 256-bit
Standard: NIST SP 800-38D
Gold standard for data-at-rest encryption
asymmetricRSA-15360 or ECC P-521
Key size: 15360-bit / 521-bit
Standard: NIST SP 800-57
P-521 strongly preferred; RSA-15360 is impractical
hashSHA-512
Key size: 512-bit output
Standard: FIPS 180-4
Maximum classical hash security
pqcML-KEM-1024 (Kyber)
Key size: 1568-byte public key
Standard: NIST FIPS 203
Highest-security post-quantum KEM
Protocol Analysis
✓
TLS 1.2secure
TLS 1.2 is acceptable. Ensure only strong cipher suites are enabled. Plan TLS 1.3 migration.
⚠
RSA-2048weak
RSA-2048 provides only 112-bit security and is being phased out. Migrate to RSA-3072+ or ECC P-256.
✓
AES-256secure
AES-256 provides the strongest symmetric security. Preferred for long-term data protection.
✓
SHA-256secure
SHA-256 provides 128-bit collision resistance. Standard choice for most hashing needs.
Migration Roadmap (13 months)
Urgency: soon
| Phase | Action | Timeline | Effort↕ | Affected Systems |
|---|---|---|---|---|
| Phase 1: Inventory | Catalog all systems using current cryptographic algorithms. Map dependencies and data flows. | Month 1-2 | MEDIUM | All systems |
| Phase 2: Testing | Deploy target algorithms in test environments. Validate compatibility with existing infrastructure. | Month 2-4 | MEDIUM | Test/staging environments |
| Phase 3: Migrate RSA-2048 | Replace RSA-2048 with ECC P-256 or RSA-3072+. Implement hybrid mode where applicable. | Month 4-10 | MEDIUM | Systems using RSA-2048 |
| Phase 3: Migrate AES-256 | Replace AES-256 with AES-256-GCM (maintain). Implement hybrid mode where applicable. | Month 4-7 | LOW | Systems using AES-256 |
| Phase 3: Migrate SHA-256 | Replace SHA-256 with SHA-256 (maintain, add SHA-384 for 192-bit+). Implement hybrid mode where applicable. | Month 4-10 | MEDIUM | Systems using SHA-256 |
| Phase 4: Cutover | Remove legacy algorithm support. Enforce new algorithms in production. Update certificates. | Month 10-12 | HIGH | All production systems |
| Phase 5: Validation | Verify all systems use target algorithms. Conduct penetration testing. Update documentation. | Month 12-13 | MEDIUM | All systems |
Compliance Mapping
| Algorithm↕ | PCI DSS 4.0 | FIPS 140-3 | NIST SP 800-131A |
|---|---|---|---|
| RSA-2048 | Not recommended after 2030 | FIPS 186-5 approved | Disallowed after 2030 (SP 800-131A) |
| AES-256 | Compliant | FIPS 197 approved | Recommended (SP 800-57) |
| SHA-256 | Compliant | FIPS 180-4 approved | Recommended (SP 800-57) |
Algorithm Comparison (RSA vs ECC vs PQC)
| Algorithm | Classical | Quantum | Key Size | Perf |
|---|---|---|---|---|
| RSA-2048 | 112-bit | Broken (Shor) | 2048-bit | slow |
| RSA-3072 | 128-bit | Broken (Shor) | 3072-bit | slow |
| ECC P-256 | 128-bit | Broken (Shor) | 256-bit | fast |
| ECC P-384 | 192-bit | Broken (Shor) | 384-bit | fast |
| AES-128 | 128-bit | 64-bit (Grover) | 128-bit | fast |
| AES-256 | 256-bit | 128-bit (Grover) | 256-bit | fast |
| ML-KEM-512 (Kyber) | 128-bit | 128-bit | 800-byte PK | fast |
| ML-KEM-1024 (Kyber) | 256-bit | 256-bit | 1568-byte PK | moderate |
| ML-DSA-44 (Dilithium) | 128-bit | 128-bit | 1312-byte PK | fast |
| ML-DSA-87 (Dilithium) | 256-bit | 256-bit | 2592-byte PK | moderate |
Quantum Timeline
NIST recommends beginning PQC migration now. Cryptographically relevant quantum computers estimated by 2030-2035. Harvest-now-decrypt-later attacks are an immediate concern for long-lived secrets.
Migration Checklist
- ☐ Inventory all cryptographic assets and key management systems
- ☐ Identify data with long-term confidentiality requirements (> 10 years)
- ☐ Assess crypto agility — can algorithms be swapped without major refactoring?
- ☐ Deploy AES-256 for all symmetric encryption
- ☐ Implement hybrid classical+PQC key exchange for TLS connections
- ☐ Deploy ML-KEM (Kyber) for key encapsulation in new systems
- ☐ Plan ML-DSA (Dilithium) migration for code signing and certificates
- ☐ Test PQC library compatibility with existing infrastructure
- ☐ Establish timeline for full PQC-only transition (target: 2030)
Choosing the right cipher, key size, and standard for a given job is harder than it looks, and the arrival of post-quantum cryptography has added another dimension. This tool maps your use case (data at rest, data in transit, digital signatures, or key exchange) and target security level (128, 192, or 256 bits) to concrete NIST- and FIPS-aligned algorithm recommendations, including optional post-quantum options.
How it works
- Select your use case, target security strength (128/192/256-bit), and whether you want quantum-ready (post-quantum) recommendations included.
- The tool returns a symmetric cipher, an asymmetric algorithm, and a hash function matched to your selection — for example, AES-128-GCM, ECDHE P-256, and SHA-256 for 128-bit data in transit — each tagged with its governing standard.
- When quantum-ready is enabled, NIST-standardized post-quantum schemes are added: ML-KEM (Kyber, FIPS 203) for key encapsulation and ML-DSA (Dilithium, FIPS 204) for signatures, along with a migration checklist and harvest-now-decrypt-later guidance.
Worked example
A team needs to protect data in transit at a 128-bit security level and wants post-quantum readiness.
- Choose use case "data in transit", security level 128-bit, and enable quantum-ready.
- Read the symmetric and asymmetric recommendations: AES-128-GCM or ChaCha20-Poly1305 for the cipher and ECDHE with P-256 for key exchange, with SHA-256 for handshake integrity.
- Note the added post-quantum recommendation: a hybrid ML-KEM-512 + ECDHE key exchange following FIPS 203 and the IETF TLS hybrid design draft.
Recommended stack: AES-128-GCM / ChaCha20-Poly1305, ECDHE P-256, SHA-256, plus hybrid ML-KEM-512 + ECDHE for post-quantum protection.
Frequently asked questions
- What does the security level (128, 192, 256 bits) mean?
- It is the work factor an attacker faces against the best known classical attack. A 128-bit level means roughly 2^128 operations are needed to break it, which is infeasible today; 192 and 256 bits provide larger safety margins for highly sensitive or long-lived data.
- Why does the tool recommend ECC over RSA at higher security levels?
- RSA key sizes grow steeply with security strength — 192-bit security needs RSA-7680 and 256-bit needs RSA-15360, which become impractically slow. Elliptic-curve algorithms like P-384 and P-521 reach the same strength with far smaller, faster keys.
- What is a "harvest now, decrypt later" attack?
- An adversary records encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the key exchange. Data that must stay confidential past the early 2030s should move to hybrid or post-quantum key exchange now.
- Are ML-KEM and ML-DSA real standards?
- Yes. ML-KEM (derived from CRYSTALS-Kyber) was finalized by NIST as FIPS 203 and ML-DSA (derived from CRYSTALS-Dilithium) as FIPS 204 in 2024, making them the first standardized post-quantum key-encapsulation and signature schemes.