Open Stack

Both CBC-AES and XTS-AES are perfectly well supported in modern OS's after
all we're all talking about using AES, only the mode of operation is being
discussed.

 

While it's true that those deploying OpenStack will want to use something
that's OS supported, we should ensure that the most prudent default setting
is set. As a secondary point this is a completely appropriate venue for this
discussion. It's important that as a community we have a discussion about
the use of crypto primitives, algorithms, modes etc.

 

I'm  not an expert on crypt but have worked in this space for a few years, I
think using CBC with suitable IV would provide a similar assurance levels as
XTS, the advantage perhaps with CBC is that one wouldn't need to use such
large key sizes. If memory serves XTS does some peculiar key splitting which
forces the user to use either 256 or 512bit keys.

 

In either case I think the data will probably be sufficiently secure on
disk. When appraising/attacking any modern crypto system I will always go
after the key server first, where would be a good place to read about the
forthcoming 'enhanced key management server' ?

 

From: Bhandaru, Malini K [mailto:malini.k.bhandaru at intel.com] 
Sent: 09 February 2013 00:19
To: OpenStack Development Mailing List
Cc: Benjamin, Bruce P.
Subject: Re: [openstack-dev] Volume Encryption

 

+1 Supporting the  current best set of algorithms.

Malini

 

From: Caitlin Bestler [mailto:caitlin.bestler at nexenta.com] 
Sent: Friday, February 08, 2013 3:13 PM
To: OpenStack Development Mailing List
Cc: Benjamin, Bruce P.
Subject: Re: [openstack-dev] Volume Encryption

 

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/20130211/6e080e95/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6190 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130211/6e080e95/attachment.bin>