Caching infrastructure designed for the key and signature sizes produced by NIST post-quantum cryptographic standards. The cache architecture that survives the transition from classical to quantum-resistant cryptography.
Post-quantum caching is caching infrastructure built to handle the key, signature, and ciphertext sizes produced by NIST post-quantum cryptographic algorithms (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA). Post-quantum keys are 10-100x larger than the classical keys they replace. A post-quantum cache stores and retrieves this material without latency degradation, using in-process memory access rather than network-bound serialization.
Every system that caches cryptographic material will be affected by the post-quantum transition. This is not a narrow concern limited to government systems. It is a structural change in the size of the data that caches store.
Classical cryptographic keys are small. An ECDH public key is 32 bytes. An Ed25519 signature is 64 bytes. These sizes are negligible in any cache. They fit inside a single CPU cache line. They serialize in nanoseconds. No infrastructure team has ever needed to think about them.
Post-quantum keys are not negligible. An ML-KEM-1024 public key is 1,568 bytes — 49 times larger than ECDH. An ML-DSA-65 signature is 3,309 bytes — 52 times larger than Ed25519. An SLH-DSA-256f signature is 49,856 bytes — 779 times larger. These sizes change the fundamental economics of caching.
| Algorithm | Standard | Key/Signature Size | Classical Equivalent | Size Increase |
|---|---|---|---|---|
| ML-KEM-768 | FIPS 203 | 1,184 B public key | ECDH: 32 B | 37x |
| ML-KEM-1024 | FIPS 203 | 1,568 B public key | ECDH: 32 B | 49x |
| ML-DSA-65 | FIPS 204 | 3,309 B signature | Ed25519: 64 B | 52x |
| ML-DSA-87 | FIPS 204 | 4,627 B signature | Ed25519: 64 B | 72x |
| FALCON-512 | Pending | 690 B signature | Ed25519: 64 B | 11x |
| SLH-DSA-128f | FIPS 205 | 17,088 B signature | Ed25519: 64 B | 267x |
| SLH-DSA-256f | FIPS 205 | 49,856 B signature | Ed25519: 64 B | 779x |
When a session store holding 1 million sessions transitions from ECDH + Ed25519 (96 bytes of crypto per session) to ML-KEM-768 + ML-DSA-65 (4,493 bytes), the cache memory for key material alone grows from 96 MB to 4.49 GB. This is the arithmetic of the standards NIST has published. It is not a projection. It is the byte-level specification.
A cache lookup for a 4,493-byte PQ session token must be as fast as a lookup for a 96-byte classical token. Network caches (Redis, Memcached) fail this requirement because serialization and transfer time scale linearly with value size. In-process caches pass it because access is a pointer dereference regardless of size.
A single 49 KB SLH-DSA signature must not evict thousands of 96-byte session tokens. The eviction policy must factor entry size into eviction priority so that one large cold entry does not displace many small hot entries.
Tracking access frequency for millions of entries must not scale with entry count. A count-min sketch in fixed memory (512 KiB regardless of key count) provides O(1) admission decisions without per-key overhead.
Serializing a 17 KB SLH-DSA signature to RESP protocol, transferring it over TCP, and deserializing it on the client adds 0.5-2ms per lookup. In-process access eliminates all three steps. The value is already in the application's memory. No encoding. No network. No decoding.
It is not encrypting cached data with PQ algorithms. That is cache encryption, a separate concern. Post-quantum caching is about handling the size of PQ key material that other systems generate and store in the cache.
It is not a new protocol. A post-quantum cache speaks RESP, REST, gRPC, or whatever protocol your application uses. The difference is architectural: where the cache runs (in-process vs. network), how it handles large values (constant latency vs. linear scaling), and how it decides what to keep (size-aware eviction vs. size-blind LRU).
It is not optional. Every TLS library, every certificate authority, every browser, and every operating system is migrating to PQ algorithms. Chrome already negotiates ML-KEM in TLS 1.3. OpenSSL 3.5 ships PQ as default. The key material arrives in your cache whether you built for it or not. The only question is whether your cache architecture handles the size increase gracefully or fails under it.
Values live in the application's address space. Access is a hash table lookup and a pointer dereference. Latency: 20-40 nanoseconds regardless of value size. No serialization, no network transfer. A 49 KB SLH-DSA signature and a 64-byte Ed25519 signature are accessed at the same speed. This architecture inherently meets all four PQ requirements.
Redis, Memcached, and ElastiCache can store PQ-sized values. They do not fail. They degrade. A Redis GET for a 4,493-byte value takes roughly 0.5-0.6ms instead of 0.3ms. Survivable for a single lookup. But a request that hits the cache four times accumulates 2.0-2.4ms instead of 1.2ms. At scale, this degradation compounds into a measurable percentage of your total request latency.
CDN caches are designed for HTTP responses, not for sub-millisecond key material lookups. They are the wrong layer for session tokens, JWT verification keys, and TLS tickets. CDN caching continues to work for static assets and API responses. It does not address the PQ key material problem.
The post-quantum transition is described in most publications as something that will happen. This framing is outdated. It is happening.
By the time the 2030 mandate arrives, every major browser, library, and framework will have been shipping PQ by default for five years. The mandate is not the trigger. The supply chain is the trigger. And the supply chain has already pulled it.
Cachee is an in-process cache engine written in Rust. It meets all four requirements of a post-quantum cache:
brew tap h33ai-postquantum/tap && brew install cachee
cachee init && cachee startThe post-quantum transition does not require a new cache architecture if your cache was built for the payload sizes PQ demands. It requires a cache that was built for them from the start.