Open Stack

Yeah, but the thing about encryption is, by nature, it isn't exactly secure. Its all based on probability:
* Use a big enough set of numbers that its unlikely someone would guess or unlikely that enough compute power could be brought to bare to brute force guess it.
* Try and use an algorithm that is cryptographically strong and has not bugs.

Naturally though, the longer an encrypted pice of information exists, the more likely one of those things won't hold true any more and the "secureness" of the data is defeated. To be "more secure" then, you should erase the data from existence, shortening the existence window.

Some encrypted data that was made 20 years ago s readable now. Who knows what would happen to an excessed disk that gets onto ebay and held onto for a while. Its unlikely, but something someone interested in clearing the volume may care about randomizing or zeroing the data on delete and paying additional fee for, rather then leaving it on disk and returning zero's.

Just random thoughts.

Kevin

________________________________________
From: Chris Friesen [chris.friesen at windriver.com]
Sent: Wednesday, January 15, 2014 4:21 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

On 01/15/2014 06:00 PM, Fox, Kevin M wrote:
> What about a configuration option on the volume for delete type? I can see some possible options:
>
> * None - Don't clear on delete. Its junk data for testing and I don't want to wait.
> * Zero - Return zero's from subsequent reads either by zeroing on delete, or by faking zero reads initially.
> * Random - Write random to disk.
> * Multipass - Clear out the space in the most secure mode configured. Multiple passes and such.

Interesting idea, but for the "None" case I'd include the possibility
that the user will be encrypting their data.

Also, I don't see any point for random or multipass given that anyone
that really cares about it isn't going to trust their unencrypted data
to someone else anyways.

Lastly, the "zero on delete" case could conceivably end up costing more
since the provider could continue to bill for the volume while it is
being deleted.

Chris

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev