ハッシュ・ID・乱数
CRCが一致すれば安全？破損確認と改ざん検証を分けたい
使うツール
ファイルの横に八桁の16進数があり、手元の計算結果も同じだった。そこで『このファイルは安全』と判断したくなりますが、CRC32が確かめるものはそこまで広くありません。データの取り違えや破損を調べる手掛かりにはなっても、作った人や悪意のないことを証明する仕組みではありません。まず短い文字列で同じ計算方式を使っているかを確認し、その後で比較対象と信頼の範囲を整理します。
123456789で、同じCRCを計算しているか確認する
123456789
CRC-32/ISO-HDLC: cbf43926CRC32ツールへ123456789の九文字だけを入力します。結果はcbf43926です。ここで計算例の二行目や末尾の改行まで入力しないようにします。この画面はCRC-32/ISO-HDLCを使うため、別のCRC32方式の期待値を持ってくると、同じ入力でも一致しない場合があります。『CRC32』という名前だけで、すべてのパラメーターが同じとは限りません。
八桁の16進数は32ビットを表しています。先頭が0になる結果でも、その0を含めた八桁表示で扱うと、他の画面との比較がしやすくなります。大文字と小文字の違いだけなら16進数の値は同じですが、文字数の不足や別の方式を大文字小文字の違いだと思い込まないようにします。
見た目ではなく、入力したバイトが一致しているかを見る
同じ123456789でも、末尾にLFが付いたファイルは別のバイト列です。Windows形式のCRLFならさらに違います。文字列入力はUTF-8として計算し、ファイル選択はそのファイルのバイトを使います。文字コードやBOM、末尾改行が違えば、見た目が同じ文章でも計算対象は違います。値が一致しないときは、まず入力元とファイルの大きさ、改行や文字コードを確認します。
改行を消して一致したとしても、元ファイルが正しかった証拠にはなりません。何を比較したいかによって、改行も含めた完全一致が必要か、文章としての比較でよいかが違います。ファイル配布のチェックサムを確認する場面では、相手が示した対象ファイルのバイトをそのまま比較します。合わせるために入力を都合よく正規化しないでください。
違うファイルでも、同じCRCになることがある
CRC32の結果は2の32乗通りですが、入力ファイルの種類はそれよりずっと多くあります。そのため、違う入力に同じ結果が対応することは避けられません。これを衝突と呼びます。CRCは意図的な改ざんへ耐えるための暗号学的な認証ではありません。チェック値が一致したことを、入力が絶対同一である証明や、悪意のある変更がない保証へ広げないようにします。
逆に不一致なら、同じ方式で同じ対象を計算したという前提の下で、どこかが違うと分かります。ただし、それだけでは破損箇所や原因、どちらが正しいかは分かりません。版が違う、途中で変換された、ファイルを取り違えた、といった候補を順に確認します。チェック値は調査の入口であって、ファイルを修復するデータではありません。
配布元の確認には、比較する値の入手先も必要
SHA-256などの暗号学的ハッシュを比較する場合でも、期待値を信頼できる配布元から取得したかが重要です。ファイルと期待値が同じ攻撃者に差し替えられていたら、一致しても配布元の確認にはなりません。署名付き配布物なら、その署名を適切な鍵と手順で検証する仕組みを使います。このCRC32ツールやSHA計算だけが署名検証を実施するわけではありません。
また、CRC32もSHAハッシュもファイルの内容を暗号化しません。短い結果から元へ戻す操作を提供していないことと、秘密を守る暗号化は別です。パスワード保存やアクセス許可の判定へCRC32を流用せず、必要な目的に合う仕組みを選びます。値の長さや見た目が似ていても、チェックサム、ハッシュ、署名は役割が異なります。
一致・不一致を、対象と方式付きで記録する
確認メモには、ファイル名だけでなく、版、byte数、CRCの方式、期待値の入手先、計算結果を残します。『CRCが同じ』より『この版のこのファイルについて、CRC-32/ISO-HDLCが配布資料の値と一致』と書く方が、後から同じ確認をやり直せます。安全だと言い切る代わりに、実施した比較の範囲を正確に伝えます。