> I'm no expert on hashing/error checking algorithms Nor am I, but here goes... > I'm afraid so please forgive me if the > following is somewhat obvious... > > In the following two pdf files: > > http://notablecases.vaed.uscourts.gov/1:01-cr-00455/docs/68089/0.pdf > http://notablecases.vaed.uscourts.gov/1:01-cr-00455/docs/68092/0.pdf > > related to the case of USA vs Zacarias Moussaoui, there is some discussion of the use > of CRC32 instead of MD5 to provide verification that a hard disk has been imaged > correctly. In this particular case the later use of MD5 would seem to confirm the accurate > imaging of the disks in question but in general does the use of CRC32 during (and after) > the imaging process really make any further checking with MD5 redundant? > > Furthermore, would it be realistically possible to change data in an image whose > authenticity is based solely on CRC32 value(s) without changing the values in question, > and thereby arousing suspicion? Instant reactions to your question, and without reading the PDFs: A CRC check is a very simple check originally designed to check the transmission of bit-serial data in an environment where there is a risk of noise affecting the data. The characteristics of such noise is that it tends to be "bursty", affecting short sequences of bits. A CRC check can be implemented cheaply in hardware when the data is in bit-serial form using "xor" gates and an n-bit shift register; in this case a 32-bit shift register. Given a bit sequence that has been changed it is sufficient to change no more than 32 bits elsewhere to compensate and get the shift register back into the state it would have had without the pair of corresponding changes. Given a disk image where there is likely to be a fair amount of "slack space" finding a location to form the "compensating" change is not difficult. Given that no more than 32 bits need to be changed, that the computations are fairly simple, and that the "slack space" is likely to be fairly close to the data that is changed and you have a situation where it is fairly easy to patch a disc image protected only be CRC32. So, a CRC does what it's designed to do well; but it's only designed to check for *accidental* changes to the data. It *is* practical to intentionally modify data protected by a CRC. A cryptographically strong hash functioin like the one used in MD5 is far harder to "crack". I can't really comment on just *how* much harder it is because I'm not an expert but all the advice is that it's very much stronger. The hash function is harder to compute (and hence takes more time); the hash value generated is longer so more trials have to be made in a "brute force" attack. We wouldn't use MD5 in password files if it was easy to crack; we wouldn't use CRC32 is password files if we were sane! -- David Pick ----------------------------------------------------------------- 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
This archive was generated by hypermail 2b30 : Sun Jan 05 2003 - 15:43:46 PST