Or, use SHA-256 and MD5, move on.
As seanmcl said, moves it off the table.
My point is that there is no need to do both if sha256 works (or you are happy with explaining away the flaws in MD5) then one is enough.
sure that I am compatible with whatever hashing system they might rely upon.
The backward comaptibility argument is flawed as well. If I have a SHA1 hash of an image and someone wants to see an MD5 then I can take one at the time. The SHA1 verifies to me that my image is OK - if the other side want to verify using sha256, md5, md2, whirlpool, or CRC32 then it is up to them to do that - I cma certainly not going to take a second hash just because they *might* want to rely on someting else.
If (insert your favourite hash algorithm here) is good enough, then it is good enough - you dont need a second, its a waste of time and processor cycles.
[quote="sandy771]My point is that there is no need to do both if sha256 works (or you are happy with explaining away the flaws in MD5) then one is enough.
[i][b]Need[/b][/i] is your word, not mine. If you don't want to do both then don't but I'm not sure how you can say that someone errs by doing both (or all).
[quote="sandy771]
The backward comaptibility argument is flawed as well. …
If (insert your favourite hash algorithm here) is good enough, then it is good enough - you dont need a second, its a waste of time and processor cycles.
Again, that is a matter of your preference. Cycles are cheap and I don't see an appreciable difference in time when I choose both as opposed to one, at least using the tools that I use.
On the other hand, I have seen considerable expert and attorney time spent arguing about trivialities that could have been avoided by taking one extra step. I take that into consideration, as well.
Has anyone really been challenged about MD5 hashes? I for one have not - not trying to stir the pot further on the issue - just curious. I do run both on certain acquisitions but for the most use MD5 with my DD images.
There is a danger here that we could make a rod for our own backs.
Back in the early '90s when I was developing imaging solutions for LE there was a requirement that two images were created, one that could be bagged and tagged and the other could be examined. We argued that a hash was enough and that as long as this was secure one or more copies could be made…..
The rationale provided to us by our LE customers was that this was so that the system tied in with what they did with audio tapes etc. - it seemed logical to them. So we developed imaging system that wrote to tape and CD that created two copies at once. It was what the customer wanted. Eventually logic took hold and we are now where we are today.
There is an argument that if there is no *need* to do something that complicates the issue then there is a *need* not to do so. Our little branch of forensics is complicated enough for the layman to understand without adding to the complexity by duplicating the workload. I agree that it is not difficult and my processors comment was a little tongue in cheek. But to take your argument and turn it on its head a jury might ask "why do you take two copies - what is wrong with one".
I appreciate your willingness to be compliant with what the other side might need - but if we go down that route should we also do a DD image and and AFFF image just in case?
Has anyone really been challenged about MD5 hashes?
I would find it hard to believe, insofar as the integrity of a disk or file system image is concerned. After all, it is not simply enough to alter the file without altering the hash, you need to alter it in a meaningful way (to effect a change in the outcome). Of course, if someone is able to succeed with the DFRWS challenge, that might make things different.
http//
I was challenged at court (rather than in court) in Surrey about three years ago (if memory serves) when this first came to light. I was prosecution and defence raised it as a possible issue. A brief chat with the defence expert over a coffee put this one to bed. Might have been interesting if he had not been so reasonable.