* Frank Bulk:
For me the MD5 hashes on file downloads are more valuable to ensure the package is accurate to a byte rather than to verify its authenticity or integrity.
Indeed. I've experienced that first-hand: the hashes helped to isolate a case of faulty router memory at the ISP I used at home. (The TCP checksum is very weak and does not detect bit errors which occur at multiples of 16 bits. If the probability of such errors is so high that two of them occur in a single segment, they very likely cancel out, which was exactly what I observed in the issue mentioned above.)
Wouldn't listing both SHA-1 and MD5 hashes for a file download assure almost complete confidence that the file is the original one? I don't think anyone has been able to create a duplicate file that generates the same SHA-1 *and* MD5 hashes as the original file.
For most applications, it's better to include a totally random string at the beginning of the message, before signing it, and strip it upon signature verification (or encode it in a way so that it is simply ignored by the application). The convergent property of hash functions (if, by chance, two people come up independently with the same document, it hashes to the same value) is rarely needed. A random string near the beginning means that the attacker doesn't know the initial internal state of the hash function when the collision is constructed, which should make attacks involving evil twins much, much harder. I expect that at a not too distant point in the future (say, within the next ten years), strong hashes keyed in a such a way offer very significant performance gains over non-keyed, but still strong hashes, so that most protocols which do not rely on the convergence property will switch to them. Convergence might even turn out to be too costly, not just in terms of performance, but in security. (And I write this as a frequent Git user. 8-/)