Open Stack

On 2/8/2013 1:57 PM, Benjamin, Bruce P. wrote:
>
> Bryan D. Payne wrote:
>
> > If memory serves me right, XTS has some known issues (in particular
>
> > data integrity issues and reply attacks).  I typically still prefer to
>
> > use CBC as it is time tested and works nicely if you handle your IV's
>
> > properly.
>
> We understand that CBC has some watermarking issues for storage 
> encryption use.  XTS is a NIST-approved cryptographic standard for 
> this purpose. 
> http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf. You're 
> right that this doesn't provide integrity checks, but the SP800-38E 
> standard states "In the absence of authentication or access control, 
> XTS-AES provides more protection than the other approved 
> confidentiality-only modes against unauthorized manipulation of the 
> encrypted data." Also note that cryptsetup for dm-crypt uses XTS as 
> the default mode now. 
> http://www.spinics.net/lists/dm-crypt/msg04885.html.   The normal 
> usage of XTS would be in an encryption module that would reside 
> directly with the hard drive platter that would be storing the 
> encrypted data.  In our case, though we're sending the data over iSCSI 
> to a remote drive, we believe this encryption mode can still support a 
> reasonably secure solution, assuming that an enhanced key management 
> server (forthcoming) will be implemented.  If the key is kept from 
> compromise, the encrypted data cannot be easily manipulated or 
> substituted in its encrypted form, and it would basically randomly 
> corrupt data within that block.
>
>

I do not see any point in discussing which encryption algorithms will be 
supported in an OpenStack forum.

If a given encryption algorithm is supported by most operating systems 
(translation: Linux) then customers
will expect that option to be available.

And if an encryption algorithm is *not* supported by those same 
algorithms then very few customers would
accept an encryption solution based on software written in python.

So ultimately we are going to accept the determination of the OS vendors 
and chip developers.
There's no point in debating these issues here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130208/7d3487b6/attachment.html>