MD5 vs CRC32 vs SHA-256 — ファイル整合性チェックでどれを使うべきか
ダウンロードの破損検出 / 改ざん検知 / 重複ファイル判定 で MD5 / CRC32 / SHA-256 をどう使い分けるかを、速度 / 出力長 / 衝突耐性 / 用途 で比較。改ざん検知に CRC32 を使ってはいけない理由も整理します。
整合性チェックは「何を検出したいか」で道具が変わる
ファイル整合性チェックという同じ用語のもとに、目的の違う 3 つの作業が混ざっています。ダウンロード途中のビット化けを拾いたい (通信路の雑音検出)、同じ中身のファイルを見つけたい (重複判定)、第三者が差し替えていないか確かめたい (改ざん検知)。判断軸は 4 つ。速度 は数百万ファイルをハッシュ化するパイプラインで効きます。出力長 は衝突の起きにくさと、保存・比較コストのトレードオフ。衝突耐性の種類 は「悪意のない衝突 (誤検出率)」と「悪意ある衝突 (攻撃)」で別物です。標準採用 は ZIP や Ethernet のように規格内に組み込まれているか、自分で計算する必要があるかを決めます。
ここでは MD5 / CRC32 / SHA-256 の 3 つに絞ります。SHA-1 は暗号学的位置づけが MD5 と近いので別記事 (SHA-256 vs MD5 vs SHA-1) に譲り、本稿では「ファイル整合性」という日常作業を切り口に CRC32 を主役に据えて並べます。
CRC32 / MD5 / SHA-256 の比較
| 項目 | CRC32 | MD5 | SHA-256 |
|---|---|---|---|
| 出力長 | 32 bit (4 byte) | 128 bit (16 byte) | 256 bit (32 byte) |
| 16 進表記 | 8 文字 | 32 文字 | 64 文字 |
| 計算速度 (1 コア目安) | 10+ GB/s (ハードウェア命令あり) | 1-2 GB/s | 300-500 MB/s (SHA-NI で 1.5-2 GB/s) |
| 種別 | 非暗号学的 (誤り検出専用) | 暗号学的 (破られ済み) | 暗号学的 |
| 衝突発見 | 設計上 1/2^32 で起こりうる | 2004 Wang、現実的攻撃可 | 未発見 |
| 悪意ある改ざん検知 | 不可 (1 bit いじって CRC を戻せる) | 不可 (衝突を意図的に作れる) | 可 |
| 標準採用 | ZIP / Ethernet / PNG / Gzip | RFC 1321 (廃止勧告) | NIST FIPS 180-4 現役 |
| 開発年 | 1961 (Peterson) | 1991 (Rivest) | 2001 (NIST) |
CRC32 は 誤り検出符号 であって暗号学的ハッシュではありません。設計上 2^32 ≒ 約 43 億で偶然衝突するので、ファイル数が 65,000 を超えると 50% の確率で偶然衝突します (誕生日問題)。それでも採用される理由は 桁違いの速さ と ハードウェア組み込み。Ethernet フレーム / ZIP エントリ / PNG の各チャンク / Gzip ブロックには CRC32 が標準で埋め込まれていて、私たちが「自分で計算する」場面は少なめです。MD5 は 2004 年の衝突発見以降、改ざん検知用途では退役済みですが、悪意のない衝突は天文学的に低確率 なので重複判定では現役。SHA-256 は 2026 年時点で実用的な衝突が知られておらず、配布署名・Git・TLS の標準ハッシュです。
用途別に何を選ぶか
ダウンロード破損検出 (ISO イメージ / インストーラ): SHA-256。配布元が *.sha256 を併記しているなら、それと一致するか確認する。MD5 で配布している配布元はリスク (中間者攻撃で別ファイルに差し替えても気付けない)。可能なら配布元の GnuPG 署名と組み合わせる。
重複ファイル判定 (写真整理 / バックアップ重複排除): MD5。数 GB から TB スケールでも 1〜2 GB/s で回り、悪意のない衝突確率は事実上ゼロ。攻撃シナリオがない用途なので SHA-256 にする必要性は低い。さらに速度が必要なら BLAKE3 (SHA-256 より数倍速く同等以上の安全性)。
通信路や保存形式の組み込み誤り検出: CRC32。ただし「自分で計算する」よりも、ZIP の中で勝手に検証されている / TCP がフレーム単位で弾いている、という形で間接的に恩恵を受けるケースがほとんど。アプリで自前 CRC32 を計算するのは、ファームウェアの ROM チェックや独自プロトコルくらいです。
バックアップ / 配布物の改ざん検知: SHA-256 以上。MD5 / CRC32 で改ざん検知ができない理由は同じで、任意の改ざん後に元のハッシュ値に一致させる細工が現実的に可能 だから。配布元のサーバーが侵害されたシナリオでは MD5 のチェックサム自体も書き換えられている、というのもよくある落とし穴です。
短い識別子 (キャッシュキー / ETag): CRC32 または MD5。衝突耐性が要らないなら 4 byte / 16 byte の節約が効きます。ただし「将来この識別子が改ざん検知に流用される」可能性があるなら最初から SHA-256 にしておく方が無難。
ブラウザだけで計算してチェックサムを照合する
ダウンロードしたファイルや手元の文書のハッシュをすぐ確かめたいときは hash-generate で MD5 / SHA-1 / SHA-256 / SHA-512 / SHA-3 / BLAKE2 を一括計算できます。配布元が公開している abc123... と、計算結果を文字単位で比較するだけ。CRC32 / CRC16 / CRC8 の誤り検出符号は crc-calc で個別に計算でき、組み込み機器のファームウェア検証やシリアル通信の検証に使えます。
注意点は 3 つ。(1) MD5 で配布しているチェックサムを盲信しない。配布元の Web サイトごと侵害されている場合、MD5 値も書き換え済みで気付けません。可能なら配布元の GnuPG 署名 (*.asc) で公開鍵まで確認する。(2) 改行コードと BOM でテキストファイルのハッシュは簡単に変わります。CRLF / LF / BOM 有無は事前に揃える。(3) CRC32 を改ざん検知に流用しない。CRC は線形演算なので、改ざん側が元の CRC に戻るよう差分を計算して上書きすれば検出されません。Web Crypto API ベースの実装は GitHub で公開しており、DevTools の Network タブで「ファイル本体がどこにも送信されていない」ことを確認できます。