チェックサム徹底解説：仕組み、主要アルゴリズム、用途とセキュリティの違い
エバープレイ編集部チェックサムとは — 概要と目的
チェックサム（checksum）は、データの誤り検出や整合性確認のために、データ列から算出される短い値（数値またはビット列）です。送受信や保存中にデータが変化していないかを簡単に確認するために使われます。ファイル転送、ネットワークプロトコル、ストレージ、バックアップ、ソフトウェア配布など、さまざまな場面で広く利用されています。
基本的な仕組み
チェックサムは入力データ（バイト列やビット列）に対してある種の演算を行い、その結果を固定長の値として出力します。送信側は元データからチェックサムを算出して一緒に送信し、受信側は受け取ったデータからもう一度チェックサムを計算して送信側の値と比較します。値が一致すれば「整合性が保たれている可能性が高い」、一致しなければ「データが変化している（＝エラー）」と判断します。
代表的なアルゴリズム
単純合計（モジュロ和） — 各バイトを足し合わせて所定の幅（例：8ビット、16ビット）に切り詰める方式。実装は簡単ですが、並び替えや特定の誤りパターンに弱いです。
1の補数和（Internet checksum） — IP/TCP/UDP のヘッダチェックサムで使われる16ビットの1の補数和。RFC 1071 に計算方法が定義されています。隣接したビット反転や短いバーションの誤りは検出できますが、強い誤り検出性はありません。
CRC（巡回冗長検査） — 多項式除算（GF(2)）に基づく手法で非常に高い誤り検出能力を持ちます。CRC-16、CRC-32 などがあり、通信やストレージのフレーム検査、ファイル伝送などで広く使われています。短いバーストエラーやビット反転に強いのが特徴です。
Fletcher、Adler — CRC と単純合計の中間的な性能を持つチェックサム。計算が早くて軽量なため、アプリケーションレベルで使われることがあります（例：Adler-32 は zlib の一部で使用）。
ハッシュ関数（MD5, SHA-1, SHA-2, SHA-3 等） — 元来はデータ整合性のためにも使われますが、これらは暗号学的ハッシュや単なるハッシュに分類されます。MD5 や SHA-1 は衝突耐性が弱い（攻撃可能）ため、セキュリティを要する用途では SHA-256 などの SHA-2 や SHA-3 を推奨します。暗号学的ハッシュは「データが改ざんされていないことの強い保証」を提供しますが、厳密な「機密性」は別の仕組み（署名や MAC）が必要です。
アルゴリズムごとの特徴比較（概要）
- 計算コスト：単純合計 < Fletcher/Adler < CRC < 暗号学的ハッシュ（SHA-2, SHA-3）
- 誤り検出能力（ランダム・偶発エラー）：CRC と暗号学的ハッシュが強い
- セキュリティ（悪意ある改ざん耐性）：暗号学的ハッシュ（十分長いもの）が必要。単純チェックサムやCRCは改ざんに弱い。
ネットワークやプロトコルでの利用例
代表的な利用例としては、IP、TCP、UDP のヘッダチェックサムや、イーサネットフレームやPPP、USB などのリンク層での CRC 検査があります。IP/TCP のチェックサムは 16 ビットの 1 の補数和（RFC 1071）で、ネットワークヘッダの単純な破損検出に使われます。一方で、物理層やデータリンク層では CRC がよく用いられ、パケットの誤り検出に優れた性能を発揮します。
ストレージやバックアップでの利用
RAID、ファイルシステム、バックアップソフトやコンテンツ配布（ソフトウェアのダウンロード）では、ファイルの破損や転送ミスを検出するためにチェックサムやハッシュが用いられます。パッケージ管理やソフトウェア配布では、配布ファイルの SHA-256 などのハッシュ値を公開して、ダウンロード後にユーザが整合性を検証できるようにしています。
チェックサムと暗号（セキュリティ）の違い
チェックサムは主に偶発的なエラー検出のための仕組みです。攻撃者が意図的にデータを修正し、その修正に合わせてチェックサムも書き換えれば（単純なチェックサムやCRCでは）改ざんが発見されないことがあります。これに対して、暗号学的ハッシュ（長さと設計による衝突耐性）やデジタル署名、MAC（Message Authentication Code）は、悪意ある改ざんに対して耐性がある設計がなされています。したがって、セキュリティ要件がある場合はチェックサムのみでは不十分で、SHA-256 と公開鍵署名や HMAC を併用することが一般的です。
実装上の注意点
エンディアンとバイト列の扱い：同じデータでもバイト順（リトルエンディアン／ビッグエンディアン）や改行コード（LF/CRLF）などの違いでチェックサムが変わります。テキストデータを扱う場合は正規化（改行・文字コード）を統一しておくことが重要です。
ASCII とバイナリ：ファイルをテキストモードで扱うと改行変換が入り、チェックサムが変わります。バイナリモードで正確なオリジナルを扱うようにしてください。
表示形式：チェックサムは16進や10進、Base64などで表示されます。表記揺れに注意（大文字小文字、先頭のゼロパディングなど）。
衝突（collision）:有限長の値なので異なるデータが同じチェックサムになる可能性があります。特にチェックサム長が短いと衝突確率が高く、意図的な衝突生成は容易になるため、重要な用途では長い暗号学的ハッシュを用いるべきです。
パフォーマンス：大規模データ処理時は高速に計算できるアルゴリズム（CRC のテーブル方式、ハードウェアアクセラレーション、並列化など）を検討します。
よく使うコマンド（Linux/UNIX 環境の例）
md5sum file.txt — MD5 ハッシュを表示（セキュリティ用途には非推奨）
sha256sum file.txt — SHA-256 ハッシュを表示（一般的な整合性確認に推奨）
cksum file.txt — POSIX の cksum（CRC に基づく）を表示
openssl dgst -sha256 file.txt — OpenSSL で SHA-256 を計算
簡単な例（概念説明用）
単純合計の例：データが 65, 66, 67（ASCII の 'A','B','C'）なら合計は 198。8 ビットのチェックサムにするなら 198 を 256 で割った余り（198）を使う。受信側が同じ計算を行い一致すれば簡易的な検査に合格となります。ただし、この方式は並び替えや特定パターンのエラーを検出できません。
現実の運用での使い分け方
- 単純な誤り検出（例：簡易な転送チェック）には軽量なチェックサムや Adler-32。
- 通信やストレージの低レイヤでの誤り検出には CRC（ハードウェア実装されることが多い）。
- ソフトウェア配布やバックアップで改ざん検出も必要なら SHA-256 以上の暗号学的ハッシュ。
- データの真正性（改竄防止や送信者認証）が必要ならハッシュ＋デジタル署名、または HMAC（共有鍵ベース）を用いる。
まとめ
チェックサムはデータの整合性を簡単に確認するための有効な手段で、用途や求められる強度に合わせて多様なアルゴリズムが存在します。単純なチェックサムや CRC は偶発的なエラー検出に優れ、高速ですが、悪意ある改ざんに対しては暗号学的ハッシュや署名に比べて脆弱です。実際の運用では、誤り検出のレベル、性能要件、セキュリティ要件を踏まえて適切な方式を選ぶことが重要です。
参考文献
- チェックサム - Wikipedia (日本語)
- 巡回冗長検査 (CRC) - Wikipedia (日本語)
- RFC 1071 — Computing the Internet Checksum
- RFC 791 — Internet Protocol (IP)
- RFC 793 — Transmission Control Protocol (TCP)
- NIST — Cryptographic Hash Functions
- RFC 6151 — Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5
- Shattered — announcement and demo of SHA-1 collision (Google)
投稿者プロフィール
