[openstack-dev] Volume Encryption

Nate Reller rellerreller at yahoo.com
Wed Feb 13 17:46:28 UTC 2013


Our intent was not to limit which encryption algorithms to use or to propose a minimum standard.  We needed to pick a default implementation to use for the Grizzly release.  We did not have enough time to make the algorithm configurable, so we needed to pick a default for the release.

In the future we would like to support many different algorithms and key sizes.  We are imagining the user inputting which algorithm and key size they would like to use via the dashboard.  The administrators of the cloud would be responsible for configuring the dashboard and other components to report which encryption algorithms are available.  This will depend upon their cloud, and the encryption algorithm and key sizes will likely be dictated by the features supported by the compute nodes.

-Nate

> As I understand it you are proposing setting a minimal standard for  
> storage encryption in OpenStack.
> 
> I am not necessarily opposed to that, but I would rather focus on 
> ensuring that OpenStack's handling
> of keys was of sufficiently high quality before limiting what OS 
> encryption capabilities will be allowed.
> 
> Historically, there has been a tradeoff between affordability and  
> quality of encryption. About a decade
> ago you may recall there was an effort to define "Better Than Nothing" 
> security in the IETF, based on the
> premise that 'inferior' encryption that people would use was better than 
> 'superior' encryption that would
> be turned off. 
> 
> That has not been as hot of an issue recently, mostly because processing 
> makes "expensive" encryption
> affordable almost faster than a debate can be resolved.
> 
> That is why I think this is a debate better left to implementers and OS 
> communities. By the time we
> can select what "minimal" encryption needs to be it could well be a moot 
> discussion.
> 
> The security of encryption is dependent on the speed of an attacking 
> machine, only communities that 
> are prepared to stay on top of the latest encryption technologies should 
> be offering advise to end
> consumers on these matters.
> 
> I'd recommend that OpenStack just use the technology that is available, 
> and specifically avoid endorsing
> any of the options.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130213/a966654a/attachment.html>


More information about the OpenStack-dev mailing list