「公開鍵」と「秘密鍵」という言葉は、TLS（HTTPS）・電子署名・パスキーなど至る所で出てきます。ここでは攻撃手順は扱わず、公開鍵暗号の考え方と、実務で押さえるべき守りの勘所を解説します。
公開鍵と秘密鍵の役割
鍵がペアになっていて、役割が逆になっているのが肝心です。
何に使われているか
暗号化（秘密のやり取り）
- 相手の公開鍵で暗号化して送る
- 対応する秘密鍵を持つ本人だけが復号できる
- TLSでは「共通鍵を安全に共有」する用途に使われる
電子署名（真正性の証明）
- 送信者が秘密鍵で署名を作る
- 受信者は公開鍵で検証し、本人性と改ざんの有無を確認
- TLS証明書・ソフト配布・パスキーの認証に使われる
実際の TLS（HTTPS） は、公開鍵暗号で共通鍵を安全に共有し、その後の通信は高速な共通鍵暗号で守るハイブリッド方式です。パスキー も、端末内の秘密鍵で署名し、サーバの公開鍵で検証することでフィッシングに強い認証を実現しています。
守りの勘所
暗号を自作しない
理論が正しくても、乱数の質・パディング・タイミング差などの実装の細部で破られる。標準プロトコルと枯れたライブラリを使い、独自実装を避ける。
秘密鍵を厳重に管理する
秘密鍵はコードやリポジトリに置かない。専用の保管（キーストア／シークレットマネージャ）に隔離し、漏洩時に**失効・再発行（ローテーション）**できる運用にする（→ 公開ディレクトリに秘密を置かない）。
鍵長・アルゴリズムを最新に保つ
推奨は時代とともに変わる。古い鍵長や非推奨アルゴリズムを放置せず、最新の推奨へ追従する。証明書は Let's Encrypt 等で自動更新する。
当サイトの視点：使う側の責任は『鍵の管理』にある
公開鍵暗号そのものは強力で、通常わざわざ破る必要はありません。現場の事故は暗号の数学ではなく、秘密鍵の置き場所・失効のしくみ・古い設定の放置といった運用面で起きます。当サイトも、秘密鍵は公開面の外に隔離し、漏洩を疑ったら「読まれた前提」で即ローテートする方針です。暗号は自作せず、標準に乗る——これが最も安全な近道です。
次に読む
よくある質問
Q公開鍵暗号と共通鍵（対称鍵）暗号はどう違いますか？
共通鍵暗号は暗号化と復号に同じ鍵を使うため高速ですが、その鍵を相手へ安全に渡す方法が課題になります。公開鍵暗号は公開鍵と秘密鍵のペアを使い、公開鍵は誰に配っても構いません。実際のTLS（HTTPS）では、公開鍵暗号で『共通鍵を安全に共有』し、その後の大量のデータは高速な共通鍵暗号で守る、というハイブリッド方式が使われます。
Q電子署名はどうやって『本物』だと確かめるのですか？
送信者が自分の秘密鍵でデータの署名を作り、受信者は送信者の公開鍵でその署名を検証します。秘密鍵は本人しか持たないため、検証が通れば『その公開鍵の持ち主が署名した／内容が改ざんされていない』と分かります。TLS証明書やソフトウェア配布の真正性確認も、この電子署名のしくみに支えられています。
Q自分で暗号を実装してもよいですか？
避けてください。暗号は理論が正しくても実装の細部（乱数の質、パディング、タイミング差など）で破られます。守りの原則は『自作しない・枯れたライブラリと標準プロトコルを使う』こと。鍵の生成・保管・失効（ローテーション）の運用を設計し、鍵長やアルゴリズムは最新の推奨に追従します。