Every write signed. Every read verified. Tamper detected at read time. Cache poisoning caught before your application sees it.
A compromised sidecar, a memory bit flip, a malicious replication inject — and your application sees wrong data. No cache product detects this. Not Redis. Not Memcached. Not Hazelcast.
Every SET signs the value with ML-DSA-65 and appends the signature. Every GET verifies the signature before returning data. Tampering is detected at read time, before your application ever sees the value.
When your application issues a SET, Cachee writes the value, then computes an ML-DSA-65 signature over [key || value] and appends the signature with a CATT marker. The key is included in the signed payload — so moving a value to a different key is detected as a forgery.
Format: [value][CATT marker][3,309-byte ML-DSA-65 signature]
When your application issues a GET, Cachee reads the stored value, strips the CATT marker and signature, verifies the signature against the key and value, and returns the data with an attestation status header. If verification fails, the response is flagged and the event is logged immediately.
Your application receives clean data plus a trust signal. Tampered entries never reach your business logic.
Four classes of cache integrity violations, all caught at read time before your application processes the data.
Cachee was not designed in a vacuum. It was extracted from a system that processes 2.17 million post-quantum authenticated operations per second.
Cachee was born from H33's post-quantum cryptography pipeline. STARK proof lookups were bottlenecking at 339µs through Redis. We built an in-process L1 and dropped it to 0.059µs. The same DashMap engine, the same Dilithium signatures that attest 2.17 million authentications per second, now protect your cache.
The ML-DSA-65 signing code running inside Cachee is not a library integration or a proof of concept. It is the same code path, the same key management, and the same verification logic that runs in H33's production pipeline on Graviton4 hardware at scale.
This is not a feature bolted onto a cache. This is a cache built by a team that has been shipping post-quantum cryptography in production since 2025.
The signature algorithm behind Cachee's attestation layer. NIST standardized. Quantum-resistant. Deterministic.
Post-quantum cache attestation is built into every Cachee instance. Enable it with a single environment variable. No configuration files. No schema changes. No restarts required on supported versions.
ML-DSA-65 signing adds approximately 145 microseconds to SET operations and 146 microseconds to GET operations for signature verification. For most workloads, this is negligible compared to network round-trip time. The signing and verification happen in-process with zero external dependencies. If your workload is latency-sensitive at the sub-millisecond level, you can selectively enable attestation on specific key prefixes.
Cachee supports automatic key rotation via the PQ_KEY_ROTATE_INTERVAL environment variable. When a new signing keypair is generated, the previous public key is retained in a verification ring for a configurable grace period. Existing signatures remain valid during the transition. Zero-downtime rotation with no cache flush required.
When PQ_ATTESTATION is not set or set to false, Cachee operates as a standard cache with no signing or verification overhead. The CATT marker and signature bytes are not appended. Enabling attestation is a one-line environment variable change with no schema migration or data loss. Existing unsigned entries are served normally and re-signed on their next SET.
Yes. Post-quantum cache attestation provides cryptographic proof that cached data has not been tampered with since it was written. This satisfies data integrity requirements in SOC 2 Type II, HIPAA, and PCI-DSS. The ML-DSA-65 algorithm is NIST FIPS 204 standardized, which satisfies federal compliance requirements including FedRAMP and CMMC. Every verification event is logged with timestamp, key, and attestation status for audit trails.
ML-DSA-65 (Dilithium) is a lattice-based signature scheme standardized by NIST as FIPS 204. It is resistant to attacks from both classical and quantum computers. While quantum threats to cache integrity may seem distant, harvest-now-decrypt-later attacks mean that adversaries can record signed data today and attempt to forge signatures later with quantum computers. Using post-quantum signatures now eliminates that future risk entirely.
ML-DSA-65 signed writes. Verified reads. Tamper detection at read time. One environment variable to enable. Born from a pipeline that signs 2.17 million operations per second.