View Full Version : MD5 versus CRC32
Isn't it about time BC introduces the use of MD5 message digest (hashes) for file checksum comparisons, as CRC/CRC32 is documented to give false results in some situations? I have heard of people copying data to CD and CRC saying the copy is the same, wheras MD5 notices they aren't. Lots of apps now use MD5 over CRC/CRC32, because unlike CRC, it is thought computationally infeasible to have two sources producing the same MD5 message digest hash. Perhaps this could be added as an "Action" option in the "Compare Contents" dialog? BTW freeware MD5 libraries are already available for use!
01-Sep-2005, 09:10 AM
We are considering adding MD5 support in a future version, but it's a low priority, and I don't think it will be as useful as you're hoping.
If you're checking a just-burned CD or file copy you should just use the binary comparison. It does a byte-by-byte check on the two files, so it doesn't even have the miniscule chance of collision that MD5 has. The speed should be about the same. When it comes to disk-to-disk comparisons the only time I've seen a hash comparison significantly outperform binary comparisons was for large files on the same physical drive, where seeking back and forth between the files became an issue.
CRC32 comparisons are most useful when comparing against zip files and snapshots, which both have CRCs already calculated for one side, and FTP sites that support the XCRC command. While there are XMD5 and XSHA FTP commands they're not well supported yet.
02-Oct-2007, 10:08 AM
I would also like to request MD5 hashes. My use is in snapshots where I want to be a bit more sure that the files haven't changed than the CRC32 provides. (Some of our software build processes here do some funky stuff where they actually tweak a few bytes in a file to produce a particular CRC32, for better or for worse. :( )
08-Oct-2007, 11:41 AM
The previous post still applies to this issue. With bc version 3 in full development swing, this is still on the list of for 'future' development, with no firm date.
If you would like, email support your specific build issues, and we can try to work out an alternate solution (perhaps instead of using snapshots for all previous verisons, use a copy of the files one history step back, for a binary compare, then the crc based snapshots for history further back?)
For fast comparison use CRC.
For bit-exact comparison use Binary comparison.
Note: There is still a very very low possibilities that different content gives same MD5 hash. So nothing beat binary comparison.
vBulletin® v3.7.1, Copyright ©2000-2013, Jelsoft Enterprises Ltd.