Your AI infrastructure likely uses RSA-2048 or ECDSA P-256 for authentication and encryption. Both will become vulnerable when large-scale quantum computers arrive. The timeline is uncertain, but the risk is measurable.
If you're running Model Context Protocol (MCP) implementations, you need cryptographic agility now. Not because quantum computers are cracking keys today, but because the data you're protecting today will still matter in five years.
Why This Matters Now
Quantum computers threaten asymmetric cryptography. Shor's algorithm can efficiently factor large primes and solve discrete logarithm problems, making RSA and ECC vulnerable. Your current MCP authentication flows, TLS handshakes, and signed message exchanges rely on these algorithms.
"Harvest now, decrypt later" attacks are already happening. Adversaries capture encrypted traffic today, betting they'll have quantum capability to decrypt it later. If your MCP servers handle sensitive model interactions, customer data, or proprietary prompts, that traffic is worth harvesting.
Cryptographic agility means you can swap algorithms without rewriting your entire stack. You're not just adding Post-Quantum Cryptography (PQC), you're building a system that can evolve as standards mature.
What You Need Before Starting
Before you touch any code, inventory your current cryptographic dependencies:
Audit Your MCP Implementation:
- Which libraries handle key exchange? (OpenSSL, BoringSSL, libsodium)
- Where do you perform signature verification?
- What protocols govern client-server authentication?
- Are you using certificate pinning that'll break with new algorithms?
Tool Requirements:
- Access to liboqs (Open Quantum Safe library) or equivalent PQC implementation
- Your current MCP server codebase with admin access
- Testing environment that mirrors production network topology
- Certificate management tooling that supports hybrid certificates
Knowledge Gaps to Fill:
- NIST's selected PQC algorithms: ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (formerly CRYSTALS-Dilithium) for signatures
- Hybrid mode concepts (combining classical and PQC algorithms)
- Performance implications of larger key sizes and signature lengths
Don't skip the inventory step. You can't implement agility if you don't know where cryptography lives in your stack.
Step-by-Step Implementation
Phase 1: Add PQC Support Without Breaking Existing Flows
Start with hybrid mode. This combines classical algorithms with PQC, so you're protected even if PQC has undiscovered weaknesses.
For MCP server authentication, implement ML-KEM alongside your existing ECDH:
# Pseudocode for hybrid key exchange
classical_shared_secret = ecdh_key_exchange(client_pubkey, server_privkey)
pqc_shared_secret = ml_kem_decapsulate(client_kem_ciphertext, server_kem_privkey)
final_shared_secret = kdf(classical_shared_secret || pqc_shared_secret)
The concatenation and key derivation ensure both algorithms must break for the exchange to fail.
Phase 2: Implement Algorithm Negotiation
Your MCP protocol needs to communicate which algorithms both parties support. Add a capability exchange during handshake:
{
"supported_kex": ["ecdh-p256", "ml-kem-768", "hybrid-ecdh-mlkem"],
"supported_sig": ["ecdsa-p256", "ml-dsa-65", "hybrid-ecdsa-mldsa"],
"preferred": "hybrid-ecdh-mlkem"
}
The server selects the strongest mutually supported option. This lets you gradually roll out PQC without forcing all clients to upgrade simultaneously.
Phase 3: Build Algorithm Rotation Capability
Cryptographic agility isn't just about adding PQC, it's about making algorithm changes routine. Implement configuration-driven algorithm selection:
# crypto-config.yaml
key_exchange:
current: hybrid-ecdh-mlkem
fallback: ecdh-p256
rotation_date: 2025-06-01
signatures:
current: hybrid-ecdsa-mldsa
fallback: ecdsa-p256
Your code should read this config at startup, not hardcode algorithm choices. When NIST finalizes additional PQC standards or discovers vulnerabilities, you change a config file instead of rewriting authentication logic.
Phase 4: Update Certificate Infrastructure
If you're using X.509 certificates for MCP server identity, you need hybrid certificates. These contain both classical and PQC public keys in the same certificate.
Work with your CA to issue hybrid certificates, or run your own internal CA with PQC support. The certificate chain validation logic needs to verify both signature algorithms.
Validation - How to Verify It Works
Test Algorithm Negotiation:
Run your MCP client against the updated server with different capability sets. Verify the server selects the correct algorithm:
# Force client to only support classical
./mcp-client --crypto-profile classical-only
# Server should fall back to ECDH
# Enable PQC support
./mcp-client --crypto-profile pqc-enabled
# Server should negotiate hybrid mode
Check your logs for negotiation outcomes. You should see which algorithm was selected and why.
Measure Performance Impact:
PQC algorithms have larger key sizes and slower operations. Benchmark your handshake time before and after:
import time
start = time.time()
for _ in range(1000):
establish_mcp_connection()
duration = time.time() - start
print(f"Avg handshake: {duration/1000*1000:.2f}ms")
ML-KEM-768 adds roughly 2-5ms to handshake time. If that breaks your latency budget, you'll need to optimize or accept the tradeoff.
Verify Backward Compatibility:
Deploy your updated server alongside legacy clients that don't support PQC. Confirm they can still connect using classical algorithms. Your fallback logic must work perfectly.
Maintenance and Ongoing Tasks
Monitor NIST Standardization:
NIST is still finalizing additional PQC algorithms. Subscribe to their announcements and be ready to add newly standardized algorithms to your supported list.
Track Library Updates:
liboqs and other PQC libraries receive frequent updates as implementations mature. Set a quarterly review to update dependencies and test for regressions.
Plan Migration Timelines:
You won't run hybrid mode forever. Once PQC is proven stable and widely deployed, you'll deprecate classical-only support. Document your migration timeline now:
- 2024-2025: Hybrid mode mandatory for new deployments
- 2026: Classical-only connections logged as warnings
- 2027: Classical-only support removed
Audit Cryptographic Inventory Quarterly:
New MCP features might introduce new cryptographic dependencies. Every quarter, re-run your inventory to catch new classical algorithm usage before it becomes technical debt.
Cryptographic agility isn't a one-time implementation. It's a capability you maintain. The quantum threat is real, but the bigger risk is building systems so rigid that you can't adapt when threats evolve.
