ファイルのダウンロード検証やパスワードの保存、電子署名など、さまざまな場面で「ハッシュ値」が使われています。
一方で、CRC32・MD5・SHA-256といった名前は聞いたことがあっても、具体的に何が違い、どのように使い分ければよいのかが分かりにくいと感じる方も多いのではないでしょうか。
本記事では、代表的な3つのハッシュ関数について、仕組みやリスク、実務での使い分けの考え方を整理して解説します。
ハッシュ関数とは何か
ハッシュ関数とは、任意の長さのデータを、一定の長さの「ハッシュ値」に変換する関数です。
入力が1ビット違うだけでも、出力がまったく別の値になるよう設計されています。
ハッシュ関数の基本的な性質
ハッシュ関数には、用途に応じて求められる性質があります。
特にセキュリティの観点からは、次の3つが重要です。
1つ目は衝突耐性です。
これは異なる2つの入力から、同じハッシュ値が得られてしまう事態(衝突)が、実用上ほとんど起きないことを意味します。
衝突が簡単に見つかるハッシュ関数は、電子署名や改ざん検知には適していません。
2つ目は第二原像耐性です。
ある入力とそのハッシュ値が分かっているとき、同じハッシュ値となる別の入力を見つけることが非常に困難である必要があります。
これは既存データのなりすましを防ぐうえで重要です。
3つ目は一方向性です。
ハッシュ値から元の入力を推測することが極めて難しい、という性質です。
この性質があることで、パスワードの保存などに利用できるようになります。
CRC32、MD5、SHA-256はいずれも「入力を短い値に要約する」という意味では同じですが、これらの性質の強さや設計思想が大きく異なります。
その違いが、安全性と用途の違いに直結します。
CRC32・MD5・SHA-256の位置づけ
CRC32・MD5・SHA-256は、次のような位置づけで理解すると整理しやすくなります。
- CRC32: 誤り検出・データ整合性確認向けのチェックサム
- MD5: かつては暗号学的ハッシュとして広く利用されたが、現在は脆弱とされる方式
- SHA-256: 現在主流の暗号学的ハッシュ関数(SHA-2ファミリーの一種)
この違いを踏まえずに「どれもハッシュだから同じ」と考えてしまうと、セキュリティが必要な場面でCRC32やMD5を使ってしまうなどのリスクにつながります。
CRC32とは何か
CRC32(Cyclic Redundancy Check 32-bit)は、主に通信やストレージにおけるエラー検出を目的として設計されたチェックサム方式です。
仕組みの概要
CRC32は、入力データを特定の多項式による「割り算」処理で扱い、余りをハッシュ値(32ビット)として扱います。
処理の中身はビット演算に還元されており、ハードウェアでもソフトウェアでも高速に計算できるようになっています。
CRCの強みはランダムな誤りに対する検出力と実装の容易さです。
通信途中でビットがひっくり返った場合など、ほとんどのケースで検出できるよう設計されています。
CRC32の用途と限界
CRC32は、次のような場面でよく利用されています。
- ネットワークプロトコル(TCP/IPの一部など)でのパケット誤り検出
- ストレージやファイルフォーマット(ZIPファイルなど)での整合性チェック
- ログや大規模データでの簡易な重複検出
一方で、CRC32は暗号目的には設計されていません。
特に注意すべき点は以下の通りです。
- 衝突は意図的に作ることが比較的容易である
- ハッシュ値から元のデータを推測しにくくするような設計にはなっていない
- 鍵を使わない公開アルゴリズムのため、攻撃者は自由にCRCを計算・調整できる
そのため、改ざん防止やパスワード保存などのセキュリティ用途にCRC32を使うことは適切ではありません。
CRCはあくまで「伝送途中や保存中に偶発的なエラーが起きていないか」を確認するための技術と理解しておくことが重要です。
MD5とは何か
MD5(Message Digest Algorithm 5)は、1990年代から2000年代にかけてもっとも広く利用された暗号学的ハッシュ関数の1つです。
出力長は128ビットで、テキスト表現では32桁の16進数として表されることが一般的です。
仕組みのイメージ
MD5はMerkle–Damgård構造と呼ばれる設計に基づいており、入力データを固定長のブロックに分割し、内部状態を更新しながら順に処理していきます。
最終的な内部状態が、MD5ハッシュ値となります。
内部ではビット演算、加算、論理関数などが複雑に組み合わされており、人間の目にはランダムに近い出力が得られます。
MD5の現状のリスク
MD5は歴史的には重要なアルゴリズムですが、現在では暗号的な用途には不適切とされています。
主な理由は以下の通りです。
- 衝突(異なる2つの入力が同じMD5になる)が、現実的な計算量で作成可能である
- 実際に、偽造証明書や電子署名の攻撃実証などに悪用された事例がある
- 攻撃手法や計算資源の進歩により、安全マージンがほとんど残っていない
たとえば、攻撃者が電子署名に使われる文書について、同じMD5値を持つ2つの異なる文書を人為的に設計できてしまえば、「正しい文書」と同じ署名を「悪意ある文書」に流用できる可能性があります。
この種の攻撃はすでに実証されており、MD5を署名や証明書発行に使うことは重大なリスクになります。
MD5の残されている用途
このような背景から、多くの標準やベストプラクティスではMD5を暗号目的に使わないことを求めています。
一方で、次のような「非セキュリティ用途」で、レガシーとして使われている場面は依然として存在します。
- 既存システムとの互換性を保つためのファイル識別子
- 内部的な重複検出やキャッシュキー(外部から攻撃を受けにくい前提)
- 歴史的なログやデータ形式との互換性維持
ただし、新規に設計するシステムにおいては、MD5を選ぶ理由はほとんどありません。
互換性維持など特別な事情がない限り、より安全なSHA-2系(SHA-256など)を利用すべきです。
SHA-256とは何か
SHA-256は、SHA-2ファミリーに属する暗号学的ハッシュ関数で、出力長は256ビット(64桁の16進数)です。
現時点の知見では、広く信頼されているハッシュ関数の1つであり、多くのプロトコルや規格で推奨されています。
仕組みと特徴
SHA-256もMD5と同様に、入力をブロックに分割して順次処理する構造を持ちますが、設計上の安全マージンが大きく、既知の攻撃に対して十分な耐性を持つよう設計されています。
SHA-256の主な特徴として、次の点が挙げられます。
- 256ビットという長い出力により、総当たり攻撃に対する耐性が高い
- 現時点で、実用的な衝突攻撃や第二原像攻撃は知られていない
- ハードウェア・ソフトウェア双方で広く実装されており、性能面でも実用的
そのため、新しいシステムで暗号学的ハッシュが必要な場合の第一候補として採用されることが多く、TLS、電子署名、ブロックチェーンなど、さまざまな場面で利用されています。
SHA-256の主な用途
SHA-256は、次のようなセキュリティ用途で広く用いられています。
- TLSやHTTPSにおける証明書・ハンドシェイク
- 電子署名やコード署名(デジタル証明書と組み合わせて使用)
- ブロックチェーン(ビットコインなど)でのブロックハッシュ・PoW
- ファイルの改ざん検知・整合性検証
- HMAC-SHA-256としてのメッセージ認証
ただし、パスワード保存にはSHA-256単体では不十分である点には注意が必要です。
パスワードには<b>ストレッチングやソルト付与を行う専用方式(PBKDF2、bcrypt、scrypt、Argon2など)を使うのが現在のベストプラクティスです。
CRC32・MD5・SHA-256の違いを整理する
3つの方式の違いを俯瞰するために、主なポイントを比較してみます。
以下はテキストでの比較表です。
| 項目 | CRC32 | MD5 | SHA-256 |
|---|---|---|---|
| 出力長 | 32ビット | 128ビット | 256ビット |
| 主な設計目的 | 誤り検出 | 暗号学的ハッシュ(当時) | 暗号学的ハッシュ |
| 現在の安全性評価 | 暗号用途には不可 | 暗号用途には不可 | 現状有効とされる |
| 衝突耐性 | 低い | 実用的な攻撃あり | 既知の実用攻撃なし |
| 一方向性 | ほぼ考慮されず | 設計上はあるが不十分 | 考慮されている |
| 代表的用途 | 通信のエラー検出、ファイル整合性チェック | レガシー互換、内部的ID | TLS、電子署名、改ざん検知など |
この表から分かるように、CRC32とMD5は、現代のセキュリティ要件を満たす暗号学的ハッシュとしては使えないことが明確です。
SHA-256はその代替として設計され、現代の標準的な用途を広くカバーしています。
どう使い分ければよいか
実務で迷いやすいのは、どの用途にどのハッシュ関数を使うべきかという点です。
ここでは代表的なシナリオごとに考え方を整理します。
データの誤り検出・整合性チェック
通信途中のビット誤り検出や、ストレージの読み出しエラー確認など、「偶発的なエラーがないか」を確認したいだけの場面では、CRC32が有効です。
高速に計算でき、実装も容易なため、組み込み機器などリソース制約がある環境でもよく使われます。
一方で、悪意ある改ざんが想定される場合にはCRC32では不十分です。
たとえば、インターネットから配布するツールのダウンロードページで「改ざんされていないこと」を保証したいなら、SHA-256のハッシュ値や電子署名を提供すべきです。
セキュリティを伴う整合性確認・電子署名
電子署名や証明書、ソフトウェア配布時の真正性確認など、「誰かに改ざんされていないこと」を保証したい用途では、SHA-256を含む暗号学的ハッシュ関数が必須です。
- 証明書や署名アルゴリズムの選択では、SHA-256以上(SHA-384, SHA-512など)が推奨されています
- MD5やSHA-1を使った証明書・署名は、すでに多くの環境で非推奨または禁止となっています
このような用途でCRC32やMD5を使用すると、攻撃者に衝突を作られる危険性が高くなり、改ざん検知が機能しなくなる可能性があります。
パスワードの保存
パスワードの保存については、CRC32・MD5・SHA-256に共通する重要な注意点があります。
それはいずれも「そのまま単体では保存用ハッシュとして不十分」であるという点です。
- CRC32・MD5はそもそも論外
- SHA-256も、ソルトなし・ストレッチングなしでそのまま使うと、総当たり攻撃やレインボーテーブル攻撃に対して弱い
パスワード保存には、次のような専用のパスワードハッシュ関数を用いるのが現代の基本です。
- PBKDF2(HMAC-SHA-256などと組み合わせ)
- bcrypt
- scrypt
- Argon2 など
これらは、計算コストを高くすることで、攻撃者による総当たりを現実的でないレベルまで引き上げることを目的としています。
互換性・レガシー対応
既存システムやプロトコルとの互換性のために、仕方なくMD5やCRC32が残っているケースも多くあります。
この場合、現実的な対応策としては次のようなものが考えられます。
- 新規機能や外部公開APIではSHA-256など安全な方式を採用する
- 内部的な利用にMD5やCRC32を残す場合も、外部から攻撃可能な入力に対して使わないようにする
- 長期的には、移行計画を立てて安全な方式へ置き換える
「レガシーだから仕方ない」で放置せず、リスクを把握したうえで段階的に改善していくことが重要です。
実務で意識しておきたいポイント
最後に、CRC32・MD5・SHA-256を扱ううえで、エンジニアとして意識しておきたいポイントをいくつか挙げます。
1つ目は「暗号学的ハッシュ」と「チェックサム」を混同しないことです。
CRC32はチェックサムの代表例であり、暗号的な安全性は考慮されていません。
「とりあえずハッシュを取っておけば安全」という発想は危険です。
2つ目はMD5を新規設計に使わないことです。
たとえ「社内システムだから」「内部用途だから」といった事情があっても、将来的に利用範囲が変わる可能性は常にあります。
最初からSHA-256など、安全な方式を選んでおく方が結果的にコストが低くなります。
3つ目はハッシュ関数はあくまで部品であり、使い方の設計も同じくらい重要だという点です。
SHA-256自体が安全だからといって、パスワードをそのままSHA-256でハッシュして保存してしまえば、総当たり攻撃には脆弱な設計になってしまいます。
用途ごとのベストプラクティス(パスワードならストレッチング、通信ならTLSなど)をセットで検討する必要があります。
まとめ
本記事では、CRC32・MD5・SHA-256という代表的なハッシュ関数について、その仕組みとリスク、そして使い分けの考え方を解説しました。
CRC32は高速なエラー検出用のチェックサムであり、セキュリティ目的には使うべきではないこと、MD5はかつて広く使われたものの、現在では暗号用途には危険であること、そしてSHA-256は現代の標準的な暗号学的ハッシュとして、多くのセキュリティ用途で推奨されていることを整理しました。
実務で重要なのは、単に「ハッシュを使う」ことではなく、目的(エラー検出か、改ざん防止か、認証か)に応じて適切なアルゴリズムを選び、正しい設計で組み込むことです。
新規のシステム設計では、原則としてSHA-256など安全な方式を採用し、CRC32やMD5は互換性や限定的な用途にとどめるのが、現時点での現実的な指針と言えるでしょう。
ハッシュ関数は、現代の情報システムを支える基盤技術の1つです。
その役割と限界を正しく理解し、状況に応じて適切に使い分けることで、システム全体の安全性と信頼性を高めることができます。
