[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: CRC -> MD5

Hallvard B Furuseth wrote:

Howard Chu writes:

Basically all of these crypto hash functions are overkill, in terms of
hash size and computation. We're only looking to detect casual misuse
or corruption, not malicious deception.


Yes.  The main reason I see to use either CRC or MD5 is that they are
likely to be installed somewhere so non-programmers can use them.  We
could use a faster hash like MurmurHash3, but would then need to provide
a 'slaputil hash' command or something for use by shell programs.


Right. The fewer custom utilities involved the better.


I didn't really spend a lot of time comparing the two functions'
speed. But even with the memory access bottleneck, I would guess that
on a loaded system with many threads running, the algorithm with fewer
instructions is the better choice. Have you measured the throughput
when multiple threads are executing?


On my 32-bit host, MD5 on a threaded test program had 90-95% of CRC's
throughput instead of 105% or whatever it was unthreaded.  OTOH crc32()
from linking -lz gave ~275%.  OTOH I'd expect MD5 to be more costly on
an older or cheaper machine where the which hasn't outpaced memory speed
as much as modern workhorses.


Sounds to me like we should just use zlib's crc32 code then.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/