公開鍵暗号
公開鍵と秘密鍵のペアを使う暗号方式。鍵を安全に共有できない問題を解決した。
概要
公開鍵暗号は、「暗号化する鍵」と「復号する鍵」を別のものに分けた暗号方式です。2つの鍵は数学的に対になっており、片方（公開鍵）は世界中に公開してよく、もう片方（秘密鍵）は本人だけが厳重に保管します。公開鍵で暗号化されたデータは、対になる秘密鍵でしか復号できません。つまり「私の公開鍵で暗号化して送ってください」と言うだけで、初対面の相手とも秘密のやり取りを始められるのです。
従来の暗号化（共通鍵暗号）は「送る側と受け取る側が同じ秘密の鍵を持つ」ことが前提でした。公開鍵暗号は「鍵の片方を公開してしまってもよい」という発想の転換であり、1976年のディフィーとヘルマンの論文、1977年の RSA の発明は、暗号の歴史でも屈指のブレイクスルーとされています。
現代のインターネットはこの仕組みなしには成立しません。HTTPS の接続開始、SSH の鍵認証、電子署名、ソフトウェアの署名検証、暗号資産——「会ったことのない相手を信頼する」場面のほぼすべてで、公開鍵暗号が土台になっています。
なぜ生まれたか
共通鍵暗号には「鍵配送問題」という根本的な矛盾がありました。安全に通信するには鍵の共有が必要ですが、その鍵を安全に共有するにはすでに安全な通信路が必要——鶏と卵の関係です。軍や銀行なら、信頼できる人間が鍵を物理的に運ぶことで解決できました。しかし不特定多数がネットワーク越しにつながる世界では、通信したい相手の数だけ事前の鍵共有が必要になり、まったくスケールしません。世界中のECサイトと買い物客が事前に鍵を郵送し合う、というのは明らかに非現実的です。
この行き詰まりを破ったのが「暗号化と復号を別の鍵にすれば、暗号化用の鍵は公開してしまえる」というアイデアでした。数学的には、一方向には簡単だが逆向きは極端に難しい計算（巨大な数の素因数分解や離散対数問題）を土台にしています。公開鍵から秘密鍵を割り出すことは、現実的な時間では計算できないほど難しい、という非対称性が安全性の根拠です。これにより「事前の秘密の共有なしに、安全な通信を始める」ことが史上初めて可能になりました。
詳細
秘密を送る — 暗号化としての使い方
最も基本的な使い方は機密性の確保です。受信者が鍵ペアを作り、公開鍵を世界に公開しておく。送信者はその公開鍵で暗号化して送る。復号できるのは秘密鍵を持つ受信者だけです。
ポイントは、秘密の情報（秘密鍵）が一度もネットワークを流れないことです。経路上のすべてが盗聴されていても、公開鍵と暗号文から平文を復元することはできません。
この非対称性は、実際に鍵ペアを作って暗号化・復号を試してみると実感できます。
公開鍵で暗号化したものは、対になる秘密鍵でしか戻せません。だから公開鍵は世界中に配ってよく、 秘密鍵さえ手元から出さなければ、誰とでも安全なやり取りを始められます。 この画面の暗号処理はすべてブラウザ標準の Web Crypto API による本物の RSA-OAEP です。
本人を証明する — 電子署名としての使い方
鍵ペアは逆向きにも使えます。秘密鍵で作った署名は、対になる公開鍵で誰でも検証できる——これが電子署名です。秘密鍵を持っているのは本人だけなので、「この署名を作れたのは本人である」「署名後に内容が改ざんされていない」ことを証明できます。実際にはデータ全体ではなく、ハッシュ化したダイジェストに署名するのが定石です。
この仕組みは、JWT の署名検証、Git のコミット署名、OSのアップデートの正当性確認など、至るところで使われています。
ハイブリッド方式 — TLSでの実際の使われ方
公開鍵暗号には弱点があります。計算が重く、共通鍵暗号の数百〜数千倍遅いのです。そこで実際のシステムでは、公開鍵暗号は「共通鍵を安全に取り決める」ためだけに使い、以降の大量データは高速な共通鍵暗号（AESなど）で守るハイブリッド方式が標準です。HTTPS を支える TLS のハンドシェイクがまさにこれで、接続の最初に公開鍵暗号ベースの鍵交換（現在は楕円曲線ディフィー・ヘルマン ECDHE が主流）でセッション用の共通鍵を確立し、その後の通信はすべて共通鍵暗号で行います。「重いが事前共有不要な公開鍵暗号」と「速いが鍵配送が課題の共通鍵暗号」の、きれいな役割分担です。
残る問題 — その公開鍵は本物か
公開鍵暗号は鍵配送問題を解決しましたが、新しい問題を生みました。「受け取った公開鍵が、本当に意図した相手のものか」をどう確認するかです。攻撃者が経路上で公開鍵をすり替えれば、通信をまるごと傍受できてしまいます（中間者攻撃）。この問題への答えが PKI（公開鍵基盤）です。信頼できる第三者（認証局、CA）が「この公開鍵は確かにこのドメインのものです」と電子署名した証明書を発行し、ブラウザはあらかじめ信頼した CA の署名を検証することで公開鍵の正当性を確認します。HTTPS のサイトで見られるサーバ証明書がこれです。一方 SSH では CA を介さず、初回接続時の鍵を記録して以後の変化を警告する方式（TOFU）が使われており、信頼の作り方にも設計の幅があります。
代表的なアルゴリズムと実務の注意点
代表格は素因数分解の困難性に基づく RSA と、より短い鍵で同等の強度を実現する楕円曲線暗号（ECDSA、Ed25519 など）で、現在の新規システムでは楕円曲線系が主流です。実務上の最大の急所は秘密鍵の管理で、秘密鍵が漏れればすべてが崩れます。リポジトリへの誤コミットは典型的な事故で、クラウドでは KMS や HSM に鍵を隔離するのが定石です。また、量子コンピュータが実用化すると現行方式は破られるため、耐量子計算機暗号（NIST が2024年に ML-KEM などを標準化）への移行が始まっていることも、頭の片隅に置いておきたい動向です。