4 ms·

you could encrypt every record (with its individual nonce), and do the merkle tree has over the encrypted record. To erase the contents of the record, you just

you could encrypt every record (with its individual nonce), and do the merkle tree has over the encrypted record. To erase the contents of the record, you just have to forget the encryption key. A variation of this trick is used in block devices that offer a fast wipe. Instead of having to fill every block with a bit pattern to wipe the contents, they just have to change the current encryption key. Once that's done the device is effectively filled with random bits.

specialist 6y ago
Exactly. Just like a password wallet. Store the hash of passwords, not the actual passwords. Then disallow password resets. Then you effectively "forget" your account if you lose your password. The book Translucent Databases (2nd ed) [2009] explains clever strategies for applying this technique to protect sensitive data. It's brilliant. https://www.wayner.org/node/39 https://www.wayner.org/node/39 https://www.amazon.com/gp/product/1441421343 https://www.amazon.com/gp/product/1441421343 Meta: I remain disappointed by the obscurity of this book and translucent techniques. A long time friend recently asked me about GDPR compliance and so forth, in prep for reworking stuff to allow proper audits. Very tech savvy. The translucent notions just could not compute. So their efforts went down the conventional rabbit hole of actually deleting data. Which I don't consider practical or auditable. How can you be sure an org deleted every record, log, backup, etc? You can't.
- toolslive 6y ago
  encryption the records. fine, but how do you handle the indexing of the attributes?
  - specialist 6y ago
    I think I understand your question. "Translucent" was coined to describe somewhere between all cleartext (transparent) and all encrypted (opaque). Generally, only sensitive fields are encrypted, so no record level encryption. The cleartext fields can still be searched, indexed. The book shows many clever schemas for mixing and matching hashes, keys, and cleartext. I used translucent strategies for storing patient data. It's pretty straightforward after some experience. Though I admit I didn't have any resources to review, audit our efforts.

specialist 6y ago

Exactly. Just like a password wallet. Store the hash of passwords, not the actual passwords. Then disallow password resets. Then you effectively "forget" your account if you lose your password. The book Translucent Databases (2nd ed) [2009] explains clever strategies for applying this technique to protect sensitive data. It's brilliant. https://www.wayner.org/node/39 https://www.wayner.org/node/39 https://www.amazon.com/gp/product/1441421343 https://www.amazon.com/gp/product/1441421343 Meta: I remain disappointed by the obscurity of this book and translucent techniques. A long time friend recently asked me about GDPR compliance and so forth, in prep for reworking stuff to allow proper audits. Very tech savvy. The translucent notions just could not compute. So their efforts went down the conventional rabbit hole of actually deleting data. Which I don't consider practical or auditable. How can you be sure an org deleted every record, log, backup, etc? You can't.

toolslive 6y ago
encryption the records. fine, but how do you handle the indexing of the attributes?
- specialist 6y ago
  I think I understand your question. "Translucent" was coined to describe somewhere between all cleartext (transparent) and all encrypted (opaque). Generally, only sensitive fields are encrypted, so no record level encryption. The cleartext fields can still be searched, indexed. The book shows many clever schemas for mixing and matching hashes, keys, and cleartext. I used translucent strategies for storing patient data. It's pretty straightforward after some experience. Though I admit I didn't have any resources to review, audit our efforts.