先に読むと理解しやすい記事：エンコード・暗号化・ハッシュ

鍵は暗号の処理を決める秘密または公開の値

暗号の鍵は、暗号化、復号、署名などの計算に使う値です。手順が公開されていても、必要な秘密の鍵がなければ内容を読んだり正しい証明を作ったりしにくいように設計します。

共通鍵暗号では送受信する側が同じ秘密の鍵を使います。公開鍵暗号では、対応する公開鍵と秘密鍵の組を使います。公開鍵は他人へ渡せますが、秘密鍵は利用者やシステムが保護します。用途によって、それぞれの鍵でできる処理は異なります。

参照：出典 s1 / 出典 s2

共通鍵暗号では同じ鍵で暗号化と復号を行う

Aさんが文書を共通鍵で暗号化すると、Bさんも同じ鍵を使って復号します。AESなどが代表的です。大量のデータの保護に使えますが、Bさんへ鍵を安全に渡す方法が必要です。

鍵をメール本文に、暗号文を同じ相手が読める別メールに分けただけでは、その相手による復号を防げません。鍵の配布と保存の両方を設計します。暗号文の改ざんも検出するAES-GCMなどの方式では、nonceという暗号化ごとに用意する値などの使用条件も守ります。たとえばAES-GCMでは、同じ鍵でnonceを再使用すると機密性や改ざん検出が損なわれるため、重複させません。

参照：出典 s1 / 出典 s4 / 出典 s5

公開鍵による暗号化では受信者の鍵を使う

公開鍵暗号で内容を秘密に届ける例では、AさんがBさんの公開鍵を使って暗号化し、Bさんが自分の秘密鍵で復号します。RSA-OAEPなどの暗号化方式があります。公開鍵を知る第三者もBさん宛ての暗号文を作れるので、暗号化だけで送信者がAさんだとは確認できません。

公開鍵が本当にBさんのものか確認する必要もあります。攻撃者の公開鍵をBさんのものと信じて暗号化すると、攻撃者が対応する秘密鍵で読めます。証明書など、鍵と相手を結び付ける仕組みが重要になります。

参照：出典 s1

署名は秘密鍵で作り、公開鍵で確かめる

署名では、Aさんが自分の秘密鍵で文書へ署名し、BさんがAさんの公開鍵で検証します。内容の秘密ではなく、改ざんされていないか、対応する秘密鍵で作られたかを確認する用途です。Ed25519やECDSAなどの署名方式があります。

「秘密鍵で暗号化すれば署名になる」と一括して説明すると、暗号化専用と署名専用の方式の違いを見失います。署名は専用の署名・検証手順を使います。鍵も、アルゴリズムや用途に合うものを選びます。

参照：出典 s2

鍵共有は大きな本文をそのまま暗号化する処理ではない

ECDHなどの鍵共有では、自分の秘密鍵と相手の公開情報から、共通の秘密を計算します。その秘密から通信で使う共通鍵を導き、本文は別の共通鍵暗号で保護する構成にできます。

TLSなどでは複数の方式を組み合わせます。公開鍵暗号という名前から、すべての通信本文を証明書の公開鍵で直接暗号化していると考えないようにします。相手の認証、鍵共有、本文の保護にはそれぞれ役割があります。

参照：出典 s3 / 出典 s4

鍵の公開範囲と用途を確認する

確認問題：公開鍵を配ったら、誰でもその持ち主の署名を作れるでしょうか。適切な方式と鍵の管理の下では、公開鍵から署名は作れません。署名を作る秘密鍵が必要です。

ただし秘密鍵が漏れれば、攻撃者が持ち主の署名を作れます。鍵の生成は暗号用乱数を使うライブラリーに任せ、アクセス権、バックアップ、交換、失効まで管理します。鍵の種類だけで運用上の安全性は決まりません。

参照：出典 s2 / 出典 s4

出典・確認範囲

  1. [s1] SubtleCrypto: encrypt() methodMDN / 確認日 2026-11-03
  2. [s2] SubtleCrypto: sign() methodMDN / 確認日 2026-11-03
  3. [s3] SubtleCrypto: deriveKey() methodMDN / 確認日 2026-11-03
  4. [s4] Cryptographic Storage Cheat SheetOWASP / 確認日 2026-11-03
  5. [s5] AesGcmParamsMDN / 確認日 2026-11-03
未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。