MD5 Discussion

Ah the whole MD5 vs SHA-1 collision debate.
RSA Laboratories

I doubt there are many people anywhere that could pinpoint a collision in the incredibly rare instance where they may occur. I guess that is why Logicube, AccessData, etc. also include SHA. Perhaps on the better safe than sorry theory?

Bit,

You may have missed the point or I may have not been clear.

The MD5 hash was not taken because if the hashes didn't match for some reason he could not pinpoint why they didn't match.

That seems a bit of dangerous path - where you stop doing things in the examination because if they don't go how you expect you're afraid of being attacked in the court-room.

Surely a counter-argument could be made that if an examiner has not carried out an MD5 check of the acquisition hash then his work is flawed/incompetent as he has not followed industry best practice in his examination?

The hashes do not always match but it's not the end of the world; I would make sure the drive was re-imaged using a different method and if they still don't match then this is put in the contemporaneous case notes - and I then get on with the rest of my exam.

All artifacts that are produced as evidence will also have full provenance provided i.e.; full path location, file offset, and MD5 hash of the artifact in question allowing any other examiner to reproduce what I found.

"…his company does NOT do an MD5 of the entire drive or image because if for some reason the hashes did not match, then you can't explain the precise point and reason why they didn't."

I have to agree with Jonathan on this point. Not doing something because an issue *may* arise where you aren't able to explain the reason for the anomoly certainly doesn't sound like sound reasoning to me. The problem with this slippery slope is that not only will it call the incident into question, but it will also call the entire process and any case that was subject to that process into question.

It sounds to me that perhaps (and please notice that I say "perhaps") the reason for this decision is that the company is hiring individuals that aren't sufficiently experienced or trained to address such situations, should they occur. A better approach would be to address those situations in the process, rather than ignoring that entire section of the process.

From my own experience, I haven't had a situation where the hashes (MD5 and SHA-1) haven't matched. This includes not only imaging extracted hard drives, but also live acquisitions, as well as walking others through the process of a live acquisition. However, had I had such a situation, I certainly would have attempted to address the situation, not pretend it didn't exist.

H

BitHead,

Thanks for the link, but I think that at best, it clouds the issue. The MD5 collisions produced by the Chinese team were specifically crafted, and of fixed size.

Now, looking at the algorithms for both MD5 and SHA-1 hashes, in that they take a variable length input and produce a fixed-length output, it is mathematically improbable, although not impossible, that there will be collisions. However small, there is a likelihood.

However, in the real world, what is the potential that two executables files of arbitrary length will have the same MD5 hash? What is the potential that a single executable file can be modified and produce the same MD5 hash as the original, and still be a functioning EXE?

Harlan

H,
My point exactly. The collisions have only been demonstrated in a controlled environment specifically crafted to cause the abnormality. The probability of an issue when you calculate both an MD5 and a SHA-1 is even more unlikely.

Not calculating any hash values puts you further down the slippery slope of doubt, which is what we are all trying to avoid, yes? And is part of the reason everything we do is logged, categorized, confirmed, notated, photographed, . . . so that when there is an unlikely issue it can be recreated by another person or team following our methodology and procedures.

However, in the real world, what is the potential that two executables files of arbitrary length will have the same MD5 hash? What is the potential that a single executable file can be modified and produce the same MD5 hash as the original, and still be a functioning EXE?

While we sure aren't there yet, eventually we will be able to. They will always be obvious because the last of the file will contain the bytes used to twiddle the hash to match.

Of course, as BitHead indicates even if you could get md5 to match, the sha1 won't.

"While we sure aren't there yet, eventually we will be able to. They will always be obvious because the last of the file will contain the bytes used to twiddle the hash to match."

Do you really think so? Do you really think that someone is going to be take, say, svchost.exe and "trojan" it so that it includes a different functionality, but now has the same size and MD5 hash as the original?

Twiddling bits at the end of a file is of no use to an attacker who wants to Trojan the file and use it as a backdoor.

Harlan

Yes, I do think we'll be able to. And I don't really think extra bits at the end will affect functionality as program entry points are fixed and I know of no architecture where it's at the end. It would be unexecuted junk. Now, will they get the same size? Not with the same functionality.