Re: New hash contest by NIST, similair to AES competition

Jean-Luc Cooke <jlcooke@xxxxxxxxxx> writes:

Like Paul said in a post. Speed is important. But the range of speeds
where a hash's performance is acceptable is far larger than most people
realize.

Acceptable to whom? MD5 is SLOWWWWW if you are hashing a 10GB file to see
if it has changed.

It it enough that it goes 1000x faster than the fastest HD today? 100x?
10x?

Performance is an important goal, not as important as security.

Depends. I am sure that I could design a totally secure hash which goes at
10 bytes per second. And I guarentee that noone will ever use it.



As if you've watched the rate of growth of CPU Speed vs Disk/Network/IO
Speed you'll notice that CPU's have *way* out-run IO speeds and will
continue to do so. I'm not talking about desktop PCs specifically.
The mobile phone in my pocket has a more powerfull CPU than a any
desktop PC from 10 years ago.

I'd say a computationally expentive hash is permittable into the 100
cycle/byte range.

JLC

Thomas Pornin <pornin@xxxxxxxxx> wrote:
According to Jean-Luc Cooke <jlcooke@xxxxxxxxxx>:
Other than that 1 beef, Whirlpool is my choice.

It's quite slow, however. NESSIE clocked the reference implementation
at 113 cycles per input byte on Pentium III, which is very slow.
Performance can probably be improved to some great extent, but I doubt
it will come below, say, 50 clock cycles per input byte. By comparison,
on the same hardware, MD4 is below 5 clock cycles, SHA-1 achieves about
10, and, more to the point, AES encryption can run below 20 cycles per
byte. It is not usual for the hash part of a encrypt-and-MAC system to
be the bottleneck.


--Thomas Pornin

--
.