Convert Data to Post-Quantum Algorithms

Re-encrypt RSA data to ML-KEM in 5 minutes - zero plaintext exposure

Quick Start: Re-Encrypt Data

Estimated time: 5 minutes What you'll achieve: Convert RSA-encrypted file to quantum-resistant ML-KEM Requirements: AnkaSecure API access, RSA-encrypted file, imported RSA key

Step 1/3: Import RSA key (if not done) (2 minutes)

# Import your existing RSA key
curl -X POST https://api.ankatech.co/migration/private-keys \
  -H "Authorization: Bearer $TOKEN" \
  -F "[email protected]" \
  -F "password=yourPassword"

✅ Result: keyId: "legacy-rsa-001" (can decrypt old data)

See import guide for details

Step 2/3: Generate ML-KEM key (1 minute)

# Create quantum-resistant key
curl -X POST https://api.ankatech.co/keys \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"algorithm":"ML_KEM_1024"}'

✅ Result: keyId: "pqc-mlkem-001" (quantum-resistant!)

Step 3/3: Re-encrypt data (2 minutes)

# Convert RSA ciphertext to ML-KEM ciphertext
curl -X POST https://api.ankatech.co/crypto/reencrypt \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "sourceKeyId": "legacy-rsa-001",
    "targetKeyId": "pqc-mlkem-001",
    "ciphertext": "eyJhbGciOiJSU0EtT0FFUC0yNTYi..."  # Your RSA-encrypted data
  }'

✅ Success: Data now quantum-resistant!

{
  "newCiphertext": "eyJhbGciOiJNTC1LRU0tMTAyNCIsInR5cCI6IkpXRSJ9...",
  "sourceAlgorithm": "RSA_4096",
  "targetAlgorithm": "ML_KEM_1024",
  "plaintextExposed": false,  # ✅ Zero plaintext exposure!
  "conversionTime": "3ms"
}

Security guarantee: Plaintext NEVER exposed during conversion (server-side transformation)

🎯 What's next? - Bulk conversion: Re-encrypt 1000s of files - Large files: Streaming re-encryption for GB files - Re-sign data: Convert signatures to ML-DSA

Why Convert to PQC?

Zero Plaintext Exposure (Unique Advantage)

Traditional re-encryption (INSECURE):

Client decrypts with RSA → Plaintext exposed on client
        ↓
Client sends plaintext to server (network exposure!)
        ↓
Server encrypts with ML-KEM

Risks: - ❌ Plaintext visible on client (memory dumps, malware) - ❌ Plaintext on network (even with TLS, trust boundary expanded) - ❌ Plaintext logged by proxies, firewalls

AnkaSecure re-encryption (SECURE):

Client sends RSA ciphertext to AnkaSecure
        ↓
Server decrypts with RSA (plaintext in secure enclave)
        ↓
Server re-encrypts with ML-KEM (plaintext never leaves server)
        ↓
Client receives ML-KEM ciphertext

Security benefits: - ✅ Plaintext NEVER on client (no exposure risk) - ✅ Plaintext NEVER on network (not even in TLS) - ✅ Plaintext only in server memory (secured, zeroized immediately)

Competitive advantage: NO other platform offers ciphertext-to-ciphertext conversion

Cost Savings vs Traditional Migration

Traditional approach (decrypt → re-encrypt in application):

200 applications × 70 hours each = 14,000 hours
14,000 hours × $60/hour = $840,000

Timeline: 6-12 months
Risk: Extremely high (plaintext exposure in 200 apps)

AnkaSecure approach (server-side conversion):

1 API call per file × 10,000 files = 10,000 API calls
10,000 calls × 3ms = 30 seconds total

Cost: ~$30 (configuration + API usage)
Timeline: 1 day
Risk: Minimal (plaintext secured server-side)

Savings: $839,970 (99.99%)

Re-Encryption Operations

Convert Single File

Endpoint: POST /api/crypto/reencrypt

Request:

{
  "sourceKeyId": "legacy-rsa-001",
  "targetKeyId": "pqc-mlkem-001",
  "ciphertext": "eyJhbGc...original RSA ciphertext..."
}

Response:

{
  "newCiphertext": "eyJhbGc...new ML-KEM ciphertext...",
  "conversionTime": "3ms",
  "sourceAlgorithm": "RSA_4096",
  "targetAlgorithm": "ML_KEM_1024",
  "plaintextSize": "1024 bytes",
  "plaintextExposed": false
}

Use case: Re-encrypt database records, API responses, configuration files

Limit: ≤ 5 MB per file (for larger files, use streaming)

Bulk Re-Encryption

Scenario: Re-encrypt 10,000 files from RSA to ML-KEM

Batch API:

curl -X POST https://api.ankatech.co/crypto/batch/reencrypt \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "sourceKeyId": "legacy-rsa-001",
    "targetKeyId": "pqc-mlkem-001",
    "files": [
      "s3://mybucket/encrypted/*.dat",  # S3 wildcard
      "/mnt/archive/2020/**/*.enc"      # Local filesystem
    ],
    "parallelism": 10  # Process 10 files concurrently
  }'

Response: Job ID

{
  "jobId": "reencrypt-job-12345",
  "estimatedFiles": 10000,
  "estimatedTime": "8 minutes",
  "throughput": "~1,250 files/minute"
}

Monitor progress:

curl https://api.ankatech.co/jobs/reencrypt-job-12345/status \
  -H "Authorization: Bearer $TOKEN"

Output:

{
  "progress": "7,500/10,000 files (75%)",
  "status": "IN_PROGRESS",
  "eta": "2 minutes",
  "errors": 0
}

Performance: ~1,250 files/minute (1KB each, RSA → ML-KEM)

Streaming Re-Encryption (Large Files)

For files > 5 MB (multi-GB databases, videos, backups):

Endpoint: POST /api/crypto/stream/reencrypt

Example: 50 GB database backup:

curl -X POST https://api.ankatech.co/crypto/stream/reencrypt \
  -H "Authorization: Bearer $TOKEN" \
  -F "sourceKeyId=legacy-rsa-001" \
  -F "targetKeyId=pqc-mlkem-001" \
  -F "[email protected]" \
  -o backup-50gb-mlkem.enc

Streaming output: Data written directly to backup-50gb-mlkem.enc (no memory accumulation)

Performance: - Throughput: ~80 MB/s - Memory usage: Constant 2 MB (regardless of file size!) - 50 GB file: ~10 minutes

Security: Plaintext exists in small chunks (64 KB) only, never full file

Re-Signing Operations

Convert RSA Signature to ML-DSA

Scenario: Documents signed with RSA, need quantum-resistant ML-DSA signatures

Process: 1. Verify RSA signature (validate authenticity) 2. Re-sign document with ML-DSA (quantum-resistant) 3. Return dual-signed document (backward compatible)

Example:

curl -X POST https://api.ankatech.co/crypto/resign \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "sourceKeyId": "legacy-rsa-signing-key",
    "targetKeyId": "pqc-mldsa-key",
    "signedDocument": "eyJhbGc...RSA-signed JWS..."
  }'

Response:

{
  "newSignedDocument": "eyJhbGc...ML-DSA-signed JWS...",
  "sourceSignature": "VERIFIED",  # RSA signature valid
  "targetSignature": "CREATED",   # ML-DSA signature added
  "documentIntegrity": "PRESERVED"
}

Integrity guarantee: Document content unchanged, only signature algorithm updated

Dual Signatures (Backward Compatible)

Create document with BOTH RSA and ML-DSA signatures:

curl -X POST https://api.ankatech.co/crypto/dual-sign \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "classicalKeyId": "rsa-signing-key",
    "pqcKeyId": "mldsa-signing-key",
    "document": "Important contract requiring dual signatures"
  }'

Output: JWS with 2 signatures

{
  "payload": "SW1wb3J0YW50IGNvbnRyYWN0...",
  "signatures": [
    {
      "protected": "eyJhbGciOiJSUzI1NiJ9",
      "signature": "RSA signature..."
    },
    {
      "protected": "eyJhbGciOiJNTC1EU0EtNjUifQ",
      "signature": "ML-DSA signature..."
    }
  ]
}

Verification policies: - ALL: Both signatures must verify (maximum security) - ANY: At least one signature must verify (migration flexibility)

Use case: Legal documents requiring both classical (current systems) and PQC (future-proof)

Conversion Strategies

Strategy 1: In-Place Conversion (Recommended)

Replace encrypted files with PQC-encrypted equivalents:

# Re-encrypt and overwrite original file
curl -X POST https://api.ankatech.co/crypto/reencrypt \
  -d '{
    "sourceKeyId": "rsa-001",
    "targetKeyId": "mlkem-001",
    "inputFile": "data.enc",
    "outputFile": "data.enc",  # Same filename (overwrite)
    "backupOriginal": true     # Create .bak file
  }'

Result: - data.enc → ML-KEM ciphertext (updated) - data.enc.bak → RSA ciphertext (backup, auto-deleted after 30 days)

Benefits: - ✅ Applications continue working (same filename) - ✅ Rollback available (from backup) - ✅ Storage efficient (backup auto-cleaned)

Strategy 2: Parallel Conversion (Safe, Slower)

Keep both versions during migration:

# Create new ML-KEM file alongside RSA file
curl -X POST https://api.ankatech.co/crypto/reencrypt \
  -d '{
    "sourceKeyId": "rsa-001",
    "targetKeyId": "mlkem-001",
    "inputFile": "data-rsa.enc",
    "outputFile": "data-mlkem.enc"  # Different filename
  }'

Result: - data-rsa.enc → Original (kept) - data-mlkem.enc → New ML-KEM version

Transition period: Update applications to read data-mlkem.enc, validate, then delete data-rsa.enc

Timeline: 2-4 weeks (gradual cutover, zero risk)

Strategy 3: Streaming for Large Files

For multi-GB files (databases, videos, logs):

# 50 GB backup conversion (constant 2MB memory!)
curl -X POST https://api.ankatech.co/crypto/stream/reencrypt \
  -F "sourceKeyId=rsa-001" \
  -F "targetKeyId=mlkem-001" \
  -F "[email protected]" \
  -o backup-50gb-pqc.enc

Performance: ~80 MB/s throughput = 50 GB in ~10 minutes

Memory usage: Constant 2 MB (works with ANY file size!)

Use case: Database backups, video archives, log files

Format Conversion (PKCS#7 to JOSE)

Modernize Legacy Formats

Problem: Legacy systems use PKCS#7/CMS (S/MIME format)

Modern standard: JOSE (JSON Web Encryption/Signature) - RFC 7515/7516

Benefits of JOSE: - ✅ JSON format (human-readable headers) - ✅ Web-friendly (Base64URL encoding) - ✅ Compact or JSON serialization (flexible) - ✅ Standardized (interoperable across platforms)

AnkaSecure conversion:

# Convert PKCS#7 to JWE (preserves RSA algorithm)
curl -X POST https://api.ankatech.co/migration/convert-pkcs7-to-jose \
  -H "Authorization: Bearer $TOKEN" \
  -F "[email protected]" \
  -F "format=JWE"

Output: JWE token (RFC 7516 format)

Then: Re-encrypt JWE from RSA to ML-KEM (Step 3 above)

Performance Characteristics

Re-Encryption Speed

Single file benchmarks (RSA-4096 → ML-KEM-1024):

File Size	Re-Encryption Time	Throughput
1 KB	3ms	333 files/sec
10 KB	4ms	250 files/sec
100 KB	6ms	167 files/sec
1 MB	15ms	67 files/sec
5 MB	60ms	17 files/sec

Bulk operations (parallel processing): - 10 concurrent workers: 3,330 files/sec (1KB each) - 100 concurrent workers: 16,700 files/sec

Example: 10,000 files in 8 minutes (1KB each, 10 workers)

Streaming Performance

Large file benchmarks (constant memory):

File Size	Re-Encryption Time	Throughput	Memory Used
100 MB	1.25 sec	80 MB/s	2 MB
1 GB	12.5 sec	80 MB/s	2 MB
10 GB	125 sec (~2 min)	80 MB/s	2 MB
50 GB	625 sec (~10 min)	80 MB/s	2 MB
100 GB	1,250 sec (~21 min)	80 MB/s	2 MB

Key feature: Memory usage CONSTANT (2 MB) regardless of file size

Use case: Database backups, video archives, log aggregation

Security During Conversion

Server-Side Transformation

Architecture:

Client (untrusted)      AnkaSecure Server (trusted boundary)
       │                          │
       │  1. RSA ciphertext       │
       ├─────────────────────────>│
       │                          │ 2. Decrypt with RSA key
       │                          │    (plaintext in memory)
       │                          │
       │                          │ 3. Re-encrypt with ML-KEM
       │                          │    (zeroize plaintext)
       │                          │
       │  4. ML-KEM ciphertext    │
       │<─────────────────────────┤
       │                          │

Security properties: - ✅ Plaintext NEVER leaves server - ✅ Plaintext zeroized after re-encryption (defense-in-depth) - ✅ Server secured with HSM (key protection) - ✅ Audit logged (complete operation trail)

For Ultra-Large Files (Streaming)

Constant memory architecture:

Decrypt Thread          Pipe (2 MB)         Encrypt Thread
      │                     │                      │
  Decrypt chunk 1 ────> Store chunk 1 ────> Encrypt chunk 1
      │                     │                      │
  Decrypt chunk 2 ────> Store chunk 2 ────> Encrypt chunk 2
      │                 (only 32 chunks       │
  Decrypt chunk 3      in memory at once)    Encrypt chunk 3
      │                     │                      │
     ...                   ...                    ...

Security: Only small chunks (64 KB) exist in memory, never full file

Memory: 2 MB total (32 chunks × 64 KB) regardless of file size (works for petabytes!)

Bulk Conversion Workflows

Re-Encrypt 10,000 Files

Step 1: Create conversion job

curl -X POST https://api.ankatech.co/migration/jobs/reencrypt \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "sourceKeyId": "rsa-001",
    "targetKeyId": "mlkem-001",
    "fileList": "s3://mybucket/encrypted/**/*.enc",
    "parallelism": 20,
    "batchSize": 100  # Process 100 files per batch
  }'

Response:

{
  "jobId": "reencrypt-job-67890",
  "estimatedFiles": 10000,
  "estimatedTime": "8 minutes",
  "costEstimate": "$0.30"  # $0.03 per 1000 operations
}

Step 2: Monitor job progress (real-time)

# Poll every 10 seconds
watch -n 10 "curl -s https://api.ankatech.co/jobs/reencrypt-job-67890 \
  -H 'Authorization: Bearer $TOKEN' | jq '.progress'"

Progress output:

"2,500/10,000 files (25%) - ETA: 6 minutes"
"5,000/10,000 files (50%) - ETA: 4 minutes"
"7,500/10,000 files (75%) - ETA: 2 minutes"
"10,000/10,000 files (100%) - COMPLETE"

Step 3: Verify completion

curl https://api.ankatech.co/jobs/reencrypt-job-67890/summary \
  -H "Authorization: Bearer $TOKEN"

Summary:

{
  "status": "COMPLETED",
  "filesProcessed": 10000,
  "filesSucceeded": 9998,
  "filesFailed": 2,
  "totalTime": "8 minutes 14 seconds",
  "avgTimePerFile": "49ms",
  "errors": [
    {"file": "corrupted-file.enc", "error": "Invalid ciphertext format"},
    {"file": "missing-file.enc", "error": "File not found"}
  ]
}

Success rate: 99.98% (9,998 out of 10,000 files)

Advanced Conversion Options

Preserve Metadata

Scenario: RSA-encrypted files have metadata (timestamps, user info)

Preserve metadata during conversion:

curl -X POST https://api.ankatech.co/crypto/reencrypt \
  -d '{
    "sourceKeyId": "rsa-001",
    "targetKeyId": "mlkem-001",
    "ciphertext": "...",
    "preserveMetadata": true,  # Copy JWE headers
    "addMetadata": {
      "convertedAt": "2026-01-07T12:00:00Z",
      "convertedBy": "[email protected]",
      "reason": "PQC migration"
    }
  }'

Result: ML-KEM ciphertext with original + new metadata

Use case: Audit trails, provenance tracking, compliance evidence

Verify Before Converting

Safety check: Ensure source key can decrypt before starting bulk conversion

# Test decryption with source key
curl -X POST https://api.ankatech.co/decrypt \
  -d '{
    "keyId": "legacy-rsa-001",
    "ciphertext": "sample-encrypted-file..."
  }'

✅ If decryption succeeds: Proceed with bulk conversion

❌ If decryption fails: Fix key import issue before bulk operation

Best practice: Test on 10 sample files before converting 10,000 files

Rollback Plan

If conversion fails or errors discovered:

Option 1: Revert from backups (if backupOriginal: true)

# Restore original RSA-encrypted files
curl -X POST https://api.ankatech.co/migration/rollback \
  -d '{
    "jobId": "reencrypt-job-67890",
    "action": "RESTORE_FROM_BACKUP"
  }'

Option 2: Keep both versions (if parallel conversion) - Delete ML-KEM files - Continue using RSA files

Option 3: Re-decrypt with source key (always possible)

# Decrypt ML-KEM ciphertext is broken
curl -X POST https://api.ankatech.co/decrypt \
  -d '{"keyId":"legacy-rsa-001","ciphertext":"original-backup..."}'

Recommendation: Always backup before bulk conversions

Cost Estimation

Conversion Cost Calculator

Estimate cost for your migration:

Files	Size per File	Total Data	Re-Encryption Time	API Cost*
1,000	1 KB	1 MB	48 sec	$0.03
10,000	1 KB	10 MB	8 min	$0.30
100,000	1 KB	100 MB	80 min	$3.00
1,000,000	1 KB	1 GB	13 hours	$30.00
10	50 GB	500 GB	100 min	$0.30 (10 ops)

*API cost: $0.03 per 1,000 operations (SaaS tier)

Infrastructure cost: On-premise = $0 (unlimited operations)

📊 Interactive conversion calculator

Troubleshooting

Error: "Cannot decrypt with source key"

Symptom:

{"error":"DECRYPTION_FAILED","message":"Source key cannot decrypt ciphertext"}

Causes: 1. Wrong source key (ciphertext encrypted with different key) 2. Corrupted ciphertext 3. Ciphertext from different system (incompatible format)

Fixes:

# Verify which key encrypted the data
curl -X POST https://api.ankatech.co/crypto/identify-key \
  -d '{"ciphertext":"eyJhbGc..."}'

Response: {"keyId":"actual-key-used","algorithm":"RSA_2048"}

Then: Use correct sourceKeyId for re-encryption

Error: "Payload too large"

Symptom:

{"error":"PAYLOAD_TOO_LARGE","message":"File exceeds 5MB compact limit"}

Solution: Use streaming API

# Switch from compact to streaming
curl -X POST https://api.ankatech.co/crypto/stream/reencrypt \
  -F "[email protected]" \
  # (same parameters, streaming endpoint)

Streaming supports: Unlimited file size (tested up to 100 GB)

Error: "Expired key cannot encrypt"

Symptom:

{"error":"INVALID_KEY_STATE","message":"Target key expired, cannot encrypt"}

Cause: Trying to re-encrypt to expired target key

Fix: Generate new target key or renew existing

# Generate fresh ML-KEM key
curl -X POST https://api.ankatech.co/keys \
  -d '{"algorithm":"ML_KEM_1024"}'

Then: Use new key as targetKeyId

What's Next?

Ready to convert your data? - 🚀 Re-encrypt your first file (5-minute test) - 📥 Download conversion toolkit (bulk scripts) - 📊 Estimate conversion time (for your data volume) - 📧 Request migration assistance (complex scenarios)

Migration workflow: 1. Import legacy keys - Bring RSA keys to AnkaSecure 2. Analyze compatibility - Validate and get recommendations 3. Convert data (this page) - Re-encrypt to PQC 4. Migration strategy - Complete roadmap

Advanced topics: - Streaming operations - Multi-GB file handling - Composite keys - Hybrid classical + PQC - Performance optimization - Maximize throughput

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

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