Comparing Files: Is it better to use multiple hash algorithms or just one? I'm looking to compare (for byte-for-byte equality) two binary files.

I already have the process down:


Check for existence etc.
Compare file lengths
Use a hash or CRC of a sort (right now I use MD5) to look for an obvious inequality
Finally, byte-for-byte compare them (I have a way of doing this in chunks to speed it up).


Note: the last bullet means I am fully aware of, and prepared for, collisions. I am aware that two identical hashes does not imply equality, but two different hashes confirms inequality.

Here are my thoughts on this so far:


The MD5 function I'm using just takes a file stream and gives me the results. I'm a crypto noob so I don't know much about this algorithm, but if there are random reads and writes (totalling a fraction of the file size) this would likely be much faster than reading in the whole file, or using its ComputeHash(byte[]) overload. That means it would be much faster than reading the file for the byte-for-byte comparison
On the other hand, to make a hash that's based very strongly on the file's contents so that one small change has a good chance of changing the hash, I would think it would need to read a good chunk of the file, so maybe this isn't much faster.
The point with the thoughts above is this: if the hash computations for (weak) comparison are significantly faster than the raw comparison, then it appears it would be worth using multiple different hash algorithms before the raw comparison may be necessary. But is this true?


My particular application: These are small (a few KB) binary files I have a user upload to an app we host on our network. If it's different than our network copy I want to force them to update our network before they can do things with it. However, I don't want to limit my function to this application, but learn how far it may go with others.

Now all I'm wondering is this: Is it better to use multiple hash algorithms to do such a comparison?

Bonus Points: If you think I could be using different algorithms for speed, feel free to recommend.
MD5 is vulnerable to a lot of collision attacks, so if you don't trust the users it is possible for them to make files which hash to the same value as other files but which are not in fact the same.

I think you are misunderstanding how a hash works though.  It does not read bits and pieces of the file, it processes the whole thing into a small output which is a "signature" of that file.  With very, very high probability (if your hash function is good) it is unlikely that two files will create the same hash if they are not, in fact, the same file.  But, it is not by itself any faster than comparing piecewise whether two files are equal.

Where it helps is when you have a bunch of files and you want to check whether a new file is the same as one that you already have.  You can store the individual hashes of the files, and then just check the hash of the new file against all of the existing hashes.  Now instead of manually checking file vs file over and over, you can just compare the small hash values.