I believe the issues of collisions occurs in any type of hashing, there is
no way around it, and the issue has been around for a very long time.
I think the fact, like in the case of EnCase, that it outputs an acquisition
hash before, a verification hash after, and it does so immediately. It would
be hard to prove that that you could do that and give matching hashes with
altered input.
I believe in the study it was something like 2^40 computations that they
were able to "create" or generate two inputs that would create the same
hash.
I do not think this affects the reliability of the evidence, or the way the
MD5 checksum is used as in the case of EnCase.
Of course EnCase and others might switch to SHA-1 or SHA-256 etc.. just to
avoid the issue ever coming up.
I guess if someone can produce and prove it, and get it into case law it
might become an issue in court.
I wonder how many hard-drive acquisitions they would have to do until they
found two different inputs that create a collision, and how long that would
take?
(is it just me, or does saying "in the case of EnCase" sound funny?)
______________________________________
Dave Kleiman, CISSP, CISM, CIFI, MCSE
www.SecurityBreachResponse.com
-----Original Message-----
From: Ferrill, Rob [mailto:Rob.Ferrill@healthsouth.com]
Sent: Tuesday, November 09, 2004 14:44
To: forensics@securityfocus.com
Subject: MD5 Collisions and Evidence Integrity
Has anyone stopped using MD5 for hashing evidence files since the disclosure
of collision issues at the Crypto 2004 conference? There was some concern
raised during a discussion this morning that this may not be acceptable in
court cases anymore to prove evidence integrity.
Thanks,
Rob
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
