Many sites these days offer MD5 and SHA256 hashes to check the integrity of downloaded files or archives.
I wonder how much safer is the use of the SHA256 hashes for integrity checks?
Note: Consider the file content as random input (no attacks)
Note: Seems to be a simple question (and I read about collisions on wikipedia), yet I have not found an answer on this site
I wonder how much safer is the use of the SHA256 hashes for integrity checks?
Note: Consider the file content as random input (no attacks)
Based on your note of "no attacks" it seems to me that you are asking:
"What is the probability that a random change (e.g., bit flip during download) to a file will result in creating a new/different file with the same checksum as the original file?"
For the case of MD5, this probability is: 1/(2128) = 2.94e-39 = 0.00000000000000000000000000000000000000294
For the case of SHA256, this probability is: 1/(2256) = 8.64e-78 = 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000864
Important Caveats: (1) In the above-mentioned hypothetical case of random changes, both MD5 and SHA256 are fine choices. However, in real life, the MD5 hash function is frowned upon because it has been broken (collisions have been found). So, consider using SHA256 rather than MD5 for file integrity; (2) I am assuming that MD5 and SHA256 provide uniform random output, which is not really true.
Update based on comments: I'm referring to MD5 as "broken" to mean (basically) that collisions have been found. One of the main conjectured properties of MD5 was "that it is computationally infeasible to produce two messages having the same message digest..." (RFC 1321) Because it is possible to violate this property, I've called MD5 "broken," which is perhaps a little harsh. I still see MD5 used all the time, and I still use it myself all the time. It is fine to use MD5 in certain circumstances, especially when there is no other option.
There seems to be some confusion about the capabilities of a collision attack.
Two of the properties a cryptographic hash must have are collision resistance and preimage resistance.
If a hash is collision resistant, it means that an attacker will be unable to find any two inputs that result in the same output. If a hash is preimage resistant, it means an attacker will be unable to find an input that has a specific output. MD5 has been vulnerable to collisions for a great while now, but it is still preimage resistant.
If you trust that the party that originally hashed the data to provide you with the integrity check is not malicious, and they did not allow anyone to modify the data beforehand (any part of the data, even if 2 images, videos, or pdfs look identical they can be vastly different), then MD5 should be sufficient to verify integrity, and SHA-256 shouldn't offer much more security (barring any future attacks on MD5's preimage resistance).
If an attacker may have been able to make any modifications to the data (even seemingly benign modifications), then SHA-256 will be more secure, as with MD5 the attacker could have crafted a malicious file with the same hash.
In many cases, not really. If you're downloading the file over HTTPS from the same website providing the hash value, then you're already benefiting from the MAC TLS uses for authenticity checking, so a MitM will be unable to change the file in-transit. If someone is able to modify the file on the site maliciously, they can also modify the hash.
One case where it does make sense to verify an MD5 or SHA-256 hash for a file is if you download the file from a mirror and check the hash against one provided by the original trusted site.
MD5 creates an 128-bit hash, whereas SHA256 creates a 256-bit hash.
You could say that SHA256 is "twice as secure" as MD5, but really the chance of a random collision is negligible with either. I would say MD5 provides sufficient integrity protection.
There are attacks to create MD5 collisions on purpose, but the chance of finding a collision on accident is still determined by the size of the hash, so is approximately 2/2128.
There are currently no two distinct files in the world that have the same SHA256 hash. There are distinct files that have the same MD5 hash, but only because they have been purposely so created.
Both MD5 and SHA256 resist a preimage attack, nowadays.
This means that it would be near to impossible for someone to replace the file with a different one with the same {MD5|SHA256} hash.
However, you should note
So, if you have to make a decision between using MD5 and SHA256, go for SHA256.
MD5 collision vulnerabilities exist and it's feasible to intentionally generate 2 files with identical MD5 sums.
No SHA256 collisions are known, and unless a serious weakness exists in the algorithm, it's extremely unlikely one will be found.
For verifying a file was not accidentally corrupted, MD5 is probably sufficient. If it's possible it was intentionally altered, MD5 isn't safe and you should stick with SHA256.
If you exclude malice or other intentional/MD5 aware behaviour, MD5 is really is fine.
There is of course a chance of accidental collision of MD5 and SHA256 the odds of the SHA256 are a lot lower. However for some context: the odds of an accidental collision on MD5 is far lower that the chances that the check flag get accidentally flipped by a comsic ray, to make it look like like the hashes where the same when they weren't see here, with some caveats.
If you are interested in non-random inputs (like malice), SHA256 might be a better choice, but it depends what you think the attacker could control.
If you're just interested in making sure the system is accident proof, there are better places to spend your time than which hashing algorithm you use.
Chosen-prefix collision attacks on md5 are fairly easy to pull off. This is an attack where the attacker can choose two arbitrary files, then append different calculated bytes to each, so that both files produce the same md5 hash.
In 2012, the authors of the Flame malware took advantage of this attack to make it appear as if the malware was signed by a legitimate Microsoft code signing certificate. The certificate had been used to sign a legitimate file, where the signature was done over the (weaK) md5 hash of the file. The authors of the Flame malware used a chosen-prefix attack to make their malware file produce the same md5 hash as the legitimate file, thus making it appear as if the malware file was signed by the Microsoft certificate. For more info, see https://en.wikipedia.org/wiki/Flame_%28malware%29#Operation.
There have been no known attacks of this kind on SHA256.
