1. 名前が同じファイルと内容が同じファイルは違う
ダウンロードしたインストールファイルの名前と容量が案内ページと同じだと、正しく受け取れたと思いがちです。しかし、名前は変えられ、同じ容量でも内容は異なることがあります。逆に、写真ファイルを別の名前でコピーしたからといって、その中のバイトが必ず変わるわけではありません。そこで、ファイルの内容を決まった計算にかけ、短い値で表すハッシュが比較に役立ちます。確かめたいのは、名前がもっともらしいかではなく、受け取ったバイトが信頼できる基準と一致するかです。バックアップファイルを別の記憶装置へ移したときも、同じ問いを立てられます。
SHA-256は、入力から256ビットのハッシュ値を作るアルゴリズムです。一般に16進数64桁で表します。16進数の1桁が4ビットを表すためです。ファイルが大きくなっても、結果の長さがファイル容量に比例して増えるわけではありません。同じバイトに同じアルゴリズムを適用すれば、同じ結果になります。ただし、長さが有限の値にあらゆる入力を対応させるので、異なる入力が同じ値を持つ衝突は原理上存在します。実用的な比較に使えることと、すべてのファイルに数学的に一意の名前を付けることは区別する必要があります。RFC 6234は、SHA-256を含むハッシュの計算と試験用資料を提供しています。
2. ハッシュは暗号化でもファイルの縮小コピーでもない
ハッシュ値が分かっても、元の文書や写真を復元するための解読ボタンが手に入るわけではありません。暗号化は適切な鍵で原文を取り戻せるように設計されていますが、暗号学的ハッシュは原文を復元する保存形式ではありません。だからといって、ハッシュだけを公開すれば、あらゆる入力が秘密として守られるという意味でもありません。入力の候補が少ししかなければ、それぞれのハッシュを計算して比較できます。そのため、ファイル確認用のSHA-256の説明を、パスワードをそのままハッシュして保存すれば十分だという助言に広げてはいけません。完全性の確認、秘密の保持、パスワードの保管は、必要な条件が異なる作業です。
ファイル全体を計算する場合、画面に見える文字だけを比べているのでもありません。同じ文章に見えても、改行方法や文字エンコーディング、文書内部のメタデータが違えば、バイトは異なることがあります。圧縮ファイルを展開して得たファイルは、元の圧縮ファイルとは別の比較対象です。文字の正規化や改行の変更をしてから計算すれば、その変換後の資料のハッシュが得られます。配布者が元の圧縮ファイルの値を示しているなら、まず受け取った圧縮ファイル自体と比べる必要があります。この区別は、既存のUnicode・UTF-8の記事で扱った表示とバイトの違いを、実際のファイル検証に当てはめる例です。
3. ダウンロードしたファイルは同じアルゴリズムと基準値で比べる
検証前に、制作者の公式な配布案内で、対象のバージョン、OS、ファイル名、ハッシュアルゴリズムをまとめて確認します。別のOS向けのインストールファイルや別バージョンの値は、比較の基準にはなりません。PowerShellでは、Get-FileHash -LiteralPath '.\download.zip' -Algorithm SHA256でローカルファイルを読み取って計算できます。このコマンドは、そのパスの内容を実行するものではありません。Microsoftの公式文書は、ファイルの内容から値を計算し、名前の変更だけでは値が変わらないと説明しています。ファイル名とパスは実際に受け取ったファイルに合わせて変更し、計算中はファイルを編集しません。
出力のHash欄にある64桁すべてを、配布者が公開したSHA-256の値と照合します。先頭や末尾の数桁だけが同じでも、全体が一致すると判断してはいけません。16進数の英字の大文字と小文字は同じ数を表しますが、別の文字が混ざっていたり桁数が足りなかったりする場合は、まずコピーした値を確認します。一致という結果は、信頼した基準値と受け取ったバイトとの整合性を裏付けます。文書の事実関係やプログラムの品質、悪意ある動作まで調べた結果ではありません。基準となるファイル自体に問題があれば、それと全く同じコピーも同じハッシュを持ちます。計算が成功したことと、ファイルを使ってよいかは別に判断する必要があります。
4. 不一致は原因を調べる合図であり、攻撃の確定的な証拠ではない
例えば、昨日受け取った配布ファイルを今日の案内に載っている値と比べたら、異なっていたとしましょう。これは実際の事故記録ではなく、説明用の例です。まず、案内が同じバージョンを指しているか、別の機器向けのファイルを受け取っていないか、ダウンロード完了前に計算していないかを確認します。圧縮ファイルではなく展開後のファイルを計算したり、エディターが文書を保存し直したりした可能性もあります。このように、比較対象が変わった場合と、転送・保存の過程で内容が変わった場合を分ける必要があります。値が異なるという事実だけでは、誰がいつ何を変えたかは分かりません。
一致しないインストールファイルを、確認のためにすぐ実行するのではなく、公式の配布案内と基準値を再確認し、新たに受け取ったファイルと比べます。それでも異なる場合は、配布者の訂正案内やサポート窓口を確認し、結果を残す方がよいでしょう。記録には確認時刻、出所のURL、ファイルのバージョン、アルゴリズム、計算値をまとめて書きます。繰り返した計算の結果が同じなら、現在のローカルファイルを同じ方法で読んだ手がかりにはなりますが、配布者が掲載した値の誤りや配布経路の問題まで解決するわけではありません。期待した値で基準の記録を上書きすると、その後に変化があったかを判断する根拠を失います。
5. 基準値を信頼する根拠と電子署名の役割
攻撃者がファイルと一緒に案内されるハッシュ値も変えられるなら、改変したファイルのハッシュを計算し、新しい基準として載せられます。NIST SP 800-175Bは、鍵や署名を使わずハッシュだけを使う場合の、この限界を説明しています。公式URLのHTTPSページから値を得ることは、出所と転送経路の確認に役立ちますが、配布サーバー自体が侵害された場合までなくす保証ではありません。重要なのは、ハッシュ文字列が長く見えるかではなく、どこでどのような信頼の手続きを経て基準を得たかです。同じ画面からコピーした二つの値が合うという事実だけでは、制作者の身元は確認できません。
電子署名では、信頼できる方法で入手した公開鍵などを用いて、署名と資料の関係を検証します。配布者が署名の確認手順を提供しているなら、鍵の所有者やフィンガープリントの確認方法まで含めて、公式案内に従います。出所の不明なファイルの横で初めて見た公開鍵をそのまま信頼しても、信頼の出発点は解決しません。共有の秘密鍵を使うHMACも、通常のハッシュとは異なる認証の道具ですが、すべてのダウンロードに任意で付け加えて解決する機能ではありません。署名が有効でも、プログラムに欠陥がないことや文書の内容が真実であることにはなりません。バイトの一致、出所の確認、内容の評価はつながっていますが、それぞれ確かめる根拠が必要です。
6. バックアップと共同作業では比較範囲も記録する
個人の写真のバックアップでは、元ファイルのSHA-256を保存してコピーと比較すると、移動中に変化が起きたかの確認に役立ちます。その際、基準の一覧も元ファイルと一緒に失われたり上書きされたりしないように保管します。写真管理ソフトが回転情報や撮影メタデータを書き直した場合、見える写真が似ていてもファイルのハッシュは変わることがあります。したがって、目的がバイト単位での保存なのか、編集後の写真の意味が同じかの確認なのかを、まず区別します。フォルダー全体を確認するには、一つのファイルのハッシュだけで終わらせず、含めるファイルの一覧、相対パス、それぞれの値を一緒に管理する必要があります。
共同作業での文書レビューでも、ハッシュはレビューした版を固定する目印にできます。しかし、ハッシュの一致を調べることは、誰かが実際に全文を読んだり翻訳を照合したりした証拠の代わりにはなりません。何をいつどのような方法でレビューしたかを記録し、その記録を該当ファイルの値に結び付けてこそ意味があります。この記事の図は、バイトの比較、基準値の出所、検証の範囲を整理した独自の説明用の図であり、実際の測定結果や証明書ではありません。ファイルを確認するときは、対象とアルゴリズム、基準の出所、結果から述べられる範囲を順に記録してみてください。そうすれば、一致と不一致を大げさに解釈せず、次の人が同じ手順を再現できます。