4 ms·

I saw the Akka people talking about this on twitter once, I think they were theorizing that encrypting the data in the log would be sufficient, because then "de

I saw the Akka people talking about this on twitter once, I think they were theorizing that encrypting the data in the log would be sufficient, because then "deleting the key" could be interpreted as the deletion of the record (even though the useless data still exists in the log). But I'm not sure this was ever legally validated?

guywhocodes 7y ago
That is a very interesting approach, however I can imagine that it can be quite a large database of encryption keys. I'll have to build a small system for this and try it.
- imglorp 7y ago
  Oh, why? Holding one key for every human on earth would fit in 8 TB plus read-mostly replicas. You'd delete their key if they made GDPR removal request and the keyless, encrypted, immutable entries would be entombed in place.
  - pookeh 7y ago
    What do you do when the data involves multiple people?
    - shrimpx 7y ago
      It's unclear (regardless of crypto shredding) what the delete policy should be if the data involves multiple people.
    - randolorian 7y ago
      Why would it? Typically you would have one stream per user.
      - tunesmith 7y ago
        Event: "User A sent Message X to User B". (I think the answer here is again to have PII be in other repositories, and only refer to them by id in the log.)
    - specialist 7y ago
      Good question. Create alias proxies?
xtagon 7y ago
That is what I was referring to as "crypto-erasure" (also known as "crypto-shredding"). I'm not sure what counts as legally validated, but some have shared concerns that the encryption you use to do this would need to be future-proof against, say, advancements in quantum computing cracking the encryption down the road even after the key has been thrown out.
- rodocite 7y ago
  if the references don't point to actual data, you don't need this. - minimum 2 parts. a relay (reference hash) and the cold/true storage portion. you can break the reference hash up and reassemble only for secret holders. which brings us to: - content-based routing - there are also deterministic vaults for rolling keys i'm actually not sure in what high-level situation "crypto-erasure" would work in because being able to re-key a reference means you have complete control. so why would you need to erase the "bad" key when you can just switch the reference? Eth draft for enabling cold storage relay https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1077.md https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1077.m... Decentralized ID https://www.w3.org/TR/did-core/ https://www.w3.org/TR/did-core/ ^ both generally use the same concept i described above and solve GDPR "delete" issue. actually, it solves GDPR completely if you can just rely on the DID. "hard delete" is a separate issue, though-- no other way to get around that but to fork/version + replay your store and re-reference anyone who wants to hard delete if you didn't use reference hashes.
specialist 7y ago
Just like password stores. Store salted and hashed password value, vs actual password. Cleverly applying this strategy to all sensitive datas is the Translucent Database thesis.

guywhocodes 7y ago

That is a very interesting approach, however I can imagine that it can be quite a large database of encryption keys. I'll have to build a small system for this and try it.

imglorp 7y ago
Oh, why? Holding one key for every human on earth would fit in 8 TB plus read-mostly replicas. You'd delete their key if they made GDPR removal request and the keyless, encrypted, immutable entries would be entombed in place.
- pookeh 7y ago
  What do you do when the data involves multiple people?
  - shrimpx 7y ago
    It's unclear (regardless of crypto shredding) what the delete policy should be if the data involves multiple people.
  - randolorian 7y ago
    Why would it? Typically you would have one stream per user.
    - tunesmith 7y ago
      Event: "User A sent Message X to User B". (I think the answer here is again to have PII be in other repositories, and only refer to them by id in the log.)
  - specialist 7y ago
    Good question. Create alias proxies?

xtagon 7y ago

That is what I was referring to as "crypto-erasure" (also known as "crypto-shredding"). I'm not sure what counts as legally validated, but some have shared concerns that the encryption you use to do this would need to be future-proof against, say, advancements in quantum computing cracking the encryption down the road even after the key has been thrown out.

rodocite 7y ago
if the references don't point to actual data, you don't need this. - minimum 2 parts. a relay (reference hash) and the cold/true storage portion. you can break the reference hash up and reassemble only for secret holders. which brings us to: - content-based routing - there are also deterministic vaults for rolling keys i'm actually not sure in what high-level situation "crypto-erasure" would work in because being able to re-key a reference means you have complete control. so why would you need to erase the "bad" key when you can just switch the reference? Eth draft for enabling cold storage relay https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1077.md https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1077.m... Decentralized ID https://www.w3.org/TR/did-core/ https://www.w3.org/TR/did-core/ ^ both generally use the same concept i described above and solve GDPR "delete" issue. actually, it solves GDPR completely if you can just rely on the DID. "hard delete" is a separate issue, though-- no other way to get around that but to fork/version + replay your store and re-reference anyone who wants to hard delete if you didn't use reference hashes.

specialist 7y ago

Just like password stores. Store salted and hashed password value, vs actual password. Cleverly applying this strategy to all sensitive datas is the Translucent Database thesis.