Ethical Hacking Training at InfoSec Institute

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Computer Forensics Computer-Forensics
[Top] [All Lists]

Re: MD5 Collisions and Evidence Integrity

Subject: Re: MD5 Collisions and Evidence Integrity
Date: Mon, 15 Nov 2004 12:49:28 -0500
On Thu, 11 Nov 2004 21:25:03 +0100, Svein Yngvar Willassen said:
The question here is why do we use hashing at all? It seems there are two
different situations where hashing will protect:

1. Unintentional changes in an evidence image
2. Intentional changes in an evidence image

Situation 1 can easily be protected against by using CRC or similar
features. (which some popular forensic tools also do)

You might want to look at what the *real* protection that a CRC-32 (for
instance) gives you against unintentional changes - it's not as high as
you might think.

http://www.ieee802.org/17/documents/ 
presentations/jan2003/ns_crcBitReversa_01l.pdf

discusses the undetected-error rate for a CRC-32 polynomial. (The case we're
interested in is the "burst error" detection capability).

It turns out that the CRC-32 in question could fail to detect as much as
1 in every 227 errors.  And remember that it's primarily intended to detect
errors of only 1-2 *bits* - the sort of mass alteration that would result
from *either* an "oops" or intentional modification would be *many* bit
in length, and which most CRC polynomials are unable to catch.  So figure
that in 1 out of ever 250 or so "whoops" cases, the CRC-32 won't notice a 
thing...

Even worse, if the alteration was intentional, there's  known *fast* algorithms
for creating a new plaintext with the same CRC-32.  Basically, you use the same
algorithm that is used for *every single* packet transmitted on the Internet,
as specified in RFC1141/1624.  I don't know of any routers that *don't* update
the IP checksums in hardware.

http://www.ietf.org/rfc/rfc1141.txt
http://www.ietf.org/rfc/rfc1624.txt

In fact, this level of weakness in CRC's is why crypto-strength hashes were
invented in the first place...

Bottom line:  Don't trust a CRC-32 checksum, especially for gigabytes of
data.  

Attachment: pgprmWPC3Wobs.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>