Re: File Integrity Check

[Bennett Todd <bet () newritz mordor net>]

1999-08-15-21:29:13 Scot Anderson:
> CRC is a Cyclic Redundancy Check.

So far so good...

> It's a polynomial, calculating a *very* unique value based on content.

Getting worried here, what's a *very* unique value? How is it different from a
unique value? And how could you even expect to have a unique value with a
fixed-size checksum over a variable-length input? The pigeonhole principle
rules that out.

> Much more effective than a MD5 or any other checksum.

Just as I feared.

Please don't speak out on what you don't know; if people were to believe you,
they might make poor decisions based on your advice.

CRC checksums are pretty good for comms work; they do a handy job of catching
most comms errors and they can be implemented in very fast and simple
hardware. They are however poor cryptographic hashes; it's relatively easy to
compute a change to a file that will cause it to match a given CRC, for any
specific CRC function.

This is not true of MD5 or other cryptographic checksums. They are
sufficiently difficult to "hoax" that you can design protocols on the
assumption that they cannot be hoaxed. One consequence of this feature is that
a suitably-protected offline database of crypto checksums (like e.g. MD5;
unlike CRC or simple modular arithmetic sum of byte values) together with
offline bootable copy of the OS and the checking software constitutes a strong
audit tool for finding out if any files have been changed and if so which
ones.

> In the old days, we used to use this lots with the x/y/zmodem protocols, and
> always ended up coding it in assembler for the individual machines to keep
> the speed up.

I remember those old days myself. Kinder, gentler times in many ways. CRC was
and remains a great communications checksum for catching transmission errors,
particularly when you can go for a fast and simple hardware implementation.

It is not however a cryptographic checksum.

-Bennett