Replace RSA with Post-Quantum Encryption
In One API Call

Why RSA Is Vulnerable

RSA's security rests on a single mathematical assumption: factoring the product of two large primes is computationally infeasible for classical computers. For 2048-bit RSA, the best classical factoring algorithm (General Number Field Sieve) requires approximately 2^112 operations. On the fastest supercomputers available, this would take longer than the age of the universe.

Shor's algorithm changes that equation entirely. Organizations must comply with NIST FIPS 203 and 204 standards to address this threat. Running on a quantum computer with sufficient logical qubits, Shor's algorithm factors RSA moduli in polynomial time—O((log N)^3). The resource estimate for breaking RSA-2048 is approximately 4,000 error-corrected logical qubits. For RSA-3072, approximately 6,000. For RSA-4096, approximately 8,000.

Making RSA keys larger does not help. The relationship between key size and quantum resources scales logarithmically, not exponentially. Doubling the RSA key size does not double the quantum effort; it barely increases it. There is no RSA key size that is quantum-resistant. The algorithm itself is the vulnerability.

What Replaces RSA

RSA serves two distinct cryptographic functions, and each has a different post-quantum replacement:

For Key Exchange: ML-KEM (FIPS 203)

RSA key transport (encrypting a symmetric key with the recipient's RSA public key) is replaced by ML-KEM (Module Lattice-based Key Encapsulation Mechanism), standardized as FIPS 203. ML-KEM is based on the CRYSTALS-Kyber algorithm.

Unlike RSA key transport, ML-KEM uses a key encapsulation mechanism (KEM) rather than public-key encryption. The sender generates a shared secret and ciphertext; the recipient decapsulates to recover the same shared secret. The shared secret is then used for symmetric encryption (AES-256-GCM). This is a conceptual shift from RSA's "encrypt a key" model to a "derive a shared secret" model, but the practical outcome is identical: two parties establish a shared symmetric key.

For Digital Signatures: ML-DSA (FIPS 204)

RSA signatures (PKCS#1 v1.5, PSS) are replaced by ML-DSA (Module Lattice-based Digital Signature Algorithm), standardized as FIPS 204. ML-DSA is based on the CRYSTALS-Dilithium algorithm.

ML-DSA provides the same functionality as RSA signatures: sign data with a private key, verify with a public key. The security is based on the Module Short Integer Solution (MSIS) problem, which has no known quantum or classical polynomial-time solution.

Performance: RSA vs. Post-Quantum

One of the most persistent concerns about post-quantum migration is performance. Here are the actual numbers:

The key takeaway: ML-KEM is faster than RSA for key operations, often by an order of magnitude. For a detailed ML-KEM vs. ECDH performance comparison, see our benchmark analysis. RSA key generation is notoriously slow (prime finding); ML-KEM keygen is nearly instant. ML-DSA signing is ~10x faster than RSA signing. The only metric where post-quantum is "worse" is key/signature sizes—they are larger. But on modern networks where bandwidth is rarely the bottleneck, this is a minor consideration compared to the security gain.

H33's production numbers are even more striking. By batching Dilithium operations across 32 users per ciphertext and running on optimized Graviton4 ARM hardware, H33 achieves 2.17 million authentications per second sustained, with per-auth latency of 38.5 microseconds. That is faster than most RSA implementations on equivalent hardware.

Code Examples: Before and After

Key Exchange: RSA to ML-KEM

// BEFORE: RSA key transport (VULNERABLE to quantum attack)
const crypto = require('crypto');
const { publicKey, privateKey } = crypto.generateKeyPairSync('rsa', {
  modulusLength: 2048,
  publicKeyEncoding: { type: 'spki', format: 'pem' },
  privateKeyEncoding: { type: 'pkcs8', format: 'pem' }
});
const symmetricKey = crypto.randomBytes(32);
const encrypted = crypto.publicEncrypt(publicKey, symmetricKey);
// Recipient decrypts
const decrypted = crypto.privateDecrypt(privateKey, encrypted);

// AFTER: ML-KEM key encapsulation (FIPS 203, quantum-resistant)
const h33 = require('@h33/sdk');

// Generate ML-KEM-768 keypair
const { publicKey, privateKey } = await h33.kem.generateKeyPair();

// Sender: encapsulate (produces shared secret + ciphertext)
const { sharedSecret, ciphertext } = await h33.kem.encapsulate(publicKey);

// Recipient: decapsulate (recovers same shared secret)
const recoveredSecret = await h33.kem.decapsulate(ciphertext, privateKey);
// sharedSecret === recoveredSecret; use for AES-256-GCM

Digital Signatures: RSA to ML-DSA

// BEFORE: RSA-PSS signature (VULNERABLE to quantum attack)
const sign = crypto.createSign('RSA-SHA256');
sign.update(document);
const signature = sign.sign(rsaPrivateKey, 'base64');

const verify = crypto.createVerify('RSA-SHA256');
verify.update(document);
const valid = verify.verify(rsaPublicKey, signature, 'base64');

// AFTER: ML-DSA-65 signature (FIPS 204, quantum-resistant)
const { publicKey, privateKey } = await h33.dsa.generateKeyPair();

const signature = await h33.dsa.sign(document, privateKey);
const valid = await h33.dsa.verify(document, signature, publicKey);
// One function call each. Same semantics. Quantum-resistant math.

Common Migration Mistakes

After working with dozens of organizations on PQC migration, these are the errors we see repeatedly:

1. Replacing RSA but Keeping ECDH

This is the most dangerous mistake. Teams audit their systems, find RSA usage, replace it with ML-KEM or ML-DSA, and call the migration complete. But they leave ECDH (P-256 or X25519) in their TLS configurations, SSH key exchange, or VPN tunnels. ECDH is equally vulnerable to Shor's algorithm. A partial migration provides a false sense of security.

2. Forgetting Hybrid Mode

If you cut over to PQ-only cryptography without a hybrid transition period, you will break interoperability with every partner, vendor, and client that has not migrated yet. The correct approach is to deploy hybrid mode first—ML-KEM + X25519 for key exchange, ML-DSA + Ed25519 for signatures—and then remove the classical component once your ecosystem has caught up.

H33 supports hybrid mode natively. You do not need to implement the combination logic yourself.

3. Ignoring Key Size Impacts

ML-DSA-65 signatures are 3,309 bytes vs. ECDSA's 64 bytes. If your system stores signatures in database columns with VARCHAR(128) constraints, or your protocol buffers have hardcoded field limits, or your JWT tokens are passed in HTTP headers with size limits—these will fail silently or throw errors that are difficult to diagnose in production.

Audit every system that handles cryptographic keys or signatures for size constraints before migration.

4. DIY Cryptographic Implementation

Implementing ML-KEM or ML-DSA from the NIST specification is a multi-month project for an experienced cryptographic engineer. Getting it correct is not enough; it must be constant-time (no timing side channels), resistant to power analysis, correctly handle edge cases in polynomial arithmetic, and produce output that matches NIST test vectors exactly.

A single timing leak in your NTT butterfly operation or a non-constant-time comparison in signature verification creates a side-channel vulnerability that leaks the private key. This is not theoretical—academic papers demonstrate key recovery from timing variations of less than 100 nanoseconds.

5. Not Testing at Scale

Post-quantum key and signature sizes mean more bytes over the wire, more bytes stored, and more CPU cycles per operation. At low volume, the impact is negligible. At 100,000 requests per second, the difference between a 64-byte ECDSA signature and a 3,309-byte ML-DSA signature is 310 MB/s of additional bandwidth. Plan for this. Load test before production deployment.

6. Assuming Your Cloud Provider Handles It

As of March 2026, AWS KMS, Azure Key Vault, and Google Cloud KMS offer limited or preview PQC support. If you rely on these services for key management, check their current algorithm support before assuming your data is quantum-resistant. "Coming soon" is not a compliance posture.

H33's Approach: One API, Zero Crypto Management

H33 exists to eliminate the cryptographic engineering burden from your team. When you call the H33 API, you get quantum-safe API security by default. There is no algorithm selection to get wrong, no parameter tuning to misconfigure, no constant-time implementation to audit.

The migration is purely software-based—no hardware changes required. The infrastructure runs on AWS Graviton4 ARM processors with a pure Rust stack—no external dependencies, no C bindings, no OpenSSL. Every cryptographic operation is benchmarked and publicly documented: 2.17 million authentications per second sustained, 38.5 microseconds per auth, with less than 1% variance.

Start with the free tier. Replace your RSA calls with H33 API calls. Run your test suite. When everything passes, deploy. That is the entire migration.