<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2/8/2013 1:57 PM, Benjamin, Bruce P.
wrote:<br>
</div>
<blockquote
cite="mid:EE1A64E628992240A94E2B625745F01674CBFB05E7@aplesstripe.dom1.jhuapl.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@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]-->
<div class="WordSection1">
<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"><o:p> </o:p></span></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 class="moz-txt-link-freetext" 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 class="moz-txt-link-freetext" 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>
</div>
<br>
</blockquote>
<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.<br>
<br>
</body>
</html>