CRC, hash & Co.

There have been some misconceptions in previous mails.

1.) A CRC is _not_ stronger than a hash. CRC is a subset of the hash domain,
defined as "a fast error-check hash based on mod 2 polynomial operations"
which has typically no crypto strength (and does not need it either for most
purposes).

2.) Theoretically, an optimal MD5 implementation can't be faster than an
optimal CRC-32 implementation. Check it yourself: download openssl
(www.openssl.org) or Peter Gutmans cryptlib where all sorts of hashes and
CRC-32 are implemented in a very reasonable way. Write a tiny routine
generating random strings, popping them through the hash function. You will
see, CRC-32 is typically several times faster.

3.) There are many domains where you need to protect yout database not only
against random accidental glitches, but also against malicious attacks. In
these cases, CRC-32 (and other CRCs without any cryptographic strength) are
no help.
The majority will probably be more happy with fast CRCs, but there will
always be some heavy weight users (such as in medical, legal and financial
domains) where strong hashes are required. Thus, it should be user-definable
at runtime which one to choose.

4.) Without CRC/hash facility, we will have no means of checking our data
integrity at all. At least in my domain (medical) most developers are
craving for database backends where we don't have to re-implement the
integrity checking stuff again and again. If postgres could provide this, it
would be a strong argument in favour of postgres.

5.) As opposed to a previous posting (Bruce ?), MD5 has been shown to be
"crackable" (deliberate collison feasible withavailable technology) - that
was one of the main reasons for the development of RIPEMD-160 (check the
RIPEMD home page for more information)

Once again, I am happy to implement any number of CRC/hash methods in
postgres if anybody (especially theone who implemented the SERIAL data type)
points me into the right direction within the postgres source code. No
takers so far :-(

Horst