<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/11/2013 2:29 AM, Clark, Robert
Graham wrote:<br>
</div>
<blockquote
cite="mid:A0C170085C37664D93EE1604364858A10B3B8B7E@G4W3229.americas.hpqcorp.net"
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:"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]-->
<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>
<br>
</div>
</blockquote>
<br>
As I understand it you are proposing setting a minimal standard for
storage encryption in OpenStack.<br>
<br>
I am not necessarily opposed to that, but I would rather focus on
ensuring that OpenStack's handling<br>
of keys was of sufficiently high quality before limiting what OS
encryption capabilities will be allowed.<br>
<br>
Historically, there has been a tradeoff between affordability and
quality of encryption. About a decade<br>
ago you may recall there was an effort to define "Better Than
Nothing" security in the IETF, based on the<br>
premise that 'inferior' encryption that people would use was better
than 'superior' encryption that would<br>
be turned off.<br>
<br>
That has not been as hot of an issue recently, mostly because
processing makes "expensive" encryption<br>
affordable almost faster than a debate can be resolved.<br>
<br>
That is why I think this is a debate better left to implementers and
OS communities. By the time we<br>
can select what "minimal" encryption needs to be it could well be a
moot discussion.<br>
<br>
The security of encryption is dependent on the speed of an attacking
machine, only communities that<br>
are prepared to stay on top of the latest encryption technologies
should be offering advise to end <br>
consumers on these matters.<br>
<br>
I'd recommend that OpenStack just use the technology that is
available, and specifically avoid endorsing<br>
any of the options.<br>
<br>
</body>
</html>