Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

General

Always check the MD5 hashes of the .NET Framework assemblies to prevent the possibility of rootkits in the framework. Altered assemblies are possible and simple to produce. Checking the MD5 hashes will prevent using altered assemblies on a server or client machine.

Source: https://www.owasp.org/index.php/.NET_Security_Cheat_Sheet

Isn't MD5 completely broken for this purpose?

share|improve this question

3 Answers 3

The MD5 hash algorithm has been demonstrated to be weak to collision attacks. This means that an attacker can generate two files which will produce the same hash value. This has no bearing on file integrity checks.

To create a file that matches a previously known hash, the algorithm has to be weak against second preimage attacks. While MD5 has some theoretical weaknesses in this aspect, the current attacks are still not computationally feasible.

Of course, new attacks might surface in the future. MD5 has been demonstrated to have several glaring weaknesses. Try to use a hash function like SHA256 instead.

share|improve this answer
    
If we're looking for a way to prove integrity in secure way, a better way is a PGP signature. –  Polynomial Apr 17 '13 at 14:33
    
Technically a second preimage attack, since the attacker also has the genuine file to start with. This is not exactly the same thing as a preimage attack (but close enough). –  Tom Leek Apr 17 '13 at 14:39
    
@TomLeek Roger, made the edits. –  Terry Chia Apr 17 '13 at 14:42
    
@ Polynomial that proves integrity and authenticity. it's preferable if both are a goal. –  Nick P Apr 18 '13 at 0:19

To complete @Terry's answer: MD5 is thoroughly broken for collisions, but only very slightly weakened for preimages and second preimages. Best known attack has cost 2123.4 (see the article), which is stupendously infeasible with existing technology, but, from an academic point of view, somewhat better than the expected 2127 resistance that a perfect hash function with a 128-bit output should offer.

SHA-256 is the current "default hash function" which you should use for anything which requires a hash function, unless some specific context characteristics warrant another function. However, replacing MD5 for integrity checks is not a critical emergency; no need to get all worried on it.

While MD5 is still fine for the purpose of integrity check, you must realize that this only translates the issue: you still have to make sure that you use the correct hash value. For instance, make sure that you get the hash value from an HTTPS Web site (from a reputable server). Hash values are small enough to allow for some extra mechanisms: you can write them down on paper or dictate them by phone, for instance, which you could not do with a 3 GB archive.

share|improve this answer

The other two answers are right about MD5 being safe for file integrity. The point I diverge on is that you shouldn't necessarily use SHA-256 by default. Crypto choice is about tradeoffs. After integrity, performance is my biggest concern with hash functions for checking files. I've seen MD5 hash four times faster than SHA-256. A list of resulting hashes also takes up half the space with MD5, which might help in memory limited systems.

So, MD5 is secure for this area of application and is anywhere from a little to several times faster. So, I'd use it.

Note: I have substituted HAVAL for MD5 in the past b/c it's fast, too. SHA-3 competition is also done so we have more to profile for performance and maybe replace MD5 in the near future for high performance hashing. Also, the VIA Padlock Engine accelerates SHA-256 so I use it on such a platform. Lots of things to consider, but I always say focus on endpoint, network and app security b/c crypto is usually the strongest link.

share|improve this answer
    
can't we concatenate SHA-256's output to 128 bits if needed? –  H M Apr 19 '13 at 5:43
    
We can. However, this could affect the security properties of the resultant hash. Uniqueness would be my main concern. Cryptographers in the past have warned me against customizing crypto algorithms and being clever with them. So, the non-clever solution was using a compact, superfast, well-understood algorithm that will survive this use case, if not others. –  Nick P Apr 19 '13 at 7:17
    
don't u think truncating SHA-256 output is nevertheless more secure than using an older and broken algorithm? –  H M Apr 24 '13 at 20:03
1  
Short answer: no. Long answer: we can't believe any construction is secure unless its been analysed and proven over time. A specific, truncated SHA-256 output? Hopefully secure, but no proof. MD5 for 2nd preimage attacks? Decent in theory and proven in 20+ years field use. MD5's speed and digest size trumps SHA256. I mean, an opponent good enough to second preimage MD5 in coming years could penetrate your system in dozens of easier ways. That's my whole point. Certain crypto issues get more focus than they deserve. –  Nick P Apr 28 '13 at 5:19
    
Maybe MD5(SHA256(data)) is a good compromise between security and storage space; but of course has no performance benefits (somewhat slower than SHA256). –  H M Apr 28 '13 at 5:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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