My question is if different files always lead to different MD5 or SHA1 hash codes?

  • well, that's the whole point of a hash function, edge cases aside... – dandavis Oct 3 '18 at 16:25

@PeterHarmann's answer is entirely correct, but to add to it: Secure hash algorithms (which MD5 was intended to be, and which is literally what "SHA" stands for) are supposed to be highly resistant to collisions where any two inputs have the same output. While such collisions will always exist for any algorithm that can take a longer (in terms of arbitrary bits of data) input than its output, finding them is supposed to be near-impossible. Ideally, doing so requires a brute-force attack on an infeasibly large search space, even when utilizing a birthday attack. In other words, while it's true that different files cannot always have different hash digests, in practice it's supposed to be possible to act as though they do.

SHA1 is deprecated because it has been demonstrated to be vulnerable to a collision attack, as Peter's link shows. MD5 is even worse, though; it has been demonstrated to be vulnerable to a chosen-prefix collision attack, where two distinct inputs can have suffixes appended to cause them to have the same hash digest. This was demonstrated as a way to break the protections afforded by cryptographic signatures (one of the key uses of secure hashes) by creating colliding X.509 certificates, allowing an attacker to generate a fraudulent certificate (with their own public key) that has the same hash and therefore the same signature as a valid certificate signed by a trusted certificate authority. The Flame malware used a fraudulent certificate purportedly signed by Microsoft, which was possible because Microsoft had a CA that was still issuing MD5-signed certificates.


No they don't. If you think about it, sha1 output has 160 bits. There are more than 2^160 possible files, therefore there must be multiple (infinitely many) potential files that have the same hashes. The problem is finding them.

Here are two files that have the same sha1.

  • aside from those two files, how often does sha1 collide? – dandavis Oct 3 '18 at 16:24
  • 1
    @dandavis if you are not actively looking for a collision, to a single file then about once in 2^160 ~10^48. So a number with 48 zeroes. You will pretty much never find a collision by accident. Or 10^24 if you compare every one with every one. So one collision in one hexalion files? Is it hexalion? – Peter Harmann Oct 3 '18 at 19:18
  • There are not infinitely many possible input files. There are "only" 2^(2^64-1) possible inputs, since the maximum length of an input is 2^64-1 due to the length encoding in the Merkle–Damgård padding. – forest Oct 24 '18 at 2:57

Theoretically they don't, and this is known as the "Pigeonhole principle". However, the probability to have 2 identical hashes is very small. The Pigeonhole principle for hashes in brief:

  • A hash has a specific bit length, say a. For SHA256, a=256.
  • As a result, there can be 2^a unique hash values. For SHA256, this is 2^256 (2 raised to 256) unique hash values.
  • If the file size is b bits, then we can have 2^b unique files.
  • The size of a file is much greater than a (otherwise we wouldnt need hashes). This can only happen if different files map to the same hash.

However, it is highly difficult for somebody to produce a second file having the same hash. This is because of the hashing algorithm properties.


Not always. Addition to the previous well explaining answers, Google has an announcement for the collision for SHA-1 algorithm: (Google) Announcing the first SHA1 collision .

Moreover, MD5 collision has been announced in 2004 referring from Cryptosense.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.