データ整合性チェック（ハッシュ/署名/チェックサム）
ファイル配布やバックアップ転送で「壊れていない？」「すり替えられていない？」を手早く確かめるためのメモです。
役割の違い
目的で手段を選びます。「壊れ」を検出したいのか、「改ざん」を防ぎたいのかで手法が変わります。
比較表
| 手法 | 強み | 弱み/注意 | 典型用途 |
|---|---|---|---|
| ハッシュ（SHA-256など） | 衝突しにくく、ファイルが同一か高速に比較できる。 | 改ざん防止にはならない（ハッシュもすり替えられたら終わり）。MD5/SHA-1は衝突リスクが高く非推奨。 | 配布物の照合、重複検出、ETag生成。 |
| チェックサム（CRC32など） | 計算が軽い。伝送エラー検出に向く。 | 意図的な改ざん検出には弱い。CRC32は衝突しやすい。 | 通信プロトコルの誤り検出、ログローテーション後の軽量チェック。 |
| デジタル署名（公開鍵） | ハッシュ＋秘密鍵署名で改ざん検知と配布元の確認ができる。 | 鍵管理が必要。検証手順がやや重い。 | ソフトウェア配布、パッケージ署名、重要ドキュメント配布。 |
配布・受信時の基本手順
ダウンロードやバックアップ転送で壊れ・改ざんを最小化する手順です。
受信側のチェックフロー
- 配布元が出しているSHA-256などのハッシュ値を入手（HTTPSや署名付きリリースノートで）。
- 取得したファイルのハッシュを計算し一致を確認。
- 改ざん懸念があるなら署名（PGP, minisign, sigstore など）を検証し、公開鍵の正当性も確認。
- 圧縮ファイルなら展開後もハッシュを取り、圧縮中の破損を検出する。
配布側の最小セット
- 少なくともSHA-256のハッシュを公開し、MD5/SHA-1のみの掲載は避ける。
- 改ざんリスクがある配布物は署名を付与し、公開鍵の配布経路を複数用意する（Web＋GitHub＋鍵サーバーなど）。
- 大容量の場合は分割+ハッシュ、またはマニフェスト（ファイルごとのハッシュ一覧）を用意すると再送範囲を絞れる。
ハッシュ選定の目安
セキュリティと性能のバランスを考えます。
選び方
- 配布物の整合性確認: SHA-256が定番。高速化が必要ならBLAKE2/3も選択肢。
- 長期運用の署名: SHA-256かSHA-384/512を利用（署名スキームとセットで運用）。
- MD5/SHA-1は衝突耐性が不足。既存システムが出す場合は、併せてSHA-256以上も出す。
よくある落とし穴
整合性チェックは「値を出すだけ」で終わらない点に注意します。
チェックポイント
- ハッシュ値の入手経路が信用できないと改ざん検出にならない。必ずHTTPSや署名付きチャネルで届ける。
- 改行コードや権限ビットが変わるとハッシュが変わる。配布形態（ZIP/TAR）を固定するとずれにくい。
- S3などのETagはマルチパート時にMD5でなくなることがあるため、整合性の一次指標に使う際は仕様を確認する。
- 署名検証は公開鍵の正当性確認（Web of Trustや鍵ピニング）がセット。鍵がすり替われば無意味。
まとめ
「壊れ検出」ならハッシュ/チェックサム、「改ざん防止と配布元証明」なら署名が必須。ハッシュ値の配布経路と鍵管理まで含めてセットで運用するのが安全です。