暗号の基礎（共通鍵・公開鍵・ハッシュ・署名）

そもそも何を守るのか

「暗号で守る」と一括りにされますが、守る対象は3つに分かれます。ここを混同すると「暗号化したのに安全じゃない」が起きます。

• 機密性（Confidentiality）：第三者に読まれない。盗聴対策。→ 暗号化（共通鍵・公開鍵）
• 完全性（Integrity）：途中で書き換えられていない。改ざん検知。→ ハッシュ・署名
• 真正性（Authenticity）：確かにその相手が作った。なりすまし防止。→ 電子署名・証明書

共通鍵暗号（対称）：速いが鍵配送が課題

暗号化と復号に同じ1本の鍵を使う方式です。送り手と受け手が同じ鍵を共有しておけば、その鍵で隠したり戻したりできます。仕組みが単純なぶん非常に高速で、大量データの暗号化に向きます（代表例は AES-GCM）。

弱点はただ一つ、**「その共通鍵をどうやって相手に安全に渡すか」**です。鍵そのものが盗まれたら全て解読されてしまうのに、鍵を送る経路がまだ暗号化されていない――という鶏と卵の問題（鍵配送問題）が生じます。

// 共通鍵暗号：同じ鍵で暗号化も復号もする（双方向）
const key = randomKey();                 // この1本を相手と「安全に」共有できるかが課題
const enc = encryptAES(plaintext, key);  // 暗号化
const dec = decryptAES(enc, key);        // 同じ鍵で復号 → 元に戻る

公開鍵暗号（非対称）：鍵配送を解く代わりに遅い

鍵を**「公開鍵」と「秘密鍵」のペアにしたのが公開鍵暗号です。公開鍵で暗号化したものは、対になる秘密鍵でしか復号できません。公開鍵はその名のとおり誰に配ってもよい**ので、共通鍵暗号の弱点だった鍵配送問題を解けます。

• 受け手は公開鍵を世界中に公開し、秘密鍵は自分だけが厳重に保管する。
• 送り手は受け手の公開鍵で暗号化して送る。復号できるのは秘密鍵を持つ受け手だけ。

ただし計算が重く、共通鍵に比べて桁違いに遅い。そのため大量データをそのまま公開鍵で暗号化することはせず、**「最初の鍵交換だけ」**に使うのが定石です（代表例は RSA / ECDH）。

両者は性質がほぼ対照的です。

ハッシュ：戻せない「データの指紋」

ハッシュ関数は、任意長のデータを固定長の短い値（ハッシュ値）に潰す一方向の関数です。暗号化と決定的に違うのは、元に戻せないこと。鍵もなく、ハッシュ値から元データを復元する手段はありません。

良いハッシュ関数（SHA-256 など）には次の性質があります。

• 一方向性：ハッシュ値から元データを求められない。
• 衝突困難性：違う入力が同じハッシュ値になるペアを、現実的に作れない。
• 雪崩効果：入力が1ビット変わるだけで、出力が全く別物になる。

sha256("hello")  // → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
sha256("hellp")  // → 一文字違うだけで全く別の値になる（雪崩効果）
// ハッシュ値から "hello" を逆算する方法は無い（一方向）

この「少しでも変われば指紋が変わる」性質から、ハッシュは**改ざん検知（完全性）**やファイルの同一性チェックに使われます。配布ファイルのチェックサム、Git のコミットID なども実体はハッシュです。

電子署名：本人＋改ざんを同時に保証

ここまでの「秘匿（暗号化）」とは目的が違います。電子署名が証明するのは、「確かにこの人が作った（真正性／なりすまし防止）」かつ「作られてから書き換えられていない（完全性／改ざん防止）」の2点です。中身を隠すものではないことに注意。

仕組みは公開鍵の「逆向きの使い方」です。

1. 署名（送り手）：データのハッシュを計算し、それを自分の秘密鍵で変換する。これが署名。データに添えて送る。
2. 検証（受け手）：受け取ったデータから自分でもハッシュを計算。一方、署名を送り手の公開鍵で復元し、両者が一致するか比べる。

// 署名する側（秘密鍵は本人だけが持つ）
const h   = sha256(message);          // まずハッシュ（＝指紋）を取り
const sig = signWithPrivateKey(h);    // 自分の秘密鍵で署名

// 検証する側（公開鍵は誰でも持てる）
const ok =
  sha256(message) === recoverWithPublicKey(sig); // 一致すれば「本人＆未改ざん」
// → 1ビットでも改ざんされればハッシュがずれ、検証に落ちる
// → 秘密鍵を持たない第三者は正しい署名を作れない＝なりすませない

秘密鍵を持つ本人しか作れない署名が、誰でも持てる公開鍵で検証できる。だから「本人性」が示せます。同時に、署名はハッシュに対して作られているので、中身が1ビットでも変わればハッシュがずれ、改ざんが必ずバレます。なお JWT の署名や、TLS のサーバ証明書（CA が秘密鍵で署名し、ブラウザが CA の公開鍵で検証する）も、この電子署名そのものです。

4つの道具を一望する

守る対象（機密性・完全性・真正性）と鍵の持ち方で整理すると、役割の違いがはっきりします。

つまずきポイント

実務でハマりやすい誤解を、ここまでの要点として整理します。

• 「暗号化したから安全」ではない：暗号化が守るのは機密性だけ。改ざん検知には AEAD（AES-GCM 等）や署名、なりすまし防止には署名／証明書が別途要ります。
• 鍵を自分で実装しない：暗号の事故は「アルゴリズムが弱い」より「使い方を間違える」（IV の使い回し、ECB モード、自前のソルト生成ミスなど）で起きます。標準ライブラリ・確立した実装に任せ、自作しないのが鉄則です。
• 乱数の質が命：鍵やソルト、IV は**暗号論的に安全な乱数（CSPRNG）**で生成します。Math.random() のような予測可能な乱数を鍵に使うと、暗号強度がゼロになります。
• 鍵の寿命と保管：鍵やパスワードのハッシュは漏洩を前提に設計します。ローテーション（定期更新）と、秘密鍵を**秘密管理（KMS / シークレットマネージャ）**に置くことを前提に。

関連トピックとして、署名済みトークンの扱いは Cookie・セッション・JWT、暗号化通信の全体像は TLS / SSL、パスワードの保存実務は パスワードの安全な保存 を参照してください。