<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>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’ ?<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Bhandaru, Malini K [mailto:malini.k.bhandaru@intel.com] <br><b>Sent:</b> 09 February 2013 00:19<br><b>To:</b> OpenStack Development Mailing List<br><b>Cc:</b> Benjamin, Bruce P.<br><b>Subject:</b> Re: [openstack-dev] Volume Encryption<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'>+1 Supporting the current best set of algorithms.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'>Malini<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Caitlin Bestler [<a href="mailto:caitlin.bestler@nexenta.com">mailto:caitlin.bestler@nexenta.com</a>] <br><b>Sent:</b> Friday, February 08, 2013 3:13 PM<br><b>To:</b> OpenStack Development Mailing List<br><b>Cc:</b> Benjamin, Bruce P.<br><b>Subject:</b> Re: [openstack-dev] Volume Encryption<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>On 2/8/2013 1:57 PM, Benjamin, Bruce P. wrote:<o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US>Bryan D. Payne wrote:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>> If memory serves me right, XTS has some known issues (in particular<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>> data integrity issues and reply attacks). I typically still prefer to<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>> use CBC as it is time tested and works nicely if you handle your IV's<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>> properly. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:#00B050'> </span><span lang=EN-US><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>We understand that CBC has some watermarking issues for storage encryption use. XTS is a NIST-approved cryptographic standard for this purpose. <a href="http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf">http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf</a>. 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. <a href="http://www.spinics.net/lists/dm-crypt/msg04885.html">http://www.spinics.net/lists/dm-crypt/msg04885.html</a>. 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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p> </o:p></span></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman","serif"'><br>I do not see any point in discussing which encryption algorithms will be supported in an OpenStack forum.<br><br>If a given encryption algorithm is supported by most operating systems (translation: Linux) then customers<br>will expect that option to be available.<br><br>And if an encryption algorithm is *not* supported by those same algorithms then very few customers would<br>accept an encryption solution based on software written in python.<br><br>So ultimately we are going to accept the determination of the OS vendors and chip developers.<br>There's no point in debating these issues here.<o:p></o:p></span></p></div></div></body></html>