ハッシュ・ID・乱数
ダウンロードしたファイルは配布元のハッシュと一致する？
使うツール
ダウンロードが最後まで進み、ファイル名も合っている。それでも、途中で壊れていないか、違う版を取っていないかは気になります。そんなとき、配布ページに並んでいる長い英数字が役立ちます。ハッシュ値は内容から計算する照合用の値です。ファイル名や更新日時の代わりに、実際のバイト列を比較する手掛かりになります。ただし、その値をどこから入手したかも同じくらい重要です。
まずはabcで、比較の手順を確かめる
SHAハッシュ計算を開き、文字列として小文字のabcを入力します。方式はSHA-256、出力は16進数にします。末尾に改行や空白は付けません。次の64文字と一致すれば、この小さな例では入力と方式をそろえられています。SHA-256の256bitを4bitずつ16進数で表すため、64桁になるわけです。大きなファイルでも桁数は同じで、長い値だから大きなファイルという意味ではありません。
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad方式をSHA-512へ変えると、同じabcでも別の値になります。Base64出力へ変えた場合は、同じハッシュのバイト列を別表記にした値です。比較するときは、内容だけでなく方式と出力表記もそろえます。SHA-256とSHA-512の値を見比べて一致しないことは、ダウンロード失敗の証拠にはなりません。
見た目が同じなのに、一致しない理由
次にabcの後ろへ改行を一つ足します。LFという1バイトの改行が追加されただけでも、結果はまったく違って見えます。ハッシュは文章の意味や見た目を理解せず、入力バイトをそのまま扱うからです。エディターで末尾改行を自動挿入した場合や、コピー時に空白を拾った場合も同じです。値の何割が似ているかから、変更箇所の多さを推定することはできません。
edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb日本語のファイルでは文字コードも確認します。同じ表示の文字でもUTF-8とUTF-16ではバイト列が違います。このツールの文字列入力はUTF-8として計算しますが、ファイル選択ではそのファイルのバイト列を扱います。文字コードや改行を変換してから比較すると、配布されたファイル自体の照合ではなくなります。配布ファイルの確認では、開いて保存し直す前のファイルを選ぶのが基本です。
配布ファイルを照合するときの順番
まず公式配布元で、対象の版、OS、CPU向けのファイル名とハッシュ方式を確認します。次に保存したファイルを選び、同じ方式で計算し、公開されている値と全体を照合します。先頭数文字だけが一致しても確認を終えません。ZIPと展開後の実行ファイル、Windows版とLinux版、同名の異なる版は、それぞれ別の内容です。配布元の値がどのファイルを指すかを取り違えないでください。
一致しなければ、まず比較対象と方式を見直します。それでも合わない場合は、不完全な取得や途中の変更などが考えられますが、ハッシュだけでは原因を特定できません。内容を実行して確かめるのではなく、信頼できる配布元からの再取得など、入手経路を確認します。ファイルがツールの上限を超える場合は、一部だけを切り取って元ファイルのハッシュとして扱わず、ローカルの対応ツールを使います。
一致した。でも、誰のファイルなのか
ファイルとハッシュ値を同じ不審なページから取得した場合、その二つが一致しても配布元の正しさは確認できません。内容を変えた人は、新しい内容のハッシュも計算できるからです。ハッシュ照合が強いのは、信頼できる経路で得た期待値と、手元の内容を比べる場面です。公式サイトのHTTPS接続や、配布元が提供する署名の確認とは役割が異なります。
また、一致は『安全なプログラム』という判定でもありません。配布元が意図して公開したものと同じでも、そのプログラムに脆弱性がないとは言えません。反対に、不一致だから必ず攻撃と断定するのも早計です。別の版や改行変換でも不一致になることを、abcの実験で確認しました。結果は内容の照合として受け取り、安全性や原因の判断を一段飛ばしで付け加えないようにします。
ハッシュ・CRC・暗号化を使い分ける
CRC32チェックサムでもデータの違いを調べられますが、攻撃者による改変への耐性を目的とした方式ではありません。配布元がSHA-256を提示しているなら、便利だからとCRC32へ置き換えず同じ方式で確認します。ハッシュは元のファイルへ戻す暗号化でもありません。パスワード保存についても、単純にSHA-256へ変換すれば適切な保存設計になるわけではなく、このファイル照合とは別の設計が必要です。
確認結果を残すなら、ファイルの版と名前、方式、比較した値の入手元、一致したかをまとめると再確認できます。秘密のファイル内容を共有する必要はありません。SheepDevでの計算はブラウザー内ですが、共有端末やクリップボードには別の注意が必要です。単に一致・不一致を眺めるだけでなく、『何を、何と、どの方式で比べたか』までそろえると、ハッシュが実用的な確認手段になります。
一致したハッシュの、比較元はどこから来た？
ダウンロードしたファイルと同じ場所に置かれたハッシュが一致すると、取得したbyte列がその表示値に対応することを確かめられます。しかし、配布元が改ざんされてファイルもハッシュも差し替えられた場合は、両方が一致しても安全性の証明になりません。比較の計算と、期待値を信頼できる理由は別です。公式の配布手順が署名検証などを求めているなら、それを省略してハッシュ一致だけで同等の確認をしたとは扱いません。このツールはファイルの出所や署名者を認証する機能ではありません。
比較前にアルゴリズムと出力形式もそろえます。SHA-256の16進文字列と同じダイジェストのBase64表記は、文字列としては一致しません。また、ファイルの内容をテキスト欄へコピーすると、文字コードや改行が変わる可能性があります。配布ファイルを照合する場合はファイル入力で元のbyte列を使い、本文を手で貼り直す操作とは区別します。ハッシュ欄に付いたファイル名や空白まで一緒に比較していないかも確認し、短い一致部分だけで成功と判断しないようにします。
ハッシュが違ったときは、直ちに攻撃と決めつけず、版違い、取得の失敗、展開前後の取り違え、改行変換などを切り分けます。ただし理由が分からないまま『だいたい同じ』として使用を進めることもしません。取得した版、ファイル名、byte数、使用アルゴリズム、期待値と実際の値を残せば、配布元の手順と照合できます。ハッシュは内容の違いを強く検出する道具ですが、違いが生じた理由を文章で説明してくれる道具ではありません。