CRC, hash & Co.
От | Horst Herb |
---|---|
Тема | CRC, hash & Co. |
Дата | |
Msg-id | 011701c0618b$eaba4c00$fcee2bcb@midgard обсуждение исходный текст |
Ответы |
Re: CRC, hash & Co.
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: