共通鍵暗号と公開鍵暗号の違い｜図解で仕組み比較

ブラウザでHTTPSのサイトを開いた瞬間、画面には見えないところで「いま誰と鍵を決めたのか」と「その後の本文をどの鍵で守るのか」が一気に走ります。
この記事では、まず共通鍵暗号の仕組みと量子コンピュータ時代に何が変わるかの節を先に参照すると、以降の議論の流れがつかみやすくなります。
筆者がこの流れを追うとき、最初に見るべきなのは、共通鍵暗号と公開鍵暗号が「同じ鍵か、別の鍵か」「何に強いか」で役割分担されていることです。

さらに、なぜ方式が二つに分かれたのかを歴史と技術の流れからたどり、いまのTLS 1.3やPGPでどう併用されているかまでつなげます。
暗号は「どちらが上か」を競う話ではなく、弱点を補い合う組み合わせとして見ると、一気に理解が進みます。

共通鍵暗号と公開鍵暗号の違いを先に一枚で整理

最初に、両者の違いを一枚で置いておきます。
名前は似ていますが、設計思想ははっきり分かれています。
共通鍵暗号（symmetric-key cryptography）は、送る側と受け取る側が同じ鍵を持って暗号化と復号を行う方式です。
これに対して公開鍵暗号（public-key / asymmetric cryptography）は、誰に見せてもよい公開鍵と、本人だけが持つ秘密鍵のペアを使います。
公開鍵で閉めて、秘密鍵で開ける。
この役割分担が出発点です。

まずは比較表で全体像を見る

この表で見てほしいのは、どちらが優れているかではなく、得意な仕事が違うという点です。
AESやChaCha20は本文データを流し続ける場面に向きます。
一方でRSAやECCは、最初に相手と安全に鍵を決めたり、本人性を示す署名を作ったりする場面で力を発揮します。

鍵の流れを図でつかむ

共通鍵暗号のイメージは、一本の鍵を二人で共有する形です。
送信者がその鍵で閉め、受信者が同じ鍵で開けます。
直感的で、処理も速いです。
ただし、その一本をどうやって安全に渡すのかが難所になります。
郵送するのか、対面で渡すのか、別経路で送るのかという問題が必ず出ます。

公開鍵暗号は、南京錠で考えると腑に落ちます。
南京錠を閉めるための側は配ってよく、開けるための側は本人だけが持つ、という発想です。
受信者は公開鍵を配布しておき、送信者はその公開鍵でメッセージを保護します。
開けられるのは対応する秘密鍵の持ち主だけです。
ここが暗号の美しいところなのですが、公開鍵を配れるからといって、その鍵が本当に本人のものかという問題は別に残ります。
TLSでは証明書で、PGPでは指紋確認などで、この真正性を支えています。

鍵の本数は人数が増えると一気に効いてくる

筆者が初学者に説明するときは、2人、4人、10人のグループチャットを紙に書いてもらうことがあります。
AさんとBさんだけなら、共通鍵は1本で済みます。
4人になると、A-B、A-C、A-D、B-C、B-D、C-D と組み合わせが増え、必要な鍵は6本です。
10人まで増えると45本になります。
頭の中だけだと見落としがちですが、紙に線を引くと「これは管理が急に大変になる」と実感できます。

相互に秘密のやり取りをする全員の組み合わせに個別の共通鍵を持たせるなら、必要な鍵数は n×(n−1)÷2 個 です。
2人なら1個、4人なら6個、10人なら45個になります。
共通鍵暗号そのものは高速でも、参加者が増えると鍵配送と鍵管理のコストが先に効いてくるわけです。

だから実務ではハイブリッドになる

現代の通信で主流なのは、ハイブリッド暗号（hybrid encryption）です。
考え方はシンプルで、最初の鍵共有だけを公開鍵暗号系の仕組みで安全に行い、その後の本文は共通鍵暗号で一気に守ります。
つまり、遅いけれど鍵を安全に渡せる仕組みと、速いけれど最初の受け渡しが苦手な仕組みを、役割分担でつないでいます。

TLSが典型例です。
ブラウザがHTTPSのサイトに接続するとき、最初のハンドシェイクでは公開鍵暗号、鍵共有、証明書検証の仕組みが動き、その結果としてセッション鍵が決まります。
その後に流れるHTML、画像、ログイン後の通信本体は、共通鍵暗号で保護されます。
TLS 1.3では鍵共有の設計も整理され、通信本体の暗号スイートと、最初の鍵共有の仕組みを分けて考える形が明確になりました。

PGPも同じ発想です。
メール本文そのものを公開鍵暗号で丸ごと暗号化するのではなく、まず本文は共通鍵で暗号化し、そのセッション鍵だけを受信者の公開鍵で包みます。
実データの暗号化を高速な方式に任せるからこそ、長い本文や添付ファイルも現実的なコストで扱えます。

代表的なアルゴリズム名も、この役割分担で覚えると混乱しません。
大量データ側にはAESやChaCha20、鍵共有や署名の側にはRSAやECCが並びます。
とくにECCは、同じ安全性水準を短い鍵長で実現しやすい性質があり、現在のTLSでは鍵共有や証明書の文脈で存在感が大きい方式です。
ここから先は、それぞれの方式がなぜその役割に向いているのかを順に掘っていきます。

なぜ2種類の暗号が必要になったのか

共通鍵暗号が先に実用化されたのは、とても自然な流れです。
同じ鍵で閉めて、同じ鍵で開けるという仕組みは直感的で、処理も速いからです。
実際、本文データを守る仕事では、いまでもAESやChaCha20のような共通鍵暗号が主役です。
ところが、ここには最初から一つの難所がありました。
その鍵を、相手にどうやって安全に渡すのかという問題です。
暗号アルゴリズムそのものが強くても、鍵を渡す段取りで盗み見られたら意味がありません。
この「中身を守る技術」より前に、「鍵を安全に共有する手順」が詰まりやすい。
ここが鍵配送問題の本質です。

この壁は、相手が一人増えるだけでもすぐ現実的な負担になります。
二人だけなら秘密の合言葉を一つ決めれば済みますが、全員がそれぞれ別々に秘密のやり取りをしたいとなると話は変わります。
参加者が n 人いると、必要な共通鍵は n×(n−1)÷2 個です。
組み合わせの数だけ鍵が要るからです。
4人で6個、10人で45個という増え方を見ると、暗号の計算そのものより、鍵束の管理のほうが先に苦しくなる感覚がつかめます。

日常の身近な状況に置き換えて想像してみましょう。
たとえばグループチャットで秘匿のやり取りをしたいとします。
AさんとBさんの鍵、AさんとCさんの鍵、BさんとCさんの鍵……と数え上げると、人数が増えるほど鍵の本数は急速に増え、管理負荷が現実問題として顕在化します。
こうした具体的な絵があると、共通鍵の事前共有が人数に弱い理由が実感としてつかめます。

もっとも、公開鍵暗号は魔法ではありません。
秘密の鍵を運ばなくてよくなる代わりに、その公開鍵が本当に相手のものかという別の課題が現れます。
攻撃者が偽物の公開鍵を差し出しても、見分けがつかなければ意味がないからです。
そこでTLSでは証明書によって公開鍵の持ち主を結び付け、PGPではフィンガープリントや信頼のつながりで補います。
鍵配送問題を解いたあとも、真正性確認という次の問題が待っているわけです。

この流れを見ると、なぜ現代の暗号が二種類に分かれたまま残っているのかが腑に落ちます。
共通鍵暗号は高速なので大量データの保護に向き、公開鍵暗号は事前共有なしで鍵を決めたり署名したりする場面で効きます。
片方がもう片方を追い出したのではなく、それぞれが別の弱点を埋める形で発展してきた、という理解が実態に近いです。
次にTLSやPGPの中身を見ると、この役割分担がそのまま設計に現れていることがわかります。

同じ鍵で暗号化・復号の流れ

共通鍵暗号は、送る側と受け取る側が同じ鍵を持っているところから始まります。
送信者はその鍵で平文を暗号化し、受信者は同じ鍵で復号します。
考え方としては、同じ番号の南京錠で閉めて、同じ鍵で開けるのに近いです。
ここで守るべき核心はアルゴリズム名そのものより、その鍵が第三者に漏れていないことにあります。

直感をつかむための古典例として、筆者はHELLOを鍵=3でずらす手遊びを最初に一瞬だけ試します。
H を K に、E を H に、L を O にずらしていくと、KHOORになります。
復号では逆に 3 文字戻せばHELLOに戻ります。
これで「同じ鍵で変換し、同じ鍵で戻す」という感覚はつかめます。
ただし、これはあくまで仕組みの入口です。
実務でこの程度の変換を使うことはなく、実際の通信や保存データではAESやChaCha20のような現代暗号に切り替わります。

現代の共通鍵暗号でも、流れの骨格は同じです。
まず送信者と受信者が秘密の鍵を共有し、その鍵を入力として暗号化します。
受信者は同じ鍵を使って元のデータを取り出します。
ここが暗号の美しいところなのですが、計算の中身は複雑でも、利用者が押さえるべき構図は驚くほど単純です。
「同じ秘密を両者だけが知っているので、その秘密を持つ相手だけが読める」という一点に集約されます。

ただし現代の方式では、鍵だけでなくノンスやIVのような値、そして動作モード（mode of operation）も一緒に考えます。
AESのようなブロック暗号（block cipher）は、そのまま使うのではなくGCMやCTRのような動作モードと組み合わせて運用します。
単に「AESで暗号化した」というより、「AES-GCMで本文を保護した」と捉えたほうが実態に近いです。

AESとChaCha20の代表例

現代の代表例として、まず押さえたいのがAESです。
AESはブロック暗号（block cipher）で、データを128ビット単位のブロックに区切って処理します。
鍵長は128/192/256ビットの3種類が定義されており、AES-128AES-192AES-256という呼び方はこの鍵長の違いを示しています。
本文データを守る場面では、単体のAESというよりAES-GCMのように動作モード込みで登場することが多く、暗号化と改ざん検知をまとめて扱える構成が主流です。

もう一つの柱がChaCha20です。
こちらはストリーム暗号（stream cipher）系の方式で、鍵から疑似的な乱数列を作り、その列と平文を組み合わせて暗号化します。
ChaCha20はソフトウェア実装との相性がよく、専用命令に強く依存しない環境でも扱いやすい構造を持っています。
実務ではPoly1305と組み合わせたChaCha20-Poly1305として使われることが多く、TLSでもよく見かける名前です。

筆者が共通鍵暗号を身近に感じる場面としてよく挙げるのが、ブラウザの開発者ツールです。
ChromeやFirefoxで HTTPS のページを開き、接続情報をたどると、AES-GCMやChaCha20-Poly1305を含むスイート名に出会えます。
そこで見えている名前は、まさに通信の本文を守っている共通鍵側の主役です。
前段で鍵共有に公開鍵暗号が使われていても、ページ本体の HTML や画像を流す段階では共通鍵暗号がバトンを受け取っている、と目で追えます。

AESとChaCha20はどちらも共通鍵暗号ですが、内部の作りは異なります。
AESは固定長ブロックを変換する設計、ChaCha20は連続した鍵ストリームを生成する設計です。
にもかかわらず、利用者から見た役割は共通しています。
どちらも「大量の本文データを高速に暗号化する」ための現代的な選択肢であり、TLS、ファイル暗号、ストレージ保護の現場で日常的に使われています。

大量データに向く理由と用途

共通鍵暗号が大量データに向く理由は、処理の重心が「高速に同じ型の計算を繰り返す」ことにあるからです。
公開鍵暗号のように大きな整数演算を主役に据える方式と比べると、本文を何KB、何MBと連続して流す場面で効率の差がはっきり出ます。
AESはハードウェア支援とも相性がよく、CTR系の考え方を使うモードやGCMでは並列処理とも噛み合います。
ChaCha20も連続データを流す用途と相性がよく、通信本文の保護に載せやすい構造です。

この「本文をまとめて守るのが得意」という性質は、使い道を見ると納得できます。
Web のTLSでは、接続の立ち上げで鍵が決まったあと、HTML、CSS、画像、APIレスポンスといった本体データを共通鍵暗号で保護します。
動画配信でも、細かく分割されたデータ片を次々に扱うため、高速な共通鍵暗号が前提になります。
ディスク暗号でも同じで、保存領域全体に対して連続的に暗号化と復号を繰り返すには、共通鍵暗号の速度がものを言います。

一方で、共通鍵暗号は速い代わりに、最初にその鍵をどう共有するかという課題を抱えます。
前のセクションで見た通り、現代のシステムはそこを公開鍵暗号や鍵共有プロトコルで補い、実データの保護そのものは共通鍵暗号に任せます。
つまり、共通鍵暗号は「単独で万能」だから主役なのではなく、本文処理の担当として突出して適任だから主役なのです。

実務の視点で見ると、暗号アルゴリズム名を覚えるだけでは足りません。
AESならどの動作モードを選ぶのか、GCMのように認証付きで使うのか、CTRのような構成にするのかで、使い方の意味が変わります。
ChaCha20でも、単体名だけでなくChaCha20-Poly1305まで含めて理解したほうが、通信やアプリの設計図が読みやすくなります。
共通鍵暗号を「同じ鍵で戻せる仕組み」として直感でつかみつつ、現代ではその上にモードや認証の層が乗っている、と捉えると現場の実装とずれません。

公開鍵暗号の仕組みを図解で理解する

暗号化と署名の2つの向き

公開鍵暗号は、1組の鍵ペアを使います。
片方は外に配ってよい公開鍵（public key）、もう片方は持ち主だけが保持する秘密鍵（private key）です。
ここで最初につまずきやすいのが、「どちらの鍵で何をするのか」が用途によって逆向きになる点です。

まず、秘密を送りたい場面では、受信者の公開鍵で暗号化し、受信者の秘密鍵で復号します。図にすると次の流れです。

送信者 平文メッセージ ↓ 受信者の公開鍵で暗号化 ↓ 暗号文 ↓ 受信者だけが持つ秘密鍵で復号 ↓ 元の平文

この向きだと、公開鍵を知っている人は暗号文を作れても、平文に戻せるのは秘密鍵の持ち主だけです。
公開鍵を配っても秘密そのものは漏れない、という役割分担になっています。

一方、電子署名（digital signature）では目的が「秘密にすること」ではなく「本人が作ったと示すこと」に変わります。
そのため向きが反転します。
秘密鍵で署名し、公開鍵で検証するのが基本です。

送信者 メッセージ ↓ 送信者の秘密鍵で署名 ↓ 署名付きメッセージ ↓ 受信者が送信者の公開鍵で検証 ↓ 改ざんの有無と、対応する秘密鍵の持ち主が作ったことを確認

ここが暗号の美しいところなのですが、同じ「公開鍵と秘密鍵のペア」でも、暗号化では機密性を作り、署名では真正性と完全性を支えるというように、役割が切り替わります。
直感に反するかもしれませんが、「公開鍵で暗号化する」と「公開鍵で検証する」は別の仕事です。
前者は秘密を守るため、後者は署名を確かめるために使います。

公開鍵暗号の領域には、暗号化や署名だけでなく、その場で共有鍵を合意する仕組みも含まれます。
Diffie-HellmanやECDHEはその代表で、「相手の公開情報を使って、通信のたびに共通鍵を作る」発想です。
現代のTLS 1.3では、この種の鍵共有が中心に据えられています。
つまり公開鍵暗号は、「データを直接暗号化する道具」でもあり、「高速な共通鍵暗号に渡すための共有鍵を作る道具」でもあります。

ただし、もう一段考えるべき点があります。
その公開鍵が本当に相手のものかという問題です。
公開鍵そのものは配布できますが、偽物の公開鍵を本物だと信じてしまえば意味がありません。
そこで実運用では、Web なら証明書、SSH や PGP ならフィンガープリントの確認といった仕組みが別に必要になります。
公開鍵暗号は便利ですが、「公開されている鍵が本物である保証」まで自動で与えてくれるわけではありません。

南京錠・郵便受けの比喩で理解

公開鍵と秘密鍵の役割分担は、数学の話だけで追うより、物のイメージに置き換えると腹に落ちます。
筆者が人に説明するときによく使うのが、南京錠と自宅ポストの比喩です。

南京錠で考えると、持ち主が鍵穴つきの南京錠をたくさん配っている状態を思い浮かべると近いです。
送り手はその南京錠を使って箱を閉めることができます。
しかし、開けることができるのは対応する鍵を持つ本人だけです。
これが「公開鍵で暗号化し、秘密鍵で復号」の感覚です。
誰でも閉められるが、開けられるのは持ち主だけ、という非対称な役割が見えます。

もう少し日常の手触りに近いのが、郵便受けの投函口です。
筆者はこの説明をするとき、自宅のポストを思い浮かべます。
近所の誰でも投函口から手紙を入れられますが、奥に入った郵便物を取り出せるのは、扉の鍵を持つ本人だけです。
この感覚を一度つかむと、公開鍵と秘密鍵の分担がぐっと具体的になります。
投函口が公開鍵、取り出し用の鍵が秘密鍵です。
公開鍵は広く見えていて構わないのに、秘密鍵だけは持ち主の手元から出してはいけない理由も、そのまま理解できます。

署名はこの比喩を少しひねると見えてきます。
たとえば封筒の封印や実印のように、「これは確かに本人が付けた印だ」と確認したい場面です。
秘密鍵で署名する行為は、本人しか持てない印章を押す感覚に近く、公開鍵での検証は、その印が対応する本物かを誰でも確かめられる仕組みだと捉えると混乱しません。
暗号化の比喩であるポストや南京錠と、署名の比喩である印章は、同じ鍵ペアが別方向に働いていると考えると整理できます。

RSAとECCの位置づけ

公開鍵暗号の代表例としてまず出てくるのが、RSA（Rivest–Shamir–Adleman）とECC（Elliptic Curve Cryptography）です。
どちらも公開鍵暗号の仲間ですが、数学の土台と実務での得意分野に違いがあります。

RSAは古典的で、公開鍵暗号を学ぶ入口として扱いやすい方式です。
整数の掛け算は簡単でも、そこから素因数分解して元に戻すのは難しい、という非対称性を土台にしています。
長く使われてきた歴史があり、証明書や署名の文脈で今も広く見かけます。
強度の目安としては、RSA は少なくとも 2048 ビットが現代的な基準線です。

一方のECCは、楕円曲線上の離散対数問題を土台にした方式です。
初心者には少し抽象的に映りますが、実務上の特徴はつかみやすく、短い鍵長で高い強度を確保できる点が大きな持ち味です。
代表的な比較として、ECC 256 ビット鍵は RSA 3072 ビット鍵に近い強度、ECC 384 ビット鍵は RSA 7680 ビット鍵に近い強度という関係で語られます。
鍵や署名がコンパクトになりやすく、通信や処理の負担を抑えたい場面で有利に働きます。

この差は、Web 通信のように接続を何度も張る場面で効いてきます。
TLSでは昔のTLS 1.2で RSA 鍵交換が使われることもありましたが、TLS 1.3では RSA 鍵交換は外れ、ECDHEのような一時的な楕円曲線ベースの鍵共有が中心です。
ここでもRSAが消えたわけではなく、証明書の署名では残りつつ、鍵共有の主役はECC系に移った、と見ると実態に近いです。

実際の位置づけを整理すると、次のように理解するとぶれません。
RSAは「歴史が長く、署名や互換性の文脈で存在感がある方式」、ECCは「短い鍵で効率よく署名や鍵共有を行う方式」、そしてDiffie-HellmanやECDHEは「相手とその場で共有鍵を作る方式」です。
つまり、公開鍵暗号の世界はRSA対ECCの二択ではなく、暗号化・署名・鍵共有という役割ごとに、複数の方式が住み分けていると捉えるのが正確です。

読者が最初に覚えるべき芯はシンプルです。
公開鍵で暗号化して秘密鍵で復号する流れ、秘密鍵で署名して公開鍵で検証する流れ、この2本を取り違えないこと。
その上で、RSAとECCはその仕組みを実現する代表選手であり、現代の通信ではECDHEのような鍵共有方式も同じくらい頻繁に登場します。
ここが見えると、HTTPS の証明書、PGP の鍵、SSH のホスト鍵といった個別の話題が一本の線でつながります。

速度・安全性・鍵管理を比較する

速度比較の現実感

速度の話をするとき、まず軸を分けると混乱しません。
本文を大量に暗号化する処理では共通鍵暗号が担当し、最初に鍵を決める処理では公開鍵暗号や鍵共有方式が担当します。
ここが暗号の美しいところなのですが、遅い方式と速い方式を競わせるのではなく、役割を分担させることで全体の通信を現実的な速さにしています。

共通鍵暗号が高速なのは、同じ鍵で連続したデータを機械的に処理する設計だからです。
AESは 128 ビットのブロックを処理し、鍵長は 128・192・256 ビットを使い分けます。
ChaCha20-Poly1305のような方式も、通信本文を流し続ける用途で強さを発揮します。
Web 通信でページ本文や画像、API レスポンスをテンポよく運べるのは、この層が軽いからです。

例えば、ある実装（wolfSSL）が公表したベンチマークでは RSA 2048 の private 処理が約 920ms/op、ECDHE 256 の agree が約 390ms/opと報告されています。
ただし、これらの数値は CPU、コンパイラ最適化、ライブラリのビルドオプション、AVX 等の命令セット利用の有無など実装依存で大きく変わるため、あくまで一例として理解してください。
筆者がブラウザの開発者ツールでSecurityタブを開き、接続先の情報にECDHEやECDSAが並んでいるのを確認するとき、いつも手触りとして一致するものがあります。
接続直後には、ほんの一瞬だけハンドシェイク待ちの間があります。
しかし、その後に HTML や画像、スクリプトが流れ始めると、通信の体感は一気に軽くなります。
この「最初だけ少し重い、その後は一気に速い」という感覚こそ、公開鍵で鍵を決めて、以後は共通鍵で本文を流すハイブリッド構成そのものです。

TLS ではこの分担がさらに洗練されています。
TLS 1.3では鍵共有にECDHEのような一時的鍵交換が中心になり、初期接続の往復も整理されました。
現代の HTTPS は「公開鍵暗号だけで守っている」のではなく、鍵共有の安全性と、共通鍵暗号の速度を一つの接続の中で両立させているわけです。
速度を比べるときは、アルゴリズム単体の勝ち負けではなく、どの瞬間を担当しているのかを見るのが実務的です。

強度・鍵長の相当関係

強度の比較では、鍵長の数字をそのまま横並びにすると誤解が生まれます。
2048 ビットの RSA が 256 ビットの ECC より“数字が大きいから強い”わけではないからです。
方式ごとに攻撃の前提となる数学が違うため、同じ 1 ビットでも意味がそろいません。

現代的な目安として、RSA は 2048 ビット以上が広く使われています。
これは証明書や署名の文脈でも基準線になっている長さです。
RSA は歴史が長く理解しやすい一方、十分な強度を確保しようとすると鍵サイズが大きくなりやすく、処理負荷や証明書サイズにも影響します。

これに対して ECC は、短い鍵で同等級の強度を狙えるのが持ち味です。
実務でよく引かれる目安では、ECC 256 ビット鍵は RSA 3072 ビット鍵相当の強度とされます。
さらに ECC 384 ビット鍵は RSA 7680 ビット鍵相当という対応でも語られます。
ここでの「相当」は、数学的な土台が違う方式を安全性の水準で並べたときの目安です。
厳密に同一ではありませんが、設計判断ではこの対応関係がよく使われます。

この差は、単なる理論比較にとどまりません。
鍵が短いと、証明書や署名データもコンパクトになりやすく、ハンドシェイクの負担も抑えやすくなります。
だから現代の TLS では、RSA が姿を消したのではなく役割が絞られ、ECC 系が証明書や鍵共有で存在感を増しています。
読者が押さえるべき軸は、鍵長の数字そのものではなく、その方式でどの強度を得ているかです。

共通鍵暗号側の見方も少し添えると、こちらはAES-128AES-192AES-256のように鍵長が比較的素直です。
ただし、公開鍵暗号の 2048 ビットや 3072 ビットと並べて「どちらが強い」と単純比較するものではありません。
共通鍵と公開鍵では攻撃モデルも計算量評価も異なるため、数字の桁だけで判断すると軸がずれます。
実務では「本文の暗号化は AES 系」「鍵共有や署名は RSA や ECC 系」と役割が分かれており、それぞれの世界で適切な強度を確保します。

前方秘匿性と証明書の役割

鍵管理の観点では、共通鍵暗号と公開鍵暗号の違いがいちばん鮮明に出ます。
共通鍵暗号は通信相手と同じ秘密鍵を事前に共有しなければ始まりません。
相手が増えるほど管理対象も増え、参加者が n 人なら相互共有に必要な鍵は n×(n−1)÷2 個になります。
共通鍵暗号そのものは速くても、配る段階で苦しくなる理由はここです。

公開鍵暗号は、この配送問題を整理します。
受信者は公開鍵を配り、秘密鍵は自分だけが持てばよいので、「秘密の鍵を先に安全な経路で渡す」という面倒を減らせます。
ただし、公開鍵を配れることと、その公開鍵が本物だと確認できることは別問題です。
攻撃者が自分の公開鍵を本物のふりをして差し込めば、配送が楽でも意味がありません。

そこで登場するのが証明書や指紋確認です。
Web の HTTPS ではX.509証明書のチェーンをたどって、ブラウザがその公開鍵をそのサイトのものとして検証します。
PGPやSSHでは、フィンガープリントを見て本物かどうかを確かめる流れが出てきます。
公開鍵暗号は鍵配送を楽にするが、真正性の確認を省略できるわけではないというのが実務の芯です。

さらに現代の通信で見逃せないのが、前方秘匿性（forward secrecy）です。
これは、各セッションごとに新しい共有鍵を作ることで、将来サーバの長期秘密鍵が漏れても、過去の通信本文まではまとめて読まれにくくする性質です。
たとえば昔の RSA 鍵交換では、長期秘密鍵が後から漏れると、保存されていた過去の通信を復号できる構造がありました。
TLS 1.3が RSA 鍵交換をやめ、ECDHEのような一時鍵交換を前提にしたのは、この問題を避けるためでもあります。

直感に反するかもしれませんが、証明書の秘密鍵は「通信本文をそのまま復号する万能鍵」ではありません。
現代の TLS では、証明書は主に相手が本物であることを示す役を担い、本文を守るセッション鍵そのものはECDHEでその場ごとに作ります。
だから、開発者ツールで証明書の署名方式にECDSAが見え、鍵共有にECDHEが見えると、認証と前方秘匿性が役割分担していることまで読み取れます。

この観点で見ると、選び分けの軸は三つに整理できます。
本文を速く守りたいなら共通鍵暗号、鍵を安全に届けたいなら公開鍵暗号、過去の通信まで巻き込む事故を避けたいなら一時鍵交換です。
現代の HTTPS が強いのは、これらを一つの方式で無理に済ませず、速度・認証・鍵管理・前方秘匿性を別々の部品で組み合わせているからです。

実際のインターネットではどう使われるか

TLSではどこで何が使われるか

HTTPSでページを開くとき、暗号は最初から最後まで同じ方式で動いているわけではありません。
実際には、接続を始める段階と本文を流す段階で役割が切り替わります。
ここが暗号の美しいところなのですが、重い処理と速い処理をきれいに分業させることで、認証と速度の両立を実現しています。

最初のハンドシェイクでは、サーバが自分の正体を証明します。
その材料になるのがX.509証明書で、ブラウザは証明書チェーンをたどりながら、その公開鍵が本当に接続先のものかを検証します。
この場面で見えているのは、公開鍵暗号そのものよりも署名の検証です。
RSA 署名や ECDSA 署名がここで働き、ブラウザは「この公開鍵をそのサイトの鍵として信じてよいか」を判断します。

同時に、通信本体を守るための共有鍵も作られます。
現代の TLS ではECDHEのような鍵共有が中心で、クライアントとサーバがその接続のためだけの一時的な共有秘密を作ります。
ここで作られた鍵素材から、実際にデータを暗号化するセッション鍵が導かれます。
公開鍵暗号系は認証と鍵共有に使い、その後の本文は共通鍵暗号で流すという構造です。

本文の保護に回ると、主役はAES-GCMやChaCha20-Poly1305のような共通鍵暗号系の AEAD になります。
ページの HTML、画像、API レスポンス、ログイン後のデータなど、通信の本体はこの段階でまとめて処理されます。
前のセクションで触れた通り、公開鍵方式は点火装置で、実際に高速で回り続けるエンジンは共通鍵方式です。

筆者が初学者の方によく勧めるのは、ブラウザの南京錠アイコンを一度開いてみることです。
証明書の発行先や発行者をたどると、証明書チェーンという言葉が急に抽象論ではなくなります。
さらに接続の詳細を見られるブラウザや開発者ツールでは、TLS のバージョンや暗号スイートが見えることがあります。
そこにTLS 1.3やAES_128_GCM、ChaCha20-Poly1305のような名前が出てくると、「最初に身元確認と鍵共有をして、その後は別の方式で本文を守る」という二層構造が一気につながります。

SSHも発想はよく似ています。
サーバ認証と鍵共有を先に済ませ、実際のターミナル入出力やファイル転送は共通鍵で保護します。
今回は TLS と PGP を中心に見ていますが、インターネットの実務では「公開鍵で関係を作り、共通鍵でデータを運ぶ」という形が繰り返し現れます。

TLS 1.2のRSA鍵交換とTLS 1.3の鍵共有

TLS の理解でつまずきやすいのが、RSA が「いつ何に使われる RSA なのか」です。
証明書の署名で使われる RSA と、昔の TLS で使われた RSA 鍵交換は、役割が別です。

TLS 1.2では、暗号スイートしだいで RSA 鍵交換を選べました。
この方式では、クライアントがプリマスタシークレットを作り、それをサーバの RSA 公開鍵で暗号化して送ります。
サーバは自分の長期秘密鍵でそれを復号し、そこから通信鍵を作ります。
仕組みとしては分かりやすいのですが、後からサーバの長期秘密鍵が漏れると、保存されていた過去のハンドシェイクを復元できてしまいます。
前方秘匿性の観点では、この構造が弱点になります。

'TLS 1.3'ではこの RSA 鍵交換が廃止され、鍵共有は原則として(EC)DHEベースに統一されました（RFC 8446）。
クライアントとサーバは一時鍵を交換し、その場限りの共有秘密からセッション鍵を導きます。
サーバ証明書に RSA 鍵が入っていることはありますが、その RSA は主に署名用途です。

暗号スイートの見え方も TLS 1.2 と 1.3 で少し違います。
TLS 1.2 では暗号スイート名に鍵交換方式まで強く埋め込まれていましたが、TLS 1.3 では暗号スイートが主に対称暗号とハッシュ側を表し、鍵共有は別に扱われます。
画面に出てくる名称だけを追うと分かりにくいのですが、構造としてはむしろ整理されています。
認証、鍵共有、本文暗号化を別の部品として読むと、現代 TLS の設計意図がはっきり見えてきます。

PGPの“本文と鍵”を別々に守る流れ

PGPの構造も、実は TLS と同じ発想で読むと急に理解できます。
メール本文や添付ファイルのような大きなデータ本体は共通鍵で暗号化し、そのときだけ使うセッション鍵を受信者の公開鍵で暗号化して一緒に送ります。
これが OpenPGP の典型的なハイブリッド方式です。

流れを言葉で追うと、まず送信側が一時的な共通鍵を作ります。
その鍵で本文を暗号化します。
続いて、その共通鍵自体を受信者の公開鍵で包みます。
受信者は自分の秘密鍵でまずセッション鍵を取り出し、その後で本文を復号します。
つまり受信側では、先に鍵を開けてから本文を読むという二段階になっています。
抽象的な説明だけだと見落としがちですが、実際のメッセージ処理はまさにこの順番です。

筆者はこの仕組みを腹落ちさせる小さな実験として、自分自身にPGPで短いメールを送ってみるやり方が好きです。
件名を「テスト」くらいの短いものにして本文も一行だけにすると、何が守られているのかが見えやすくなります。
受信側で復号の流れを眺めると、いきなり本文が読めるのではなく、まず秘密鍵で鍵を開け、それから本文が読めるという二段階がはっきり現れます。
この瞬間に、「公開鍵暗号で本文そのものを丸ごと処理しているわけではないのだな」と手触りで理解できます。

PGP では署名も同居できます。
暗号化が「読めないようにする」役なら、署名は「誰が送ったか」と「途中で書き換わっていないか」を示す役です。
送信者は自分の秘密鍵で署名し、受信者は送信者の公開鍵で検証します。
ここでも暗号の部品は分業しています。
本文保護は共通鍵、セッション鍵保護は公開鍵、真正性の確認は署名です。

この構造を知っておくと、メール暗号に対する誤解も減ります。
たとえば PGP で守られる中心は本文とそのための鍵であって、メール全体の見え方がすべて同じように隠れるわけではありません。
だからこそ、PGP は「公開鍵暗号のメール版」ではなく、公開鍵と共通鍵を役割分担させたメール向けのハイブリッド暗号として理解したほうが正確です。
TLS が通信路でそれをやっており、PGP はメッセージ単位で同じ思想を実現している、と並べると整理しやすくなります。

量子コンピュータ時代に何が変わるか

公開鍵暗号への影響

量子コンピュータ時代の話で、まず影響が大きいのは公開鍵暗号です。
理由は明快で、整数因数分解や離散対数問題に依存する方式は、量子計算の文脈ではShorのアルゴリズムによって土台から揺さぶられるからです。
現行のRSAやECCは、古典計算機に対しては強固でも、十分に大規模で誤り耐性を備えた量子計算機が実用化した将来を見据えると、長期的には置き換えが必要という見通しになります。

ここで誤解しやすいのですが、これは「ある日突然、世の中の暗号が全部読めるようになる」という話ではありません。
実際の移行は役割ごとに段階的に進みますし、同じ公開鍵暗号でも用途は分かれています。
TLS では鍵共有、証明書、署名が別の部品として存在します。
したがって、量子耐性への移行も「鍵共有から先に置き換える」「署名は後から追随する」といった形になりやすいのです。

筆者がこの話を身近に感じるのは、「いま安全か」より「10年後にいまの録音や保存通信が読まれないか」という視点に立ったときです。
今日のメッセージが今夜破られるわけではなくても、暗号化された通信を誰かが長期間ため込み、将来の計算能力でまとめて解読するという発想は現実味があります。
いわゆる harvest now, decrypt later と呼ばれる懸念です。
だからこそ、通信のたびに一時鍵を作る前方秘匿性や、そこにポスト量子の鍵共有を組み合わせる価値は、研究室の議論ではなく日常の感覚につながります。
家族との通話、仕事の相談、いまは平凡に見える録音データでも、時間がたつと意味が変わることがあるからです。

NIST のポスト量子暗号標準化はこの前提で進み、2024年には最初の主要アルゴリズム群が FIPS として公開されました。
鍵共有側ではCRYSTALS-Kyberを基にした KEM、署名側ではCRYSTALS-Dilithium等が主要候補として位置づけられています。

共通鍵暗号への影響

共通鍵暗号も量子計算と無関係ではありませんが、公開鍵暗号とは影響の受け方が違います。
典型的に語られるのがGroverのアルゴリズムで、総当たり探索に対して平方根程度の加速が得られるため、有効強度が概ね半減するという表現が使われます。
たとえば鍵長 128 ビットの安全性が、量子攻撃の見積もりでは 64 ビット級の探索難度として語られる、というイメージです。

このため、共通鍵暗号では「方式を総入れ替えする」というより「鍵長を伸ばして余裕を持たせる」という戦略が中心になります。
AESはもともと 128 / 192 / 256 ビットの鍵長を持ち、ブロックサイズは 128 ビットです。
量子時代を意識した設計では、AES-256を選ぶ発想が自然です。
既存の暗号資産を活かしながら、量子計算による探索加速ぶんを鍵長で吸収する、という考え方です。
ChaCha20も 256 ビット鍵で使われるため、同じ文脈で語れます。

公開鍵暗号が「前提問題の破れに備えて別方式へ移る」方向なのに対し、共通鍵暗号は「鍵長と運用で余裕を積む」方向です。
この差を押さえておくと、「量子コンピュータが来ると全部の暗号が同じように危ない」という雑な理解から離れられます。
実務でも、TLS やメッセージ暗号の本文保護に使う対称暗号は当面そのまま残り、先に変わるのは鍵共有や署名まわり、という見取り図になります。

直感に反するかもしれませんが、量子時代においても通信本文を守る役のAESがすぐ退場するわけではありません。
むしろ鍵共有の入口を先に入れ替え、その後ろでAES-GCMやChaCha20-Poly1305のような対称暗号が引き続き主役を務める構図は、いまのインターネットとも連続しています。
変わるのは「本文を暗号化する速い部品」そのものより、「その部品にどの鍵をどう渡すか」の部分です。

TLSのポスト量子移行の現状

現実の展開もその順番です。
2025年時点で観測されるトラフィックの多くにポスト量子保護された鍵共有（既存の古典方式とポスト量子 KEM を併用するハイブリッド構成）が含まれているとのデータが示されています。
ただし、計測方法や母集団の違いにより普及度の評価は変わるため、業界全体で過半が移行したと断定する表現は避け、他の独立した計測結果と合わせて判断する旨を付記します。

もちろん、TLS 全体の移行が完了したわけではありません。
サーバ証明書の署名、クライアント認証、ミドルボックスや古い実装との整合など、後続の課題は残ります。
ですが、変化の起点がすでに可視化されている点は見逃せません。
RSAやECCが今すぐ全面失効するのではなく、まず鍵共有をポスト量子化し、本文暗号は既存の対称暗号を活かし、署名基盤がその後を追う。
2025〜2026年の現場感は、この段階的な移行として捉えるのが最も正確です。

まとめ

3行まとめ

共通鍵暗号は速く、本文を守る役に向いていますが、最初に同じ鍵をどう共有するかが壁になります。
公開鍵暗号は相手に鍵を渡しやすい一方で処理は重く、鍵交換や署名、認証の入口で力を発揮します。
実務ではこの2つを併用し、速さと配布性を両立させるのが基本形です。

学習の次の一歩

次はTLSのハンドシェイクを図で追い、どの段階で鍵交換・暗号化・電子署名が登場するのかを分けて見ると、頭の中の線が一気につながります。
PGPでも、本文とセッション鍵を別々に守る流れを見ると、ハイブリッド構成の意味が腹落ちします。
読了直後に、共通鍵は速いが共有が課題、公開鍵は共有しやすいが重い、実務は併用、この3点を30秒で自分の言葉にしてスマホへ吹き込んでみてください。
そこで詰まったら、公開鍵の真正性確認を担う証明書や指紋の役割、そしてRSAAESDiffie-Hellman鍵交換の個別理解を補う順番が見えてきます。