Migrating from RSA to ML-KEM: A Production Guide

This is a production guide for engineers who need to execute the migration from RSA key exchange to ML-KEM. If you need the "why," read What Happens When You Don't Migrate. This guide assumes you have decided to migrate and need the "how."

Understanding What You Are Replacing

RSA key exchange encrypts a pre-master secret with the server's RSA public key. The server decrypts with the private key. Both derive the session key. In TLS 1.3, RSA key transport is removed in favor of ECDHE, but many legacy systems and VPN configurations still use RSA.

ML-KEM (FIPS 203) replaces RSA key exchange with lattice-based key encapsulation. The client encapsulates a shared secret using the server's ML-KEM public key. The server decapsulates. Both derive the session key. The RSA math (integer factoring) is replaced with ML-KEM math (lattice problems) that quantum computers cannot solve.

Step 1: Assess Your RSA Key Exchange Footprint

Identify every system using RSA for key exchange: TLS configurations with RSA cipher suites (TLS_RSA_WITH_AES_256_GCM_SHA384 and similar), VPN concentrators using IKEv2 with RSA, SSH servers with RSA key exchange, application-level RSA encryption for session key establishment, and API gateways with RSA cipher suites.

Note: if your TLS 1.3 servers only use ECDHE (the default), you are replacing ECDHE with hybrid ECDHE+ML-KEM, not RSA with ML-KEM. The migration path is the same.

Step 2: Upgrade TLS Libraries

OpenSSL 3.x: ML-KEM through oqs-provider or native support. Verify with openssl list -kem-algorithms.

BoringSSL: Full ML-KEM support. Used by Chrome and Google infrastructure.

AWS-LC: Full ML-KEM support. Drop-in OpenSSL replacement. FIPS-validated module available.

Upgrade path: identify TLS library per system, check ML-KEM support, upgrade if needed, test that existing functionality is preserved.

Step 3: Configure Hybrid Key Exchange

Configure servers to offer hybrid key exchange (X25519+ML-KEM-768). For Nginx with OpenSSL 3.x, set the ssl_ecdh_curve directive to include the hybrid group. For Apache, use SSLOpenSSLConfCmd. For cloud load balancers, it is typically a console setting.

After configuration: restart, test with Chrome/Firefox (verify negotiated suite includes ML-KEM), check with openssl s_client.

Step 4: Measure Performance Impact

Expected handshake size increase: ~2.3 KB for X25519+ML-KEM-768 (ML-KEM-768 public key 1,184 bytes + ciphertext 1,088 bytes).

Expected latency increase: 0.1-0.5 ms on modern networks. ML-KEM operations take 50-100 us each.

Monitor in production: handshake completion rate (target above 99.9%), handshake latency (p50/p95/p99), connection throughput under load, client compatibility issues.

Step 5: Handle Client Compatibility

Most modern browsers support hybrid ML-KEM. Some clients may not: older browsers (pre-2024 Chrome), embedded devices, IoT systems, custom HTTP clients with older TLS libraries, legacy VPN clients.

The server continues offering classical-only cipher suites as fallback. TLS negotiation handles this automatically -- no client is broken by enabling hybrid. Track the percentage of hybrid vs classical-only connections. When hybrid exceeds 95%, consider deprecating classical-only.

Step 6: Extend to Internal Systems

After deploying on external systems, extend to internal: service-to-service communication, database connections, internal API gateways, message queues, monitoring. Lower HNDL priority but necessary for comprehensive quantum readiness.

Step 7: Add Post-Quantum Attestation

Hybrid key exchange protects transport. For comprehensive protection, add post-quantum attestation at the application layer. H33-74 provides three-family PQ signatures (ML-DSA, FALCON, SLH-DSA) for any data flow, independent of key exchange. This provides PQ integrity even for data on classical TLS connections.

Step 8: Plan RSA Deprecation

Once hybrid is deployed across all systems: announce deprecation timeline internally, monitor for systems still negotiating RSA-only, work with owners to upgrade, remove RSA cipher suites, verify no connection failures.

Timeline depends on complexity: simple environments 6 months after hybrid deployment, complex environments 12-24 months.

The migration from RSA to ML-KEM is the most impactful single step in post-quantum migration because key exchange is the operation most vulnerable to harvest-now-decrypt-later. Every day without ML-KEM key exchange is a day of data exposure that cannot be retroactively fixed. These steps are concrete, tested, and executable. Start with Step 1 today.

Frequently Asked Questions