Unless an attacker can select the field names, in which case they may be
able to improve those odds significantly. In the case of MD5, they can
possibly improve those odds to 1 in 1, since MD5 is vulnerable to
collision attacks. Not so for some (all?) of the SHA hashes, at least not
yet, but they're much more expensive to calculate.
If the OP sticks with his intention to use CRC32, the odds won't be
anywhere near that low. CRC32 is neither collision-resistant nor
cryptographically random, and only generates eight hex digits, not ten.
I'm not affraid of attackers. As I said, nobody will want to "crack" the
hash. This is for an in-house project. Only the dba can create new
database objects. If the dba wants to do something wrong, he can simply
delete whole database. He doesn't need to crack any hash value. :-)
So yes, CRC32 is not collision-resistant, and not cryptographically
random. But in my case, sha256 is not collision resistant either
(because I'm using the first few chars of the digest value only). And
cryptographic randomness is not a requirement.
Given these circumstances, maybe using CRC32 would be fine too.
I wonder what kind of hash Django uses for Oracle.
--
http://mail.python.org/mailman/listinfo/python-list
