Skip to content

Algorithm Selection Guide

Choosing the right cryptographic algorithm depends on your security requirements, performance needs, and regulatory compliance. This guide helps you select the optimal algorithm for your use case.

Quick Selection

I need quantum-resistant encryption

Recommended: ML-KEM-768

Why: - ✅ NIST-standardized (FIPS 203) - ✅ NSA CNSA 2.0 approved - ✅ Balanced security (Level III = AES-192 equivalent) - ✅ Good performance (82 MB/s throughput) - ✅ Widely supported (Java, Python, C++)

Alternative: ML-KEM-1024 (for maximum security, Level V = AES-256 equivalent)

See ML-KEM details →

I need quantum-resistant digital signatures

Recommended: ML-DSA-65

Why: - ✅ NIST-standardized (FIPS 204) - ✅ NSA CNSA 2.0 approved - ✅ Balanced security (Level III) - ✅ Reasonable signature size (~3 KB) - ✅ Good performance (59 MB/s throughput)

Alternatives: - FALCON-512: If signature size is critical (40% smaller, ideal for smartcards) - SLH-DSA-SHA2-192F: If stateless signatures required (no key state)

See signature algorithms →

I need high-performance symmetric encryption

Recommended: ChaCha20-Poly1305

Why: - ✅ Fastest symmetric AEAD (87 MB/s throughput) - ✅ IETF standard (RFC 7539, TLS 1.3) - ✅ Constant-time implementation (side-channel resistant) - ✅ Excellent for mobile and high-throughput APIs

Alternative: AES-256-GCM (if hardware acceleration available, 74 MB/s)

See symmetric algorithms →

I'm migrating from RSA

Encryption: Migrate to ML-KEM-768 (quantum-resistant replacement) Signatures: Migrate to ML-DSA-65 (quantum-resistant replacement)

See migration guide →

Decision Tree

Step 1: What operation do you need?

flowchart TD Start{What do you need?} --> Encryption[Encryption] Start --> Signatures[Digital Signatures] Start --> MAC[Message Authentication] Encryption --> QuantumResistant1{Need quantum resistance?} QuantumResistant1 -->|Yes| MLKEM[ML-KEM-768 ⭐] QuantumResistant1 -->|No| SymmetricEnc{Symmetric or Asymmetric?} SymmetricEnc -->|Symmetric| AES[AES-256-GCM or ChaCha20] SymmetricEnc -->|Asymmetric| RSA[RSA-2048 ⚠️ Transition to PQC] Signatures --> QuantumResistant2{Need quantum resistance?} QuantumResistant2 -->|Yes| MLDSA[ML-DSA-65 ⭐] QuantumResistant2 -->|No| ECDSA[ECDSA P-384 ⚠️ Transition to PQC] MAC --> HMAC[HMAC-SHA256 ⭐]

Selection Criteria

By Security Level

When to use each NIST security level:

Security Level Equivalent Use Case Algorithms
Level I AES-128 Standard security, IoT devices, temporary data ML-KEM-512, ML-DSA-44
Level III ⭐ AES-192 Recommended for most use cases ML-KEM-768, ML-DSA-65
Level V AES-256 Long-term protection (>20 years), government, defense ML-KEM-1024, ML-DSA-87

Recommendation: Level III provides excellent security with optimal performance for most enterprise applications.

By Performance Requirements

High Throughput (>100 MB/s): - Symmetric: ChaCha20-Poly1305 (87 MB/s), AES-256-GCM (74 MB/s) - Asymmetric: SABER-256 (477 MB/s, experimental, not standardized)

Balanced (50-100 MB/s): - Post-Quantum Encryption: ML-KEM-768 (82 MB/s) ⭐ - Post-Quantum Signatures: ML-DSA-65 (59 MB/s) ⭐

Security-Focused (<50 MB/s): - Ultra-Conservative: Classic McEliece (28-51 MB/s, 40+ years research) - Stateless Signatures: SLH-DSA (18-29 MB/s)

See complete performance benchmarks →

By Regulatory Compliance

USA Federal Government: - Encryption: ML-KEM-768 or ML-KEM-1024 (NIST FIPS 203) - Signatures: ML-DSA-65 or ML-DSA-87 (NIST FIPS 204) - Policy Template: NIST_APPROVED

USA Defense (DoD/IC/NSS): - Encryption: ML-KEM-768 (required by 2030) - Signatures: ML-DSA-65 or SLH-DSA-192F (required by 2030) - Transitional: ECDSA P-384 (until 2030) - Policy Template: US_NSA_CNSA

European Union: - Encryption: ML-KEM-768, FrodoKEM (BSI recommends algorithm diversity) - Signatures: ML-DSA-65, FALCON-512 - Policy Template: EU_COMPLIANT or BSI_COMPLIANT (Germany)

China: - Symmetric: SM4-GCM-128 (mandatory for government) - Signatures: SM2 (mandatory for government) - Policy Template: CHINA_GMT_COMPLIANT

Japan: - Symmetric: Camellia-GCM-256 (CRYPTREC recommended) - Post-Quantum: ML-KEM, ML-DSA (CRYPTREC approved) - Policy Template: JAPAN_CRYPTREC

South Korea: - Symmetric: ARIA-GCM-256 or SEED-GCM-128 (KCMVP recommended) - Post-Quantum: ML-KEM, ML-DSA - Policy Template: KOREA_KCMVP

See standards alignment →

By Signature Size

Compact Signatures (constrained devices, smartcards): - FALCON-512: ~700 bytes (40% smaller than ML-DSA) - Use Cases: eID cards, SIM cards, firmware updates

Standard Signatures: - ML-DSA-65: ~3 KB (NIST-standardized, recommended) ⭐

Large Signatures (security priority): - SLH-DSA: ~17-49 KB (stateless, highest security)

By Data Lifetime

Short-Lived Data (<5 years): - Classical encryption acceptable (AES-256, RSA-2048) - Quantum threat timeline: Minimal risk - Recommendation: AES-256-GCM (high performance)

Medium-Lived Data (5-15 years): - Quantum resistance recommended - Store-now-decrypt-later attack risk - Recommendation: ML-KEM-768 (balanced) ⭐

Long-Lived Data (>15 years): - Quantum resistance mandatory - High probability of quantum computers within data lifetime - Recommendation: ML-KEM-1024 (maximum security)

Use Case Examples

Healthcare: Patient Records (HIPAA)

Requirements: - Long-term retention (7-30 years) - HIPAA compliance - PHI protection

Recommended: - Encryption: ML-KEM-1024 (Level V, long-term protection) - Signatures: ML-DSA-87 (Level V, audit trail integrity) - Policy: NIST_APPROVED or HIPAA_COMPLIANT

Rationale: Patient records stored for decades require maximum quantum resistance.

Healthcare use case →

Finance: Payment Transactions (PCI-DSS)

Requirements: - PCI-DSS compliance - High throughput (thousands of transactions/second) - Cardholder data protection

Recommended: - Encryption: AES-256-GCM (high performance, PCI-DSS approved) - Signatures: ML-DSA-65 (non-repudiation, quantum-resistant) - Policy: PCI_DSS or FINANCE_COMPLIANT

Rationale: Transaction data short-lived (<3 years), symmetric encryption sufficient for performance.

Finance use case →

Government: Classified Documents (FedRAMP)

Requirements: - FedRAMP compliance - Long-term classification (50+ years) - National security data

Recommended: - Encryption: ML-KEM-1024 (Level V, NSA CNSA 2.0) - Signatures: SLH-DSA-256F (stateless, long-term verification) - Policy: US_NSA_CNSA

Rationale: Classified documents require highest security level and quantum resistance.

Government use case →

IoT: Sensor Data

Requirements: - Constrained devices (limited CPU, memory) - Low latency - Moderate security

Recommended: - Encryption: ML-KEM-512 (Level I, efficient for IoT) - Signatures: FALCON-512 (compact signatures) - Symmetric: AES-128-GCM (lightweight)

Rationale: IoT devices have limited resources, Level I security sufficient for sensor data.

API: High-Throughput Services

Requirements: - High throughput (10,000+ requests/second) - Low latency (<100ms) - Moderate data lifetime (<5 years)

Recommended: - Symmetric: ChaCha20-Poly1305 (87 MB/s, fastest) - Asymmetric: ML-KEM-768 (82 MB/s, quantum-resistant) - Signatures: ML-DSA-65 (59 MB/s)

Rationale: Optimize for performance while maintaining quantum resistance.

Decision Matrix

Encryption Algorithm Selection

Requirement Top Choice Alternative 1 Alternative 2
Quantum resistance + Performance ML-KEM-768 ⭐ ML-KEM-512 HQC-256
Maximum security ML-KEM-1024 Classic McEliece FrodoKEM-1344
High throughput ChaCha20-Poly1305 AES-256-GCM SABER-256
Germany (BSI) FrodoKEM-976 ML-KEM-768 -
China (GM/T) SM4-GCM-128 AES-256-GCM -
Japan (CRYPTREC) Camellia-GCM-256 ML-KEM-768 -
South Korea (KCMVP) ARIA-GCM-256 SEED-GCM-128 ML-KEM-768

Signature Algorithm Selection

Requirement Top Choice Alternative 1 Alternative 2
Quantum resistance + Performance ML-DSA-65 ⭐ ML-DSA-44 FALCON-512
Maximum security ML-DSA-87 SLH-DSA-256F -
Compact signatures FALCON-512 ML-DSA-44 -
Stateless SLH-DSA-192F SLH-DSA-128F -
China (GM/T) SM2 ML-DSA-65 -
Transitional ECDSA P-384 RSA-PSS-384 -

Migration Path Recommendations

From RSA Encryption → PQC

Target: ML-KEM-768

Migration Steps: 1. Generate ML-KEM-768 keys 2. Re-encrypt data (RSA → ML-KEM) using /api/crypto/reencrypt 3. Update applications to use ML-KEM keys 4. Decommission RSA keys (after grace period)

Detailed migration guide →

From RSA Signatures → PQC

Target: ML-DSA-65

Migration Steps: 1. Generate ML-DSA-65 keys 2. Re-sign documents (RSA → ML-DSA) using /api/crypto/resign 3. Update verification logic (support both RSA and ML-DSA during transition) 4. Decommission RSA signing keys

Detailed migration guide →

From ECDSA Signatures → PQC

Target: ML-DSA-65

Migration Steps: Same as RSA → ML-DSA (above)

Note: ECDSA P-384 is NSA CNSA 2.0 transitional (acceptable until 2030), so migration is less urgent than RSA.

Algorithm Trade-offs

Security vs Performance

Highest Security: - ML-KEM-1024: 86 MB/s (slower) - ML-DSA-87: 56 MB/s (slower)

Balanced: - ML-KEM-768: 82 MB/s ⭐ - ML-DSA-65: 59 MB/s ⭐

Highest Performance: - ChaCha20-Poly1305: 87 MB/s (not quantum-resistant) - SABER-256: 477 MB/s (experimental, not standardized)

Recommendation: Use balanced algorithms (Level III) for most applications.

Signature Size vs Performance

Smallest Signatures: - FALCON-512: ~700 bytes - ECDSA P-256: ~64 bytes (not quantum-resistant)

Balanced: - ML-DSA-65: ~3 KB ⭐

Largest Signatures: - SLH-DSA-256S: ~49 KB (stateless, highest security)

Trade-off: Compact signatures (FALCON) slightly slower than ML-DSA, but 40% smaller.

Standardization vs Performance

NIST-Standardized (recommended): - ML-KEM-768, ML-DSA-65 ⭐ - Regulatory compliance guaranteed - Wide industry adoption

NIST Round 3/4 (not standardized): - SABER, BIKE, HQC - Better performance (some variants) - Less regulatory acceptance

Recommendation: Use NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA) for production.

Common Scenarios

Scenario 1: Startup SaaS Application

Profile: - Short data lifetime (<3 years) - High growth (variable workload) - Need rapid deployment

Recommended: - Encryption: AES-256-GCM (high performance, proven) - Transitional: Consider ML-KEM-768 for future-proofing - Signatures: ML-DSA-65 (if non-repudiation needed)

Scenario 2: Enterprise Healthcare System

Profile: - Long data retention (30+ years) - HIPAA compliance required - Moderate performance needs

Recommended: - Encryption: ML-KEM-1024 (maximum security for PHI) - Signatures: ML-DSA-87 (audit trail integrity) - Policy: NIST_APPROVED or HIPAA_COMPLIANT

Scenario 3: Financial Payment Processing

Profile: - High throughput (10,000+ TPS) - PCI-DSS compliance - Short data retention (<3 years)

Recommended: - Encryption: AES-256-GCM (optimal performance) - Signatures: ML-DSA-65 (quantum-resistant, non-repudiation) - Policy: PCI_DSS

Scenario 4: Government Classified Systems

Profile: - Long data retention (50+ years) - FedRAMP/CNSA 2.0 compliance - Highest security requirements

Recommended: - Encryption: ML-KEM-1024 (NSA CNSA 2.0) - Signatures: SLH-DSA-256F (stateless, long-term) - Policy: US_NSA_CNSA

Scenario 5: IoT Device Firmware

Profile: - Constrained devices (limited CPU/memory) - Signature size critical (network bandwidth) - Long-term verification (firmware signing)

Recommended: - Signatures: FALCON-512 (compact, ~700 bytes) - Stateless: SLH-DSA-128F (if state management not feasible)

Anti-Patterns (What NOT to Do)

❌ Anti-Pattern 1: Using Experimental Algorithms in Production

Don't: Use SABER, BIKE, or other non-standardized algorithms for production

Why: Not NIST-standardized, limited regulatory acceptance, compatibility issues

Do Instead: Use ML-KEM-768 (NIST FIPS 203, proven)

❌ Anti-Pattern 2: Choosing Algorithm by Performance Alone

Don't: Use fastest algorithm without considering security requirements

Why: May not meet compliance (HIPAA, FedRAMP), insufficient for data lifetime

Do Instead: Balance security and performance (ML-KEM-768 optimal for most cases)

❌ Anti-Pattern 3: Neglecting Migration Path

Don't: Deploy classical algorithms (RSA, ECDSA) for new systems

Why: Will require migration later (costly, risky)

Do Instead: Start with PQC algorithms (ML-KEM, ML-DSA) for new deployments

❌ Anti-Pattern 4: One-Size-Fits-All

Don't: Use same algorithm for all data (regardless of sensitivity, lifetime)

Why: Over-secures low-risk data (wastes performance), under-secures high-risk data

Do Instead: Risk-based algorithm selection (high-risk → Level V, low-risk → Level I)

Summary Recommendations

Default Choices (If Unsure)

Encryption: ML-KEM-768 (quantum-resistant, balanced, NIST-standardized)

Signatures: ML-DSA-65 (quantum-resistant, balanced, NIST-standardized)

Symmetric: AES-256-GCM (proven, high performance)

MAC: HMAC-SHA256 (fast, widely supported)

Regional Defaults

  • USA: ML-KEM-768 + ML-DSA-65 (NIST_APPROVED)
  • EU: ML-KEM-768 + ML-DSA-65 (EU_COMPLIANT)
  • Germany: FrodoKEM-976 + ML-DSA-65 (BSI_COMPLIANT)
  • China: SM4-GCM-128 + SM2 (CHINA_GMT_COMPLIANT)
  • Japan: Camellia-GCM-256 + ML-DSA-65 (JAPAN_CRYPTREC)
  • South Korea: ARIA-GCM-256 + ML-DSA-65 (KOREA_KCMVP)

Documentation Version: 3.0.0 Last Updated: 2025-12-26