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. |

| 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.
pgprmWPC3Wobs.pgp
Description: PGP signature
| Previous by Date: | Re: mactimes (ctime on unix is not creation but change time), Martin Mačok |
|---|---|
| Next by Date: | Re: MD5 Collisions and Evidence Integrity, Gary Kessler |
| Previous by Thread: | RE: MD5 Collisions and Evidence Integrity, Svein Yngvar Willassen |
| Next by Thread: | RE: MD5 Collisions and Evidence Integrity, Svein Yngvar Willassen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |