3 ms·
Instead of having a key that you delete (and also build non trivial infrastructure to support), why not delete the actual data?
by skj 9y ago
Instead of having a key that you delete (and also build non trivial infrastructure to support), why not delete the actual data?
- Someone 9y agoBecause the key is smaller, it is easier to make sure you deleted every copy of that key than that you deleted every copy of the data. The data also might be part of a larger backup that you would have to take apart and reassemble in order to delete the data, or might be in a place where doing that is costly (e.g. on Amazon Glacier)
- chc 9y agoIt seems precisely as easy to make sure you've deleted every copy of the data as it is to make sure you've encrypted every copy of the data.
- mehrdadn 9y agoEdit: apologies, seems I read way too quickly! Thanks for pointing it out.
- tkxxx7 9y agoYou seem to be commenting out of context: > generate a new encryption key every day for “data deleted today”, The question is not can we encrypt at storage. We’re now talking about encrypting as a soft-deletion method, which means we need to know everywhere the data is stored at deletion time, whether to delete it or to encrypt it with this new “deletion” key.
- qubex 9y agoThanks for raising that issue, I was somewhat confused by the mentioning of encryption as a soft-deletion method... it made precious little sense to me, but everybody seemed to go along with it and I thought I was missing something very fundamentally ’right’ about that idea. Turns out it’s not so.