<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 10/4/2013 10:23 AM, Phillip
Hallam-Baker wrote:<br>
</div>
<blockquote
cite="mid:CAMm+Lwgti+xL41g7zMsUim8434iAWPuW9zsO6Snvkt2OV82gVA@mail.gmail.com"
type="cite">
<div dir="ltr">On Fri, Oct 4, 2013 at 12:27 AM, David Johnston <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:dj@deadhat.com" target="_blank">dj@deadhat.com</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>On 10/1/2013 2:34 AM, Ray Dillinger wrote:<br>
</div>
<blockquote type="cite"> What I don't understand here is
why the process of selecting a standard algorithm for
cryptographic primitives is so highly focused on
speed. ~<br>
</blockquote>
<br>
What makes you think Keccak is faster than the
alternatives that were not selected? My implementations
suggest otherwise.<br>
I thought the main motivation for selecting Keccak was
"Sponge good".<br>
</div>
</blockquote>
<div><br>
</div>
<div>You mean Keccak is spongeworthy.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
It may be, but that wasn't really my argument. My argument was that
algorithm speed cannot have been the primary selection criteria
because Keccak is not the fastest and faster alternatives had a
similar or better security margin in the claims made.<br>
<br>
<blockquote
cite="mid:CAMm+Lwgti+xL41g7zMsUim8434iAWPuW9zsO6Snvkt2OV82gVA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>I do not accept the argument that the computational
work factor should be 'balanced' in the way suggested. </div>
<div><br>
</div>
<div>The security of a system is almost always better
measured by looking at the work factor for breaking an
individual message rather than the probability that two
messages might be generated in circumstances that cancel
each other out.</div>
<div><br>
</div>
<div>Given adequate cryptographic precautions (e.e. random
serial), a certificate authority can still use MD5 with an
acceptable level of security even with the current
attacks. They would be blithering idiots to do so of
course but Flame could have been prevented with certain
precautions. </div>
<div><br>
</div>
<div>If a hash has a 256 bit output I know that I cannot use
it in a database if the number of records approaches
2^128. But that isn't really a concern to me. The reason I
use a 256 bit hash is because I want a significant safety
margin on the pre-image work factor.</div>
<div><br>
</div>
<div>If I was really confident that the 2^128 work factor
really is 2^128 then I would be happy using a 128 bit hash
for most designs. In fact in PRISM-Proof Email I am
currently using a 226 bit Subject Key Identifier because I
can encode that in BASE64 and the result is about the same
length as a PGP fingerprint. But I really do want that
2^256 work factor.</div>
<div><br>
</div>
<div>If Keccak was weakened in the manner proposed I would
probably use the 512 bit version instead and truncate. </div>
</div>
<div><br>
</div>
</div>
</div>
</blockquote>
I don't disagree, but it's a tad orthogonal to my argument.<br>
<blockquote
cite="mid:CAMm+Lwgti+xL41g7zMsUim8434iAWPuW9zsO6Snvkt2OV82gVA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">-- <br>
Website: <a moz-do-not-send="true"
href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div>
</div>
</blockquote>
<br>
</body>
</html>