PQC Migration Guide
Guide to migrating from classical to post-quantum cryptography with 4Quays
Post-quantum cryptography (PQC) protects against the threat of quantum computers breaking classical encryption. 4Quays makes PQC migration a policy change, not a code change.
Why PQC Matters
The Quantum Threat
Quantum computers threaten current cryptographic algorithms:
| Algorithm | Quantum Impact |
|---|---|
| RSA | Broken by Shor's algorithm |
| ECDSA | Broken by Shor's algorithm |
| AES-256 | Weakened (still secure with larger keys) |
Harvest Now, Decrypt Later
Adversaries may be collecting encrypted data today to decrypt when quantum computers become available. Sensitive data with long-term value should use PQC now.
NIST PQC Standards
NIST has standardized post-quantum algorithms:
- ML-KEM (formerly CRYSTALS-Kyber) — Key encapsulation
- ML-DSA (formerly CRYSTALS-Dilithium) — Digital signatures
4Quays supports these NIST-standardized algorithms.
PQC in 4Quays
Supported PQC Algorithms
Key Encapsulation (ML-KEM)
| Variant | Security Level | Key Size |
|---|---|---|
| ML-KEM-512 | Level 1 | 1632 bytes |
| ML-KEM-768 | Level 3 | 2400 bytes |
| ML-KEM-1024 | Level 5 | 3168 bytes |
Digital Signatures (ML-DSA)
| Variant | Security Level | Signature Size |
|---|---|---|
| ML-DSA-44 | Level 2 | ~2.4 KB |
| ML-DSA-65 | Level 3 | ~3.3 KB |
| ML-DSA-87 | Level 5 | ~4.6 KB |
How It Works
PQC in 4Quays follows the hybrid encryption pattern:
- Payload encryption: AES-256-GCM (quantum-resistant with 256-bit keys)
- Key encapsulation: ML-KEM replaces RSA key wrapping
- Digital signatures: ML-DSA replaces RSA/ECDSA signing
Classical: AES-256-GCM + RSA-2048 key wrapping PQC: AES-256-GCM + ML-KEM-768 key encapsulation
Migration Path
Step 1: Assess Current State
Review your current policies:
const policies = await fetch('https://api.4quays.com/admin/policies', {
headers: { 'Authorization': `Bearer ${adminKey}` },
});
// Identify policies using classical algorithms
policies.filter(p => p.algorithm.keyWrapping.startsWith('RSA'));
Step 2: Coordinate with External Services
PQC migration requires coordination:
- Confirm external service supports PQC
- Obtain their PQC public key
- Agree on migration timeline
- Plan testing phase
Step 3: Import PQC Keys
Import the service's PQC public key:
await fetch('https://api.4quays.com/admin/keys', {
method: 'POST',
headers: {
'Authorization': `Bearer ${adminKey}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
type: 'ML-KEM-768',
publicKey: '-----BEGIN PUBLIC KEY-----\n...',
serviceId: 'service_id',
description: 'Bank A ML-KEM-768 production key',
}),
});
Step 4: Create New Policy Version
Create a new version of your policy with PQC:
await fetch('https://api.4quays.com/admin/policies/policy_id/versions', {
method: 'POST',
headers: {
'Authorization': `Bearer ${adminKey}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
algorithm: {
encryption: 'AES-256-GCM',
keyWrapping: 'ML-KEM-768', // Changed from RSA-2048
},
activationDate: '2026-06-01T00:00:00Z',
description: 'Upgrade to post-quantum key encapsulation',
}),
});
Step 5: Test in Staging
Before the activation date:
- Create a staging policy with PQC
- Test with the external service
- Verify payloads are processed correctly
- Check performance impact
Step 6: Monitor Activation
On the activation date:
- Watch audit logs for the new algorithm
- Monitor error rates
- Verify external service is accepting payloads
- Have rollback plan ready
Zero Code Changes
The key benefit: your application code doesn't change.
// Before PQC migration const protected = await fourq.protect(payload, 'BANK-TRANSFER-001'); // After PQC migration - SAME CODE const protected = await fourq.protect(payload, 'BANK-TRANSFER-001');
The policy determines the algorithm. When the policy updates to PQC, subsequent operations automatically use the new algorithm.
Hybrid Approach
For extra security during transition, consider hybrid encryption:
Hybrid: AES-256-GCM + RSA-2048 + ML-KEM-768
This provides protection if either algorithm is compromised. Contact support to enable hybrid mode.
Monitoring Migration Progress
Track algorithm adoption:
const stats = await fetch('https://api.4quays.com/admin/audit/algorithms', {
headers: { 'Authorization': `Bearer ${adminKey}` },
params: {
from: '2026-01-01T00:00:00Z',
to: '2026-12-31T23:59:59Z',
},
});
// {
// "AES-256-GCM+RSA-2048": 45000,
// "AES-256-GCM+ML-KEM-768": 55000
// }
Generate compliance reports showing PQC adoption percentage.
Rollback Procedure
If issues occur after PQC activation:
- Create emergency policy version reverting to classical
- Set immediate activation (no scheduled date)
- Monitor for resumed normal operations
- Investigate the issue in staging
- Re-attempt migration after resolution
// Emergency rollback
await fetch('https://api.4quays.com/admin/policies/policy_id/versions', {
method: 'POST',
body: JSON.stringify({
algorithm: {
encryption: 'AES-256-GCM',
keyWrapping: 'RSA-2048', // Rollback to classical
},
activationDate: null, // Immediate activation
description: 'Emergency rollback from PQC',
}),
});
Timeline Recommendations
| Data Sensitivity | Recommendation |
|---|---|
| Long-term secrets (25+ years) | Migrate to PQC now |
| Sensitive business data | Migrate within 2 years |
| Short-term transactional | Monitor and plan |
Performance Considerations
PQC algorithms have different performance characteristics:
| Operation | RSA-2048 | ML-KEM-768 |
|---|---|---|
| Key generation | ~100ms | ~1ms |
| Encapsulation | ~1ms | ~0.1ms |
| Decapsulation | ~10ms | ~0.1ms |
| Key size | 256 bytes | 2400 bytes |
ML-KEM is generally faster but produces larger payloads.
What's Next
- Supported Algorithms — Complete algorithm reference
- Security Best Practices — Security recommendations