<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=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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:0in;
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:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hello Robert!<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">The key splitting in XTS is “minor”, say 256 bit key, top half of key (k1) is used across the whole volume, and the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">bottom half (k2) for creating the per sector “tweaks”. The per sector variant, aka initialization vector, does not need<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">separate storage space because it can be computed from the sector-id and key.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">For a single 128-bit data block P in a sector, the encryption can be described as
<b>C = T </b> <b>AES-ENCRYPT</b></span><b><span style="font-size:6.5pt">k1</span></b><b><span style="font-size:10.0pt">(T
</span></b><span style="font-size:10.0pt"> <b>P)</b>, where <b>T = AES-ENCRYPT</b></span><b><span style="font-size:6.5pt">k2</span></b><b><span style="font-size:10.0pt">(i)* α</span></b><b><span style="font-size:6.5pt">j</span></b><span style="font-size:10.0pt">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt">In this case, i is the address for the sector, j represents the position of the 128-bit block within the sector,
<b>α </b>is a primitive element of the Galois field GF(2</span><span style="font-size:6.5pt">128</span><span style="font-size:10.0pt">) and the multiplication is defined in the same field as described in [1].<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">(Excerpted from : <a href="http://www.intel.com/content/www/us/en/intelligent-systems/embedded-systems-training/ia-high-performance-storage-encryption-paper.html">
http://www.intel.com/content/www/us/en/intelligent-systems/embedded-systems-training/ia-high-performance-storage-encryption-paper.html</a>)<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">So, using is AES-XTS is a good default, the approach JHU-APL has taken.<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">The key length should not be a detraction, the keys can be auto-generated. If a user provided key is short, I can be extended with random bits.<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">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Malini<o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Clark, Robert Graham [mailto:robert.clark@hp.com]
<br>
<b>Sent:</b> Monday, February 11, 2013 2:29 AM<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-GB" 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 lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" 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 lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" 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 lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" 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 lang="EN-GB" style="color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Bhandaru, Malini K [<a href="mailto:malini.k.bhandaru@intel.com">mailto:malini.k.bhandaru@intel.com</a>]
<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"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">+1 Supporting the current best set of algorithms.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Malini<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span 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"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 2/8/2013 1:57 PM, Benjamin, Bruce P. wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Bryan D. Payne wrote:<o:p></o:p></p>
<p class="MsoNormal">> If memory serves me right, XTS has some known issues (in particular<o:p></o:p></p>
<p class="MsoNormal">> data integrity issues and reply attacks). I typically still prefer to<o:p></o:p></p>
<p class="MsoNormal">> use CBC as it is time tested and works nicely if you handle your IV's<o:p></o:p></p>
<p class="MsoNormal">> properly. <o:p></o:p></p>
<p class="MsoNormal"><span style="color:#00B050"> </span><o:p></o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><span 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 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>