Composite Hybrid Keys: Defense-in-Depth Cryptography

The ONLY platform combining classical + PQC algorithms in a single key - 1000× more secure than OR-decrypt

🚀 Try it now: Generate your first composite key in 2 minutes

Quick Start: Create Your First Composite Key

Estimated time: 2 minutes What you'll achieve: Encrypt data with RSA + ML-KEM simultaneously (defense-in-depth) Requirements: AnkaSecure API access

Step 1/3: Generate composite key (30 seconds)

curl -X POST https://api.ankatech.co/keys/composite \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "classicalAlgorithm": "RSA_4096",
    "pqcAlgorithm": "ML_KEM_1024",
    "mode": "HYBRID_KEM_COMBINE",
    "keyPurpose": "DATA_ENCRYPTION"
  }'

✅ Success: You'll receive a single keyId for the composite key:

{
  "keyId": "hybrid-001",
  "classicalComponent": "RSA_4096",
  "pqcComponent": "ML_KEM_1024",
  "mode": "HYBRID_KEM_COMBINE",
  "securityLevel": "NIST_L5",
  "complianceStatus": {
    "NIST_SP_800_227": true,
    "GSA_PQC": true,
    "CNSA_2_0": true
  }
}

Security guarantee: Data encrypted with this key requires BOTH RSA AND ML-KEM to decrypt (1000× more secure than OR-decrypt)

Step 2/3: Encrypt data (1 minute)

# Same API as regular keys - composite operation is transparent!
curl -X POST https://api.ankatech.co/encrypt \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "keyId": "hybrid-001",
    "plaintext": "Top secret data"
  }'

✅ Behind the scenes (automatic): 1. Generates random AES-256 key (CEK) 2. Encapsulates CEK with RSA-4096 → secret₁ 3. Encapsulates CEK with ML-KEM-1024 → secret₂ 4. Combines secrets with NIST-approved KDF → derived CEK 5. Encrypts data with AES-256-GCM

You just wrote: curl -X POST (one line) AnkaSecure did: Dual-algorithm encryption (5 cryptographic operations)

Step 3/3: Decrypt data (30 seconds)

curl -X POST https://api.ankatech.co/decrypt \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "keyId": "hybrid-001",
    "ciphertext": "eyJhbGciOi..."
  }'

✅ Security verification: Both RSA and ML-KEM components validated before decryption

❌ Attack scenario: If quantum computer breaks RSA, data STILL secure (ML-KEM protects it)

🎯 What's next? - Use dual signatures: Create ML-DSA + ECDSA composite signing key - Deploy in production: Enterprise rollout guide - Understand the math: How AND-decrypt works

Why Composite Keys? The Quantum Threat

"Harvest Now, Decrypt Later" Attack

The problem: 1. Adversary captures your encrypted data TODAY (e.g., encrypted database backups) 2. Stores it for 10-15 years 3. When quantum computers arrive (estimated 2030-2035), decrypts all RSA/ECDSA-encrypted data 4. Your "secure" data from 2026 is now compromised in 2035

Traditional encryption (RSA-only):

Encrypted with RSA-4096 today ❌ Broken by quantum computer in 2035

Composite key encryption (RSA + ML-KEM):

Encrypted with RSA + ML-KEM today ✅ STILL SECURE in 2035
                                   (quantum breaks RSA but not ML-KEM)

Protection timeline: If your data must stay confidential for 10+ years, use composite keys NOW

Defense-in-Depth: Hedge Against the Unknown

What if... - ❓ Quantum computers break RSA? → ML-KEM protects data ✅ - ❓ Vulnerability found in ML-KEM? → RSA protects data ✅ - ❓ BOTH broken simultaneously? → Astronomically unlikely (requires breaking 2 independent hard problems)

Traditional single-algorithm encryption:

One algorithm broken = Data compromised ❌

Composite key encryption:

BOTH algorithms must be broken = 1000× more secure ✅

Analogy: Like requiring two keys to open a safe (not key A OR key B, but key A AND key B)

Federal Compliance Ready

Composite keys satisfy these regulatory requirements:

Compliance benefit: Check all federal procurement boxes with one key type

📥 Download federal compliance guide (maps composite keys to NIST/GSA requirements)

How Composite Keys Work

HYBRID_KEM_COMBINE: AND-Decrypt Encryption

High-level flow:

Plaintext
   ↓
1. Generate random AES-256 key (CEK)
   ↓
2. Encapsulate CEK with RSA → secret₁
   ↓
3. Encapsulate CEK with ML-KEM → secret₂
   ↓
4. Combine secrets with KDF → derived CEK
   ↓
5. Encrypt plaintext with AES-256-GCM
   ↓
Ciphertext (JWE format)

Security property: Adversary needs BOTH secrets to decrypt

NIST compliance: Uses HKDF-SHA256 per NIST SP 800-56C Rev. 2 (not ad-hoc XOR)

DUALSIGN: Dual-Signature Verification

High-level flow:

Document
   ↓
1. Hash document (SHA-256/384/512)
   ↓
2. Sign hash with ECDSA → signature₁
   ↓
3. Sign hash with ML-DSA → signature₂
   ↓
4. Embed both in JWS (General JSON format)
   ↓
Signed document (JWS format)

Verification policies: - ALL (recommended): Both signatures must verify - maximum security - ANY: At least one signature must verify - migration flexibility - CLASSICAL_REQUIRED: ECDSA required, ML-DSA optional - backward compatibility - PQC_REQUIRED: ML-DSA required, ECDSA optional - forward compatibility

Example: Generate signing composite key:

curl -X POST https://api.ankatech.co/keys/composite \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "classicalAlgorithm": "Ed25519",
    "pqcAlgorithm": "ML_DSA_87",
    "mode": "DUALSIGN",
    "verificationPolicy": "ALL",
    "keyPurpose": "DIGITAL_SIGNATURE"
  }'

Supported Algorithm Combinations

Encryption (HYBRID_KEM_COMBINE)

Validation rule: Both components must match security levels (e.g., L3 + L3, L5 + L5)

❌ Invalid combination: RSA-2048 (L1) + ML-KEM-1024 (L5) - mismatched security levels

Digital Signatures (DUALSIGN)

Real-World Use Cases

Use Case 1: Financial Services (Long-Lived Data)

Challenge: Transaction records must be retained for 10 years, but quantum computers may break RSA by 2035

Solution: Composite keys (RSA + ML-KEM) for all transaction encryption

Benefits: - ✅ Quantum-resistant: ML-KEM protects data beyond 2035 - ✅ Hedge risk: If ML-KEM vulnerable, RSA still protects - ✅ Compliance: PCI DSS + quantum readiness

Example: Encrypt credit card transactions

curl -X POST https://api.ankatech.co/keys/composite \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "classicalAlgorithm": "RSA_4096",
    "pqcAlgorithm": "ML_KEM_1024",
    "mode": "HYBRID_KEM_COMBINE",
    "metadata": {
      "purpose": "credit_card_transactions",
      "retention": "10_years"
    }
  }'

Use Case 2: Government (Classified Documents)

Challenge: NSA CNSA 2.0 requires quantum-resistant algorithms by 2030, but existing RSA keys still in use

Solution: Dual-signature composite keys for document signing

Benefits: - ✅ CNSA 2.0 compliant: ML-DSA satisfies quantum requirement - ✅ Backward compatible: ECDSA for legacy systems - ✅ Audit trail: Both signatures verifiable independently

Example: Sign classified document

curl -X POST https://api.ankatech.co/sign \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "keyId": "gov-composite-001",  # ECDSA + ML-DSA
    "document": "TOP SECRET//CNSA2",
    "verificationPolicy": "ALL"  # Both must verify
  }'

Use Case 3: Healthcare (Patient Records)

Challenge: HIPAA requires encryption for patient data with 30+ year retention, quantum threat looming

Solution: Composite keys for EHR (Electronic Health Records) encryption

Benefits: - ✅ HIPAA compliant: Strong encryption required - ✅ Future-proof: Quantum-resistant for 30+ years - ✅ Key rotation: Upgrade classical component without re-encryption

Example: Encrypt patient record

curl -X POST https://api.ankatech.co/encrypt \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "keyId": "ehr-composite-001",
    "plaintext": "{\"patientId\":\"12345\", ...}",
    "metadata": {
      "recordType": "medical_record",
      "retention": "30_years"
    }
  }'

Use Case 4: IoT/Industrial (Long-Lived Devices)

Challenge: Industrial IoT devices deployed for 10-20 years can't be easily updated, must use quantum-resistant crypto from day 1

Solution: Composite keys for device-to-cloud communication

Benefits: - ✅ Quantum-proof: Devices secure for entire 20-year lifecycle - ✅ No firmware update needed: Crypto handled by AnkaSecure cloud API - ✅ Defense-in-depth: If one algorithm broken, other protects

Example: IoT device enrollment

# Device generates composite key once during manufacturing
curl -X POST https://api.ankatech.co/keys/composite \
  -H "Authorization: Bearer $DEVICE_TOKEN" \
  -d '{
    "classicalAlgorithm": "X25519",  # Low compute overhead
    "pqcAlgorithm": "ML_KEM_768",
    "mode": "HYBRID_KEM_COMBINE",
    "metadata": {
      "deviceType": "industrial_sensor",
      "lifespan": "20_years"
    }
  }'

Migration to Composite Keys

Strategy: Add PQC Layer to Existing RSA Keys

Problem: You have 500 RSA keys in production, need quantum resistance without replacing keys

Solution: Convert RSA keys to RSA+ML-KEM composite keys

Step 1: Identify existing RSA keys

curl https://api.ankatech.co/keys?algorithm=RSA_4096 \
  -H "Authorization: Bearer $TOKEN"

Step 2: Upgrade to composite (keeps same keyId!)

curl -X PATCH https://api.ankatech.co/keys/rsa-key-001/upgrade \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "upgradeType": "ADD_PQC_COMPONENT",
    "pqcAlgorithm": "ML_KEM_1024",
    "mode": "HYBRID_KEM_COMBINE"
  }'

✅ Result: rsa-key-001 now uses RSA + ML-KEM (apps continue working, no code changes!)

Decryption behavior: - Old ciphertext (RSA-only): Decrypts with RSA component ✅ - New ciphertext (RSA+ML-KEM): Requires both components ✅

Zero downtime: Gradual transition with backward compatibility

Performance Characteristics

Encryption Overhead

Performance summary: - Key generation: +0.2% overhead (one-time operation) - Encryption: +75% overhead (but still < 5ms for 1KB) - Decryption: +17% overhead (acceptable for most applications) - Throughput: ~200 encrypt ops/sec (composite) vs 350 ops/sec (RSA alone)

Trade-off: 17-75% performance overhead for 1000× security improvement

Recommendation: Use composite keys for high-value data (not every API call)

Benchmark: Real-World Scenario

Test: Encrypt 10,000 files (1MB each) with RSA-4096 vs RSA+ML-KEM

Verdict: Performance overhead acceptable for quantum resistance

Cost-Benefit Analysis

Traditional "Defense-in-Depth" Approach

Encrypt data twice with separate keys:

# Step 1: Encrypt with RSA
rsa_ciphertext = encrypt_rsa(plaintext, rsa_key)

# Step 2: Encrypt RSA ciphertext with ML-KEM (double encryption)
final_ciphertext = encrypt_mlkem(rsa_ciphertext, mlkem_key)

Problems: - ❌ 2× API calls (latency penalty) - ❌ 2× storage (ciphertext bloat) - ❌ 2× key management (complexity) - ❌ Application code changes required

Cost: 2× everything

AnkaSecure Composite Keys Approach

Single API call, unified key management:

# One call, dual encryption automatically
curl -X POST https://api.ankatech.co/encrypt \
  -d '{"keyId":"composite-001", "plaintext":"..."}'

Benefits: - ✅ 1× API call (normal latency) - ✅ 1× storage (JWE efficiently embeds both secrets) - ✅ 1× key management (single keyId) - ✅ Zero application code changes

Cost: Same as single encryption (but 1000× more secure)

Enterprise Deployment

Rollout Strategy

Phase 1: Pilot (1 week) - Deploy composite keys for 1-2 non-critical applications - Monitor performance impact - Validate encryption/decryption workflows

Phase 2: High-Value Data (2 weeks) - Migrate sensitive data (financial records, PHI, classified docs) - Use composite keys for all new encryption - Keep RSA for low-value data (logs, cache)

Phase 3: Gradual Expansion (1-2 months) - Convert 10% of RSA keys per week - Monitor error rates and performance - Fallback plan: Revert to RSA-only if issues

Phase 4: Full Adoption (Ongoing) - All new keys are composite by default - Archive pure RSA keys after data expiration - Maintain compliance documentation

Monitoring & Validation

Key metrics to track: - Composite key usage: % of encryption ops using composite keys (target: 80%+) - Performance impact: Latency p95 (target: < +20% vs baseline) - Error rates: Failed encryptions/decryptions (target: < 0.1%) - Compliance status: % of keys meeting NIST SP 800-227 (target: 100%)

Example: Query composite key usage:

curl https://api.ankatech.co/analytics/key-usage \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "period": "last_30_days",
    "filterByType": "COMPOSITE"
  }'

Output:

{
  "totalEncryptions": 1500000,
  "compositeKeyEncryptions": 1200000,
  "compositePercentage": 80.0,
  "avgLatency": "4.2ms",
  "latencyIncrease": "+15%"
}

Comparison: Composite Keys vs Alternatives

vs Single PQC Key (ML-KEM only)

Verdict: Composite keys recommended for high-security applications

vs Dual Encryption (RSA then ML-KEM)

Verdict: Composite keys are simpler and more efficient

vs Algorithm Agility (Rotate RSA → ML-KEM)

Verdict: Composite keys enable risk-free migration

Compliance & Standards

NIST SP 800-227: Hybrid Post-Quantum Cryptography

Requirement: Combine classical and PQC algorithms using approved KDF

AnkaSecure implementation: - ✅ Classical: RSA, ECDSA, X25519, Ed25519 - ✅ PQC: ML-KEM, ML-DSA, SLH-DSA - ✅ KDF: HKDF-SHA256 (NIST SP 800-56C Rev. 2) - ✅ Mode: AND-decrypt (both secrets required)

Validation: CAVP certificates for ML-KEM, ML-DSA, HKDF

📥 Download NIST compliance guide

GSA PQC Mandate: Federal Procurement Requirements

GSA requirement: Dual-algorithm cryptography for federal contracts

AnkaSecure composite keys satisfy: - ✅ Hybrid PQC/classical algorithms - ✅ FIPS 140-2 validated cryptographic module - ✅ AND-decrypt semantics (both algorithms required) - ✅ Approved for classified data (pending ATO)

Federal readiness: Ready for RFP responses and contract proposals

📥 Download GSA compliance brief

CNSA 2.0: NSA Commercial National Security Algorithm Suite

CNSA 2.0 timeline: - 2025-2030: Transition period (hybrid encouraged) - 2030: Quantum-resistant algorithms mandatory for classified data

AnkaSecure alignment: - ✅ ML-KEM, ML-DSA on CNSA 2.0 approved list - ✅ Hybrid mode supports gradual transition - ✅ RSA-4096 acceptable during transition (until 2030)

Benefit: Start transition now, meet 2030 deadline

Best Practices

DO: Use Composite Keys For

✅ Long-lived data (10+ year retention) - Financial records, contracts, healthcare data

✅ High-value targets - Trade secrets, classified documents, PII

✅ Federal/regulated environments - Government contracts, HIPAA, PCI DSS

✅ IoT/embedded devices (long deployment cycles) - Industrial sensors, medical devices, automotive

DON'T: Use Composite Keys For

❌ Low-value data - Application logs, cache data, temporary files

❌ High-throughput applications (> 10,000 ops/sec) - Real-time messaging, high-frequency trading (unless hardware-accelerated)

❌ Short-lived data (< 1 year retention) - Session tokens, temporary credentials

Recommendation: Use pure ML-KEM for high-throughput, composite keys for high-security

Key Rotation Cadence

Rotation strategy: Rotate classical component more frequently (RSA every 1 year), PQC less frequently (ML-KEM every 2-3 years)

Troubleshooting

Issue: "Mismatched security levels" error

Symptom:

{"error": "Classical component (RSA-2048, L1) and PQC component (ML-KEM-1024, L5) have mismatched security levels"}

Cause: Attempting to combine L1 classical with L5 PQC (imbalanced security)

Fix: Use matching security levels:

# Correct: RSA-4096 (L5) + ML-KEM-1024 (L5)
curl -X POST https://api.ankatech.co/keys/composite \
  -d '{
    "classicalAlgorithm": "RSA_4096",  # L5
    "pqcAlgorithm": "ML_KEM_1024"      # L5
  }'

Issue: Higher latency than expected

Symptom: Encryption taking 10ms instead of expected 5ms

Diagnosis: 1. Check if using composite keys (expected +17-75% overhead) 2. Verify network latency (not crypto latency) 3. Review payload size (larger payloads = more overhead)

Fix: If performance critical, use pure ML-KEM for bulk operations, composite keys for metadata

What's Next?

Ready to deploy composite keys? - 🚀 Try the 2-minute quick start (scroll to top) - 📊 ROI calculator: Composite vs traditional dual encryption - 📥 Download deployment playbook (PDF, 25 pages) - 📧 Schedule security review (discuss your threat model)

Explore related topics: - Migration strategy - Add PQC to existing RSA keys - Performance benchmarks - Detailed latency measurements - Algorithm comparison - Security level equivalence - NIST compliance - Federal procurement readiness

Have questions? Email [email protected] or join our community forum

Last updated: 2026-01-07 | Version: 3.0.0