CRC(Cyclic Redundancy Check)巡回冗長検査

ファイルの破損チェックに使われる方式です。誤り訂正能力はありませんが、非常に高精度な誤り検出が可能です。
IETF(インターネット技術タスクフォース)のコメント
RFC1952によると
32ビット(4バイト)のCRCはCRC32.cにそのコードが記述されています。
その仕組みは
生成多項式から得られるビット列0xEDB88320から
256個のCRC配列(以降H)を用意しておき、

CRC符号を作成するには、あらかじめCRC符号をc=0xFFFFFFとして初期設定したものに対して
以下の処理を行う。
ファイルの先頭から1バイトずつ読み込んでは、cに対して、ビット列との排他論理和をとり(つまりは読み込んだ1バイト(8ビット)で1のたつビットについて対応するcのビットを反転させる)、そのようにして得られたcの下位8ビットに該当するH(=CRC配列)の中身に対して、cを8ビットシフトした値との排他論理和(cを8ビットシフトした値で1のたつビットをHの中身に対してビット反転する)をとり、その結果をcに格納するという操作

をファイルの終端まで行う。
この処理を経て得られるcこそがCRC符号となる。
この符号をファイルの終端につけて送信する

検査を行うときはCRC符号とファイル本体を分割して、ファイル本体からCRC符号を再作成する。得られたCRC符号とファイルの終端についていたCRC符号が一致するかを確認する。

このような機能が利用されているのがGzipという圧縮方法です。
他にもいろいろなアプリケーションでもCRCによるファイル破損チェックが行われています。
重要なファイル群における通信やファイル圧縮解凍、ファイル暗号複合処理に利用されています。

CRCという言葉は知っていても、中身までは知らなかったのですが、いざ調べてみると面白いですね。ややこしさは抜群です。
256個のCRC配列生成も複雑な処理がされていて、配列番号nをcとおいて、8回の繰り返し処理で、c下位ビットが1のときには、生成多項式から得られる値とcを1ビット右にシフトした値の排他論理和の結果を新たにcとし、下位ビットが0のときには、cを1ビット右にシフトした値を新たにcとするという方法で算出される固定値になっています。

下位ビットが1のときだけビット反転するということの意味や
ファイルから抜き出されてくる1バイトから、256の配列から操作する配列を選択する意味、

このあたりがよくわからないですが、よくできた計算式だと思います。
ファイルによって、ほぼ確実に異なるCRC符号が生み出せているようです。32ビットなので、実際はおよそ、2の32乗くらい(=42 9496 7296)、42億とおりのファイル種別があるということになります。まぁ大丈夫でしょう。まったく同じCRC符号が得られる、2つの異なるファイルを見つけるのは大変そうです。

と、まぁこんな感じで理解していれば、CRCについては十分でしょう。あとはcrc32.cのソースコードを確認しておくとよいでしょうか。

こういう仕組みを全部理解したらすごいんだろうねぇ。知識として、沢山を知っていきたい。