同じ説明をされる、3つのもの
ハッシュも HMAC も電子署名も、たいてい「改ざん検知に使う」と説明されます。 間違いではありませんが、それだけではどれを使うべきか判断できません。
違いは、検証する側から見て何が分かるかにあります。 3つの問いを立てると、はっきりします。
段階的に、できることが増えていきます。 そのぶん必要なもの（鍵の管理）も増えます。順に見ていきます。
暗号化そのものについては 暗号化アルゴリズム体験デモで AES と RSA を扱いました。この記事は「秘密にする」ではなく「確かめる」ための仕組みです。
ハッシュ — 誰でも計算できる
任意の長さのデータから、決まった長さの値を作ります。 SHA-256 なら、どんなデータでも 256ビット（16進で64文字）になります。
振込先: 1234567 山田太郎 / 金額: 10000円 → a259c67fb5e156b7904ed971447305999d0d602c0ffa5ac20dfb9885e62f676c // 金額の 1 を 9 に変える 振込先: 1234567 山田太郎 / 金額: 90000円 → 42ef5c7c3081083225c287bcd3a217e0405d2823c0f8ba001695a653f2d59cdf
1文字変えただけで、256ビットのうち127ビット（約50%）が変わりました。 わずかな違いが全体に波及する——雪崩効果と呼ばれます。
同じ入力からは必ず同じ値が出る。値から元のデータを復元できない。 同じ値になる別のデータを見つけられない。この3つです。
できること、できないこと
| 用途 | なぜ使えるか |
|---|---|
| ダウンロードの検証 | 転送中に壊れていないか確かめられる |
| 重複の検出 | 同じ内容かどうかを短い値で比較できる |
| パスワードの保存 | 元に戻せないので、漏れても直接は使えない |
ハッシュが確実に守れるのは、偶然の破損です。 通信エラーやディスクの不良で内容が変わったことは、確実に分かります。
HMAC — 鍵を知る者だけが作れる
ハッシュに鍵を混ぜて計算します。 同じ文書でも、鍵が違えば別の値になります。
// 鍵 A で計算 → 19f68cff55b72f8aaf4835dcc612ef487c126de19d93075fa025f34c413fecce // 鍵 B で計算 → 6a65f1a6cff39bee7bd6905027297ea2...
鍵を知らなければ、正しい値を作ることも、検証することもできません。 これで「正しい相手が作ったものか」に答えられるようになります。
できないこと — 第三者への証明
鍵は2者で共有しています。つまり、 どちらも同じ値を作れます。
受け取った側が「この文書は相手が送ってきた」と主張しても、 自分で作った可能性が排除できません。 同じ鍵を持っているのだから、区別がつかない。 送信者は「私は送っていない」と言えてしまいます。
2者の間で完結する用途なら問題ありません。 サーバーが自分で発行した Cookie を、自分で検証する—— このような場合、第三者に示す必要がないからです。
電子署名 — 作れるのは1人、検証は誰でも
鍵を2つに分けます。秘密鍵と公開鍵です。
| 鍵 | 持つ人 | できること |
|---|---|---|
| 秘密鍵 | 本人だけ | 署名を作る |
| 公開鍵 | 誰でも | 署名を検証する |
作れるのは秘密鍵の持ち主だけ。しかし検証は誰でもできます。 この非対称性が、HMAC との決定的な違いです。
正しい文書 + 正しい公開鍵 → 検証成功 改ざんされた文書 → 検証失敗 別人の公開鍵で検証 → 検証失敗
デモ：3つを、同じ文書に適用する
文書を書き換えると、3つとも検証に失敗します。 そのうえで、鍵を変えたときの違いを見てください。
「鍵を変える」を押すと、HMAC と署名だけが検証に失敗します。 ハッシュは鍵を使わないので、影響を受けません。 この違いが、3つの性質の差そのものです。
どこで、どれが使われているか
| 場面 | 使われるもの | 理由 |
|---|---|---|
| 配布ファイルの検証 | ハッシュ | 破損の検知で足りる。値はHTTPSで伝える |
| パスワードの保存 | ハッシュ | 元に戻せないことが目的 |
| TLS の通信 | MAC（認証タグ） | 鍵は接続時に共有済み |
| API の認証 | HMAC | 双方が鍵を持つ。第三者は関与しない |
| Cookie の改ざん防止 | HMAC | サーバーが自分で検証できればよい |
| サーバー証明書 | 署名 | 誰でも検証でき、CAが作ったと示せる |
| ソフトウェアの配布 | 署名 | 開発元が作ったと、利用者全員が確認できる |
署名でも、防げないこと
署名が証明するのは、「この秘密鍵で作られた」ということだけです。
だから証明書があります。「この公開鍵は、このドメインの持ち主のものだ」という 対応づけを、認証局が保証する。 以前書いたとおり、 それもドメインの持ち主であることまでしか保証しません。
鍵が漏れた場合に備えて、失効の仕組みも用意されています。 CRL（失効リスト）や OCSP（オンラインでの状態確認）といったものです。 この検証がどこまで実際に行われているかは、別の主題になります。
まとめ
この記事のまとめ
- 3つとも改ざんを検知するが、答えられる問いが違う。
- ハッシュは誰でも計算できる。守れるのは偶然の破損。値自体を安全に伝える必要がある。
- 1文字変えると256ビット中127ビットが変わる（雪崩効果）。
- HMAC は鍵を知る者だけが作れる。なりすましを防げる。
- ただし鍵を共有した2者はどちらも同じ値を作れる。第三者に証明できない。
- 署名は秘密鍵で作り、公開鍵で検証する。作成者を特定でき、誰でも検証できる。
- 選び方は「誰が検証するか」。限られた相手なら HMAC、不特定多数なら署名。
- 署名が示すのは「この鍵で作られた」ことだけ。鍵の持ち主が本人かは証明書の役目。
