[147511] in cryptography@c2.net mail archive
Re: [Cryptography] Sha3
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Sat Oct 5 10:43:31 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <524E43C3.9000506@deadhat.com>
Date: Fri, 4 Oct 2013 13:23:12 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: David Johnston <dj@deadhat.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============0244035844166740292==
Content-Type: multipart/alternative; boundary=089e013d203099fd8f04e7ed8e59
--089e013d203099fd8f04e7ed8e59
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 4, 2013 at 12:27 AM, David Johnston <dj@deadhat.com> wrote:
> On 10/1/2013 2:34 AM, Ray Dillinger wrote:
>
> What I don't understand here is why the process of selecting a standard
> algorithm for cryptographic primitives is so highly focused on speed. ~
>
>
> What makes you think Keccak is faster than the alternatives that were not
> selected? My implementations suggest otherwise.
> I thought the main motivation for selecting Keccak was "Sponge good".
>
You mean Keccak is spongeworthy.
I do not accept the argument that the computational work factor should be
'balanced' in the way suggested.
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.
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.
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.
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.
If Keccak was weakened in the manner proposed I would probably use the 512
bit version instead and truncate.
--
Website: http://hallambaker.com/
--089e013d203099fd8f04e7ed8e59
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Oct 4, 2013 at 12:27 AM, David Johnston <span dir=
=3D"ltr"><<a href=3D"mailto:dj@deadhat.com" target=3D"_blank">dj@deadhat=
.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 10/1/2013 2:34 AM, Ray Dillinger
wrote:<br>
</div>
<blockquote type=3D"cite">
=20
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 i=
s spongeworthy.</div><div><br></div><div><br></div><div>I do not accept the=
argument that the computational work factor should be 'balanced' i=
n the way suggested.=A0</div>
<div><br></div><div>The security of a system is almost always better measur=
ed 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 s=
erial), 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 precaut=
ions.=A0</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&#=
39;t really a concern to me. The reason I use a 256 bit hash is because I w=
ant 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 re=
ally 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 Ide=
ntifier because I can encode that in BASE64 and the result is about the sam=
e 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 p=
robably use the 512 bit version instead and truncate.=A0</div></div><div><b=
r></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallamba=
ker.com/</a><br>
</div></div>
--089e013d203099fd8f04e7ed8e59--
--===============0244035844166740292==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============0244035844166740292==--
