Key Pool Architecture:
104x Speedup for Post-Quantum Crypto

Post-quantum key generation is expensive. ML-KEM (Kyber) keygen takes 33.3µs. Dilithium keygen takes 36.6µs. For high-throughput applications processing millions of requests per second, these microseconds add up fast.

Our solution: pre-generated key pools. By generating keys in advance during idle time, we reduce effective keygen latency to sub-microsecond levels—a 79-104x improvement.

The Problem with On-Demand Keygen

Consider a typical authentication flow:

1. User initiates authentication
2. Generate ephemeral Dilithium keypair (36.6µs)
3. Sign challenge (45µs)
4. Verify signature (36.9µs)
5. Generate ML-KEM keypair for session (33.3µs)
6. Establish encrypted channel (72.6µs)

Key generation alone accounts for 70µs—nearly 30% of a complete authentication. At scale, this becomes the bottleneck.

How Key Pools Work

The key insight is that cryptographic key generation doesn't need user-specific input. Keys are random—we can generate them in advance.

// Traditional approach: generate on demand
let keypair = dilithium::keygen();  // 36.6µs

// Pool approach: grab pre-generated key
let keypair = key_pool.acquire();   // 0.35µs

Our pool architecture:

• Background generation: Dedicated threads continuously generate keys during idle periods
• Lock-free queues: MPMC queues allow concurrent access without blocking
• Adaptive sizing: Pool size adjusts based on request rate and key consumption
• Secure memory: Keys are stored in mlock'd memory, never swapped to disk

Benchmark Results

January 2026 benchmarks on AWS c8g.metal-48xl (AWS Graviton4, 96 cores):

Throughput Impact

The throughput improvements are dramatic:

Security Considerations

Pre-generating keys doesn't compromise security:

• Keys are ephemeral: Pool keys are used once then destroyed
• CSPRNG seeding: Each key uses fresh randomness from the system CSPRNG
• Memory protection: Keys are stored in secure, non-swappable memory
• No key reuse: Each key is acquired atomically and never returned to the pool

When to Use Key Pools

Key pools are most beneficial when:

• You need ephemeral keys for each request (authentication, key exchange)
• Throughput requirements exceed 10,000+ ops/second
• Latency budgets are tight (<1ms total)
• You have available CPU cycles during idle periods

For long-term identity keys that are generated once and used repeatedly, direct generation is fine—the 33-37µs overhead happens only once.