On 10/4/2013 10:23 AM, Phillip Hallam-Baker wrote:
On Fri, Oct 4, 2013 at 12:27 AM, David Johnston <d...@deadhat.com
<mailto:d...@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.
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.
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.
I don't disagree, but it's a tad orthogonal to my argument.
--
Website: http://hallambaker.com/
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography