🔐 ファイルハッシュ計算・照合 (SHA-256 / MD5 / SHA-1)
ファイルをブラウザにドロップするだけでMD5・SHA-1・SHA-256を即座に計算。ダウンロードファイルの改ざん検知・整合性確認に。
計算中...
✅ 期待値と照合 (Checker モード)
ダウンロード元サイトに記載されている SHA-256 / MD5 / SHA-1 値を貼り付けると、上で計算した値と一致するか自動判定します。一致しなければファイルは破損または改ざんされています。
📖 つまずきやすいポイント
ファイルをドロップすると MD5 / SHA-1 / SHA-256 を Web Crypto API で計算し、期待値を貼れば一致するかを判定します。ファイルはブラウザから出ません。ここで確認できるのは「手元のバイト列が、公開されている値と一致するか」だけです — そのファイルが安全かどうかも、公開されている値そのものが信用できるかどうかも、ハッシュでは分かりません。ハッシュは「同一性」の道具であって「正当性」の道具ではありません。この 2 つを混同したまま運用すると、検証している気になって、実際には何も検証していない状態になります。
| ケース | 何が起きるか | どうする |
|---|---|---|
| ハッシュが一致しても改ざんされていないとは限らない | 公開されているハッシュ値が、ダウンロード先と同じサーバーに置かれている場合、両方を書き換えられます。攻撃者がファイルを差し替えられる立場にいるなら、そのすぐ横にあるハッシュ値も差し替えられます — そして一致するので、あなたの検証は成功します。この構図で守れるのは「転送中の破損」と「ミラーの取り違え」だけで、侵害されたサーバーからのダウンロードには何の効果もありません。実際、いくつかのオープンソースプロジェクトが配布サーバーを侵害され、バイナリとチェックサムの両方を書き換えられた事例があります。「チェックサムを確認しました」は、それ単独ではセキュリティ上の主張になりません。 | ハッシュ値は、ファイルとは別の経路から取ってください。 配布サイトがミラーなら、ハッシュ値は本家のリリースノートや GitHub の Releases ページから取ります。より確実なのは署名の検証で、GPG・minisign・OS のコード署名は秘密鍵を持っていないと作れないため、サーバーを侵害されただけでは偽造できません — gpg --verify file.sig file の 1 行で済みます。ただし「鍵をどこから入手したか」が問われます — 同じ侵害されたサイトから鍵を落としたなら、振り出しに戻ります。パッケージマネージャ (apt / dnf / winget / Homebrew) を使えるなら、それが最良の選択です — 鍵の配布と検証が仕組みとして組み込まれているため、あなたが手順を間違える余地がありません。 |
| MD5 と SHA-1 は、もう改ざんの検出に使えない | MD5 の衝突は、ノート PC で数秒あれば作れます — 同じ MD5 値を持つ「無害な文書」と「悪意ある実行ファイル」を意図的に生成できるということです。SHA-1 も 2017 年に実際の衝突が公開され、2020 年には任意の接頭辞で衝突を作る手法まで示されました。これが意味するのは、「MD5 が一致したから同じファイルだ」という推論が成り立たなくなったことです。ただし用途によっては今も有効です — 偶然の破損 (転送エラー・ディスク不良) を検出する目的なら、MD5 でも十分機能します。攻撃者がいない前提でだけ使える、と整理してください。 | セキュリティ目的なら SHA-256 を使ってください。 このページは 3 つを同時に計算するので、期待値が MD5 でしか公開されていない場合でも、SHA-256 を控えておけば次回以降は強い比較ができます。配布側なら、SHA-256 を公開してください — sha256sum file (Linux)、shasum -a 256 file (macOS)、certutil -hashfile file SHA256 (Windows) で生成できます。すでに MD5 で運用しているシステムを直すときの優先順位ははっきりしています: 署名検証や認証に使っているなら最優先で置き換え、ファイルの重複判定やキャッシュキーに使っているだけなら急ぐ必要はありません — 後者は攻撃者が入り込む経路がないためです。パスワードの保存に MD5 や SHA-256 を使っているなら、それは別種の問題です — bcrypt / Argon2 に置き換えてください。 |
| 一致しない原因のほとんどは改ざんではない | 値が食い違ったとき、まず疑うべきは手順のずれです。頻度の高い順に: ダウンロードが途中で切れている (サイズを見れば一目瞭然です)、ハッシュを取る対象が違う (配布ページの値は .iso のものなのに、あなたは .zip を計算している)、期待値のコピーに余計な空白や改行が混じっている、大文字小文字の違い (これは無視されるので問題になりません)。そして見落としやすいのが Git 経由で取得したテキストファイルです — core.autocrlf が有効な Windows では、チェックアウト時に改行が CRLF に変換されるので、バイト列が変わりハッシュも変わります。ファイルの中身は「同じ」なのにハッシュは違う、という状態が正当に起こります。 |
まずファイルサイズを比べてください。 配布ページには通常バイト数が書かれています — サイズが違えばハッシュを計算するまでもなく、それは別のファイルか不完全なダウンロードです。再ダウンロードは、ブラウザではなく curl -L -O や wget -c で行うと、途中切れが起きにくく、起きても検出できます。テキストファイルを検証するなら、改行コードを揃えてから比較してください (改行コード変換)。そして最も重要な原則: 一致しなかったファイルは、原因が特定できるまで実行しないでください。「たぶんダウンロードの失敗だろう」と考えて実行するのは、検証しなかったのと同じです — もう一度落として、もう一度確かめるだけで済みます。 |
ハッシュを個人情報の匿名化に使わないでください。メールアドレスや電話番号のように取りうる値が事実上有限なものは、総当たりで元に戻せます — 携帯電話番号は日本国内で約 10 億通りしかないので、全部ハッシュ化して照合表を作るのに数分もかかりません。ハッシュ化した個人情報は、多くの法域で依然として個人情報です。本当に必要なら、ソルトではなく秘密のキーを使う HMAC にするか、そもそも可逆な暗号化にして鍵を管理してください。もうひとつ実務的な注意として、「同じファイル」の定義はフォーマットによって違います — ZIP はタイムスタンプを含むので、同じ内容を再圧縮すればハッシュは変わります。Docker イメージや tar も同様で、ビルドのたびに違うハッシュになるのは正常です。再現可能なハッシュが必要なら、タイムスタンプを固定する再現可能ビルドの仕組みが要ります。
📖 使い方
-
1
ファイルをドラッグ & ドロップダウンロード検証したいファイルをドロップエリアにドラッグします。最大 2 GB 程度まで対応。
-
2
ハッシュを自動計算MD5 / SHA-1 / SHA-256 が並列計算されます。大きなファイルではストリーミング処理されるため、全データをメモリに載せずに完了します。
-
3
公式の期待値と比較ダウンロード元サイトに記載されたハッシュ値をペーストすると、一致/不一致を色で表示します。
❓ よくある質問
SHA-3 や BLAKE2 には対応しますか?
ファイルはサーバーにアップロードされますか?
ダウンロードしたファイルが改ざんされていないか確認したい
MD5 を使っても安全ですか?
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。