Crypto-Shredding

Crypto-shredding is the practice of rendering encrypted data permanently unreadable by destroying the encryption key rather than deleting the data itself. This is Tayra's primary mechanism for fulfilling GDPR Article 17 (Right to Erasure) requests.

Why Crypto-Shredding?

Traditional data deletion in distributed systems is difficult to verify:

• Database records may exist in replicas, backups, caches, and logs
• DELETE statements don't guarantee data is physically erased from disk
• Proving deletion across all storage layers is nearly impossible

Crypto-shredding sidesteps these problems entirely. Once the encryption key is destroyed, the ciphertext remaining in your database is just random bytes — mathematically unrecoverable without the key.

TIP

Crypto-shredding is faster and more verifiable than record deletion. You can prove the key was destroyed without auditing every storage layer where the data might reside.

Single Subject Erasure

To erase all data for a single data subject, delete their encryption key using tayra.ShredAsync(). After deletion, any attempt to decrypt the data will return the configured replacement values instead of the original plaintext.

// Delete the encryption key for a single data subject.
// After deletion, any data encrypted with this key becomes permanently unreadable.
await tayra.ShredAsync("cust-subject-001");

// Decrypting after shredding returns replacement values instead of the original data
await tayra.DecryptAsync(customer);
Console.WriteLine($"Name after shredding: \"{customer.FullName}\"");       // ""
Console.WriteLine($"Email after shredding: \"{customer.Email}\"");          // "redacted@example.com"
Console.WriteLine($"Phone after shredding: \"{customer.PhoneNumber}\"");    // ""

^anchor

The key ID is constructed from the DataSubjectId attribute's Prefix property combined with the subject identifier. For example, with [DataSubjectId(Prefix = "cust-")] and a subject ID of "subject-001", the key ID is "cust-subject-001".

Bulk Erasure

To erase data for multiple subjects at once, use tayra.ShredByPrefixAsync() with a subject prefix. This deletes all keys matching the prefix, affecting all subjects and groups under that prefix.

// Delete all keys matching a subject prefix — bulk crypto-shredding
// across all groups for data subjects matching the prefix.
await tayra.ShredByPrefixAsync("cust-subject-bulk-");

// All data for matching subjects is now permanently unreadable
await tayra.DecryptAsync(customer2);
await tayra.DecryptAsync(customer3);
Console.WriteLine($"Alice after bulk shred: \"{customer2.FullName}\"");  // ""
Console.WriteLine($"Bob after bulk shred: \"{customer3.FullName}\"");    // ""

^anchor

Mask Values

After crypto-shredding, decrypted fields return mask values instead of the original data:

Configuration	Behavior
No MaskValue specified	Empty string "" for string fields
[PersonalData(MaskValue = "redacted@example.com")]	Returns the specified mask value
[PersonalData(Masking = MaskingStrategies.MaskAfter, MaskingParameter = 2)]	Returns a partially masked value (e.g., "El************")

Mask values are deterministic — the same shredded field always returns the same mask value. This prevents downstream systems from breaking on null values while making it clear the data has been erased.

Audit Events

Crypto-shredding operations emit structured audit events for GDPR Art. 30 compliance:

• KeyDeleted — Emitted when DeleteKeyAsync destroys a single key
• BulkKeysDeleted — Emitted when DeleteAllKeysAsync destroys keys by prefix
• CryptoShreddingDetected — Emitted when a decryption attempt finds a missing key and returns replacement values

These events are logged through the ITayraAuditLogger interface and can be persisted to any audit store.

Blind Indexes and Crypto-Shredding

Blind indexes (HMAC hashes) use separate keys from encryption keys. When you crypto-shred a data subject, their encryption key is deleted but the blind index HMAC key remains. The blind index hash is one-way and cannot reveal the original value, but it can still be used to locate the (now-unreadable) record. This is by design — the hash is irreversible and poses no privacy risk.

Best Practices

1. Use meaningful key prefixes — Prefixes like "cust-", "patient-", "emp-" make it easy to identify and manage keys by entity type.

2. Test shredding in staging — Verify that your application handles replacement values gracefully before processing real erasure requests.

3. Log erasure requests — Keep a record of which subjects requested erasure and when, separate from the encrypted data.

4. Consider retention policies — Use the Key Retention background service for automated time-based shredding.

See Also

• Key Rotation — Rotate keys before they need to be shredded
• Key Retention — Automate shredding with TTL policies
• Partial Redaction — Keep partial data visible after shredding
• Data Subject Access — Export data before erasure