Cache Attestation
Every cache entry is signed by three post-quantum families.
A signed cache entry is a provable fact -- not data that might have been tampered with.
Cache poisoning requires breaking three independent mathematical assumptions simultaneously.
Cache attestation is the practice of cryptographically signing every cached entry with post-quantum digital signatures. Every SET produces a 58-byte H33-74 receipt signed by three independent signature families: ML-DSA-65 (lattice), FALCON-512 (NTRU lattice), and SLH-DSA (hash-based). Every GET verifies the receipt before returning the result. Poisoned data fails verification and is rejected. A signed cache entry is a provable fact -- not data that might have been tampered with.
Traditional Caches Are Black Boxes
You put data in. You get data back. You hope nothing changed it in between.
Cache poisoning is not theoretical. It is a documented attack vector in Redis, Memcached, and CDN caches. The attacker does not need to break encryption -- they only need write access to the cache. Without attestation, every consumer downstream trusts the poisoned value because they have no mechanism to verify it.
Three Families. Three Hardness Assumptions.
Breaking one signature family does not weaken the attestation. An attacker must break all three simultaneously -- three independent mathematical bets.
These are three independent hardness assumptions. MLWE lattice problems, NTRU lattice problems, and hash function preimage resistance are mathematically unrelated. A quantum algorithm that breaks MLWE does not help against NTRU. A hash function weakness does not help against either lattice family. The attestation survives as long as any one of the three families remains unbroken.
| Family | Hardness Assumption | Signature Size | Sign Time | Verify Time |
|---|---|---|---|---|
| ML-DSA-65 | MLWE (lattice) | 3,309 B | ~0.2 ms | ~0.1 ms |
| FALCON-512 | NTRU lattice (SIS) | 656 B | ~0.5 ms | ~0.05 ms |
| SLH-DSA | Hash (SHA3) | 17,088 B | ~5 ms | ~0.3 ms |
| Total (3 families) | Three independent bets | 21,053 B | ~5.7 ms | ~0.45 ms |
Signing is a write-path cost (5.7ms, amortized over batch). Verification is a read-path cost (0.45ms). Both are dwarfed by the computation they attest -- a STARK verification at 25 microseconds, an FHE computation at 100 milliseconds. The attestation overhead is noise relative to the value it protects.
58 Bytes. Everything You Need.
The H33-74 receipt is a compact, self-describing attestation that travels with every cached entry. 58 bytes of metadata that prove authenticity.
The receipt does not contain the full signatures -- those are stored in the Cachee Archive Bundle (CAB). The receipt contains only the prefixes needed to identify which signature algorithms were used and to locate the full signatures for verification. This keeps the per-entry overhead at 58 bytes while supporting full independent verification.
The Cachee Archive Bundle (CAB)
Self-Contained Verification
A CAB is a self-contained package that includes everything needed to verify a cached result independently. No network connection. No Cachee account. No API key. No trust in H33 or any third party. Download the CAB, run cachee-verify, get a cryptographic answer.
| Component | Size | Purpose |
|---|---|---|
| Cached result | Variable | The actual cached value (bytes to KB) |
| H33-74 receipt | 58 B | Compact attestation metadata |
| ML-DSA-65 signature | 3,309 B | Lattice-based signature |
| FALCON-512 signature | 656 B | NTRU lattice-based signature |
| SLH-DSA signature | 17,088 B | Hash-based signature |
| Public verification keys | ~2,500 B | All three family public keys |
| Computation fingerprint | 32 B | SHA3-256 provenance digest |
| Total CAB | ~24 KB | Everything needed for independent verification |
The CAB is designed for offline verification, archival, and regulatory compliance. A financial auditor receives a CAB file and can verify it on an air-gapped machine. A court can verify a cached result years after the Cachee instance that produced it has been decommissioned. The math does not expire.
cachee-verify in Action
Try it: brew install cachee && cachee-verify --help
We Do Not Need to Exist for Your Data to Be Trusted
This is the independence argument, and it is the most important property of cache attestation.
If H33 ceases to operate tomorrow, every CAB file ever produced remains independently verifiable. The verification does not call home. It does not check a license server. It does not require a subscription. The cachee-verify tool is open-source and statically linked. The cryptographic algorithms are NIST standards. The public keys are embedded in the CAB.
Compare this to any other integrity mechanism that depends on a vendor's API, certificate authority, or cloud service. When the vendor disappears, the integrity guarantee disappears with it. Cache attestation is different. The integrity is in the math, not in the vendor.
Vendor-Dependent Integrity
TLS certificates expire. API keys are revoked. Cloud services shut down. When the vendor disappears, the integrity guarantee disappears. Every verification is a dependency on someone else's uptime.
Cache Attestation
Public keys embedded in the CAB. Algorithms are NIST standards. Verification tool is open-source. Works offline, air-gapped, on any platform. The math does not expire. The math does not need a subscription.
Where Cache Attestation Matters
What Cache Attestation Prevents
Cache poisoning is the most common attack against caching infrastructure. It takes many forms, and attestation defends against all of them.
| Attack | How It Works | Without Attestation | With Attestation |
|---|---|---|---|
| Direct cache poisoning | Attacker writes malicious value to cache | Succeeds -- no integrity check | Rejected -- no valid receipt |
| Man-in-the-middle | Attacker intercepts and modifies cached value in transit | Succeeds -- cache returns modified value | Rejected -- hash mismatch |
| Stale data injection | Attacker replays an old cached value after it was updated | Succeeds -- no version check | Rejected -- timestamp mismatch |
| Cross-tenant contamination | Tenant A's cached data served to Tenant B | Depends on namespace isolation | Rejected -- fingerprint includes tenant context |
| Quantum forgery (future) | Quantum computer forges a classical digital signature | All classical signatures broken | Three PQ families -- quantum-resistant by design |
The Attestation Pipeline
When you execute a SET command with Cachee, the following sequence executes in the write path:
// Write path: SET key value
1. Compute SHA3-256(value) // 32-byte content hash
2. Build computation fingerprint // input + function + params + version + HW
3. Construct H33-74 receipt (58 bytes) // version + timestamp + hash + prefixes + flags
4. Sign receipt with ML-DSA-65 // 3,309-byte signature
5. Sign receipt with FALCON-512 // 656-byte signature
6. Sign receipt with SLH-DSA // 17,088-byte signature
7. Store value + receipt + signatures // single atomic write
// Read path: GET key
1. Retrieve value + receipt // from cache
2. Verify SHA3-256(value) == receipt.hash // content integrity
3. Verify ML-DSA-65 signature // lattice check
4. Verify FALCON-512 signature // NTRU lattice check
5. Verify SLH-DSA signature // hash-based check
6. All pass? Return value // safe to use
7. Any fail? Reject and delete entry // poisoned data eliminated
Signing happens on the write path (5.7ms total). Verification happens on the read path (0.45ms total). For hot cache entries accessed thousands of times, the amortized cost of attestation approaches zero -- you sign once and verify many times.
Batch Attestation: One Signature Per 32 Entries
For high-throughput workloads, Cachee supports batch attestation. Instead of signing each cache entry individually, a Merkle tree is built over a batch of entries, and the three PQ families sign the Merkle root once.
Individual Attestation
Each entry gets its own signature triplet. 32 entries = 96 signatures = 182.4ms of signing time. Full per-entry provenance. Best for low-volume, high-value workloads.
Batch Attestation
Merkle tree over 32 entries. One root signature. Each entry carries a Merkle proof (~160 bytes) to the signed root. 5.7ms for the batch. Individual entries still independently verifiable via Merkle inclusion proof.
Batch attestation is the default for high-throughput workloads (biometric auth at 1.6M+ ops/sec, STARK verification caching, ML inference results). Individual attestation is available when per-entry provenance is required (financial settlements, legal documents, healthcare records).
Get Started
brew tap h33ai-postquantum/tap && brew install cachee
cachee init && cachee start
# Every SET is automatically attested
SET audit:trade_q4 "settlement:confirmed" FP <fingerprint_hex>
# Every GET is automatically verified
GETVERIFIED audit:trade_q4
# Export CAB for offline verification
cachee export-cab audit:trade_q4 --output trade_q4.cab
# Verify anywhere, offline, no account needed
cachee-verify trade_q4.cab
Attestation is on by default. Every SET is signed. Every GET is verified. No configuration needed. For batch attestation, use the --batch flag or configure the batch size in cachee.toml.
Every cached result should be a provable fact. Not a hope.
Install Cachee Computation Fingerprinting