Crypto-Shredding Deletion: Deleting the Key Instead of the Data

When you delete a file, the bits stay on disk. The operating system removes a pointer—a directory entry—and calls it done. On modern SSDs with wear leveling, those residual bits can persist for months or years. Crypto-shredding deletion bypasses this problem entirely: instead of hunting down every copy of the data, you destroy the encryption key that makes the data intelligible. The ciphertext remains—on disk, in backups, in replicas—but without the key it is indistinguishable from random noise. Permanently. This post is a deep dive into how that works in practice, where it breaks, and why we built our own deletion pipeline around it. It connects to our broader pillar on privacy by architecture and sits alongside sibling pieces on key management and HSM practices and memory encryption at rest.

Key Takeaways

• Crypto-shredding renders data irrecoverable by destroying the encryption key rather than tracking down and overwriting every copy of the ciphertext—a practical necessity for distributed systems, append-only logs, and backups.
• Per-entity key isolation is the hard requirement that most implementations underestimate: without it, one deletion request either destroys everyone's data or affects nobody's.
• Regulators—including the EDPB, ICO, and CNIL—explicitly accept cryptographic erasure as valid under the right to be forgotten, provided the algorithm is strong, destruction is irreversible, and the process is auditable.
• The most common real-world failure isn't the concept; it's backup hygiene. Forgotten key copies in automated backups, HA clusters, or dev environments silently undermine the guarantee.
• For AI products with persistent memory layers, crypto-shredding addresses a problem that traditional row-level deletion cannot: erasing user data from vector stores, embeddings, and retrieval indices without rebuilding the entire index.

What is crypto-shredding, exactly?

Crypto-shredding is the deliberate destruction of encryption keys to render the corresponding ciphertext permanently unreadable. The formal definition is straightforward: assuming the key is not recovered and the encryption algorithm is not broken, the data becomes irrecoverable. You do not need to locate every backup tape, every replica, every snapshot. You need to locate the key. One object, in one place, under your control.

This is not the same as pressing "delete" in a filesystem. Traditional deletion removes metadata—the pointer that says "file X lives at blocks 4,271 through 4,309." The blocks themselves remain allocated until the OS needs them for something else. Forensic recovery tools exploit this gap routinely. Crypto-shredding sidesteps the gap by making the blocks' content meaningless regardless of whether they are overwritten.

Why doesn't normal deletion work for distributed systems?

Normal deletion assumes you know where all the copies are. In a distributed system, you usually don't—or you can't reach them all atomically.

Consider an append-only log like Kafka. A user's personal data might appear across topic partitions, replicas, and downstream consumer state stores. You cannot retroactively remove a record from the middle of a committed log without violating the append-only invariant. Compaction helps eventually, but "eventually" is not a timeline regulators accept for erasure requests. Crypto-shredding lets the ciphertext remain in the log—intact, immutable, compliant with the log's integrity guarantees—while rendering it meaningless to anyone who reads it.

The same logic applies to backups. If you run nightly encrypted backups and a user requests deletion on day 15, you now have 15 backup sets containing their data. Restoring each one, surgically removing the user's records, re-encrypting, and re-archiving is operationally brutal. Destroying one key is not.

How does per-entity key isolation work?

Per-entity key isolation means every user—or every record, depending on your granularity—gets its own encryption key. This is the architectural decision that makes crypto-shredding viable, and it is the one most teams underestimate.

Without per-entity isolation, you have a shared key encrypting data for many users. Destroying that key to satisfy one erasure request destroys everyone's data. Keeping it alive to preserve everyone else's data means the deleted user's ciphertext remains decryptable. Neither outcome is acceptable. As one implementation guide puts it, each record or patient gets its own key so that destroying one key does not wipe out every other user's data.

The cost is key management complexity. If you have a million users, you have a million keys. Each key needs secure storage, access control, rotation policy, and—critically—a destruction procedure that is both irreversible and auditable. This is where hardware security modules or cloud KMS services earn their cost. More on that in our sibling piece on key management and HSM practices.

What granularity should you pick?

Per-user is the common baseline. Per-record is sometimes necessary for systems where individual data elements need independent lifecycle management—healthcare, for instance, where a single patient might have records subject to different retention rules. For most SaaS products, per-user key isolation is sufficient and keeps the key management surface tractable.

We use per-account key isolation. When an account is deleted, we destroy that account's key. Every stored copy—primary storage, backups, replicas—becomes permanent noise. There is a grace window before destruction is final, so accidental deletions can be reversed. After the window closes, it is irreversible. Not hidden. Not archived. Gone.

Do regulators actually accept crypto-shredding as valid erasure?

Yes. The European Data Protection Board, the UK's Information Commissioner's Office, and France's CNIL have all explicitly recognized cryptographic erasure as a valid mechanism for satisfying the right to be forgotten—provided three conditions are met: the encryption algorithm must be strong, key destruction must be irreversible, and the destruction process must be auditable.

That last condition—auditability—is where many implementations fall short. Telling a regulator "we deleted the key" is an assertion. Showing them a timestamped, cryptographically signed erasure certificate with a chain of custody for the key's lifecycle is evidence. The difference matters when non-compliance with GDPR's erasure provisions can trigger fines up to €20 million or 4% of global annual turnover.

How does crypto-shredding reconcile conflicting regulatory obligations?

It separates data integrity from data confidentiality. Financial regulations like MiFID II require you to retain transaction records for years. GDPR requires you to delete personal data on request. These obligations appear to conflict directly. Crypto-shredding resolves the conflict by keeping the ciphertext and hash chain intact for audit integrity while destroying the key that would reveal any personal data. The record still exists—its integrity is verifiable—but its content is inaccessible. Both regulators are satisfied.

What are the real failure modes?

The concept is sound. The failures are operational. Here are the ones we have seen or studied.

Backup hygiene: the most common failure

Multiple 2026 practitioner guides flag the same problem: forgotten key copies linger in automatic backups, high-availability clusters, or developer test environments even after the primary key is destroyed. If a key backup exists anywhere, the crypto-shredding guarantee is void. This is not a theoretical concern. It is the most frequently cited real-world failure mode.

The fix is a rigorous key inventory—knowing every location where a key or key material might reside, including HSM replicas, cloud KMS snapshots, and CI/CD environment variables. If you cannot enumerate every copy, you cannot guarantee destruction.

Key destruction is not instantaneous

Cloud KMS services typically implement a safety window before final key destruction. The default in some implementations is 30 days, with a configurable minimum of 24 hours. This is a feature, not a bug—it prevents catastrophic accidental deletion. But it means your erasure timeline is "destruction requested at T, irrevocable at T + grace window," not "deleted at T." Your data processing agreement needs to reflect this honestly.

Algorithm lifespan and post-quantum risk

Crypto-shredding's guarantee is only as strong as the encryption algorithm protecting the ciphertext. If AES-256 is ever broken—or if a sufficiently powerful quantum computer renders current algorithms vulnerable—ciphertext that was "shredded" decades ago could theoretically become readable. Cloud KMS providers have begun adding post-quantum digital signature algorithm support in anticipation. For data with a multi-decade sensitivity horizon, this is a real consideration, not an academic one.

We do not claim crypto-shredding provides an infinite guarantee. We claim it provides a guarantee bounded by the strength of the underlying cryptography and the completeness of key destruction. That is an honest framing, and it is the only accurate one.

Why does crypto-shredding matter specifically for AI memory systems?

Because AI products with persistent memory face a deletion problem that traditional databases do not.

When a user's data lives in a relational database, you can issue a DELETE FROM users WHERE id = ? and—setting aside backups—the record is gone. When a user's data has been embedded into a vector store, chunked into a retrieval-augmented generation (RAG) index, logged in conversation histories, and cached in inference pipelines, "deletion" becomes a distributed systems problem with no single point of control.

A January 2026 paper on AI memory architecture (MemTrust) implements crypto-shredding specifically for this scenario—treating it as the mechanism to reconcile persistent AI memory with GDPR and CCPA erasure rights. The paper notes that physical deletion from massive vector indices is technically difficult and hard to verify in cloud environments. Crypto-shredding offers a tractable alternative: the embeddings remain in the index, but without the decryption key, they decode to nothing meaningful.

This is directly relevant to how we handle memory at Selina. Memory is encrypted at rest. It is not end-to-end encrypted—a slice of each request reaches a frontier provider at inference time, and we state that plainly. But the stored memory layer is encrypted with per-account keys, and when an account is deleted, the key destruction renders all stored memory—including any backup copies—permanently unrecoverable.

We do not fine-tune models on user data. User context lives in the retrieval and memory layer, not in model weights. This is a deliberate architectural choice that makes crypto-shredding effective for us—destroying the key actually removes the data from our system, because the data was never absorbed into a model. For products that do fine-tune on user data, crypto-shredding the storage layer is necessary but not sufficient. The data may persist in model weights, and model unlearning remains an unsolved problem in any verifiable sense.

How do you audit and prove that deletion actually happened?

You produce a cryptographic erasure certificate—a timestamped, signed record that a specific key was destroyed at a specific time through a specific process, and that no copies of the key remain in your key inventory.

This is not optional. The EDPB's acceptance of crypto-shredding as valid erasure is conditional on auditability. If you cannot prove the key was destroyed, you cannot prove the data was erased. The burden of proof is on the data controller.

In mid-2026, Google Research announced a new auditing framework aimed at verifying whether AI models have genuinely "forgotten" data. This signals growing scrutiny—not just of whether you assert deletion, but of whether you can demonstrate it to an independent auditor. The direction is clear: deletion is not a feature. It is a claim, and claims require evidence.

Our approach: when an account is deleted and the grace window expires, key destruction is logged with a tamper-evident record. The ciphertext remains in backups—we do not attempt to surgically remove it—but the erasure certificate documents that the key required to decrypt it no longer exists anywhere in our key management infrastructure. This is the honest version: we cannot guarantee we have overwritten every last ciphertext byte on every backup medium. We can guarantee the key is gone, and without the key, the bytes are noise.

What does a minimal crypto-shredding implementation look like?

At minimum, you need four components:

1. Per-entity key generation. Every user (or record, depending on your model) gets a unique data encryption key (DEK). DEKs are themselves encrypted by a key encryption key (KEK) stored in a KMS or HSM.
2. Encryption at write time. All personal data is encrypted with the user's DEK before it touches persistent storage—primary database, search index, vector store, message queue, whatever.
3. Key destruction on erasure request. When a deletion is requested, the DEK is destroyed according to a defined procedure—typically via the KMS's scheduled destruction API, with a configurable grace window.
4. Audit trail. Every key lifecycle event—creation, rotation, destruction request, final destruction—is logged in a tamper-evident store.

The implementation gets harder at each layer of your stack. Encrypting a Postgres column is straightforward. Encrypting individual chunks in a vector store while preserving similarity-search performance is not. Encrypting Kafka messages per-user while maintaining consumer group semantics requires careful key-routing logic. The Kafka-specific pattern typically involves encrypting message values with per-user keys and storing the key reference in the message header, so consumers can look up and apply the correct DEK—or fail gracefully when the key no longer exists.

What we learned building this into a production AI product

A few specifics from our experience, without overstating what we got right on the first try.

Key isolation was the hard part, not encryption. Getting AES encryption into the storage layer was mechanical. Designing a key management topology where every account has an isolated key, where keys are stored in a dedicated KMS, where the KMS itself is not a single point of failure, and where key destruction propagates to every replica—that was the real engineering work. It took longer than the encryption itself by a wide margin.

The grace window is a product decision, not just a safety mechanism. Users accidentally delete accounts. Support tickets arrive 48 hours later. The grace window before crypto-shredding becomes irreversible is a product decision about the tradeoff between user recovery and deletion finality. We landed on a window that balances both. After it closes, we cannot help you. We do not have a backdoor. That is the point.

Backups required the most paranoia. Our backup pipeline runs automatically. Every backup contains encrypted user data. If a backup also contained a copy of the user's key—or a snapshot of the KMS state that included the key—then destroying the primary key would be theater. We had to verify, repeatedly, that our backup pipeline stores ciphertext only, never key material. The keys live exclusively in the KMS. This sounds obvious in retrospect. It was not obvious during implementation.

Memory—not files—was the novel challenge. Selina's files and transfers (SelinaSEND) are end-to-end encrypted; the crypto-shredding story there is clean. Memory was harder. Memory is adaptive, not a transcript—fragments of context, summaries, inferred preferences. It is encrypted at rest, but a slice reaches a frontier provider during inference. We cannot crypto-shred what a provider processed transiently. We can—and do—crypto-shred everything we store. That is the honest boundary, and we state it rather than obscure it.

How does crypto-shredding relate to data minimization?

Crypto-shredding is the last line of defense, not the first. If you collect data you do not need, you now have data you must protect, retain-policy, and eventually delete. Crypto-shredding makes the "eventually delete" step reliable, but it does not excuse unnecessary collection.

The stronger architecture is layered: collect only what the product needs (data minimization), encrypt it per-entity at rest (defense in depth), retain it only as long as it serves the user (retention policy), and destroy the key when it is time (crypto-shredding). Each layer reduces the blast radius of a failure in any other layer.

This connects to our broader privacy-by-architecture approach. Crypto-shredding is one mechanism within that architecture, not the whole thing.

What crypto-shredding does not solve

We should be explicit about the limits.

• Data in model weights. If personal data has been used to fine-tune a model, destroying the encryption key on the training data does not remove the data's influence from the model's parameters. Machine unlearning is an active research problem, not a solved one. Crypto-shredding applies to stored data, not to learned representations.
• Data already exfiltrated. If data was accessed or copied before the key was destroyed—by an authorized user, by an attacker, or by a third-party integration—crypto-shredding does not retroactively protect it.
• Weak encryption. If the encryption algorithm is broken or the key length is insufficient, the ciphertext remains readable regardless of whether the key was destroyed. The guarantee is bounded by cryptographic strength.
• Operational metadata. Non-content operational metadata—timestamps, request counts, error logs—may be retained for a short retention window for system reliability. Crypto-shredding applies to content, not to operational telemetry. We do not claim zero retention.

These are real limits. Stating them does not weaken the value of crypto-shredding; it defines the boundary within which the guarantee holds.

The trajectory: crypto-shredding as table stakes

In 2024, crypto-shredding was a differentiator. By 2026, it is approaching table stakes for any product handling personal data at scale—especially AI products with persistent memory or retrieval layers. The regulatory direction is toward stricter enforcement and independent auditability. The technical direction is toward embedding crypto-shredding into AI memory architectures natively, not retrofitting it.

If you are building a product that remembers things about users, you need a credible answer to "what happens when they want to be forgotten?" That answer should be architectural, not aspirational. Crypto-shredding—with per-entity key isolation, rigorous backup hygiene, and an auditable destruction process—is the most practical answer available today.

Deleted means gone. Actually gone.

If you want to see how this works in practice, start a free 7-day trial—no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io