公開鍵暗号方式と共通鍵暗号方式の違いとは？仕組み・アルゴリズム・使い分けを解説

公開鍵暗号方式と共通鍵暗号方式は、どちらもデータを第三者に読めない形へ変える技術ですが、鍵の使い方が根本から違います。共通鍵暗号方式が暗号化と復号に同じ鍵を使うのに対し、公開鍵暗号方式は公開鍵と秘密鍵という2つの鍵をペアで使う点が特徴です。この記事では、2つの方式が生まれた理由を「鍵配送問題」という本質から整理し、AES・DES・RSA・楕円曲線暗号といった代表的なアルゴリズムの違い、SSL/TLSで両者を組み合わせるハイブリッド運用、電子署名やデジタル証明書を支えるPKIの仕組みまでを解説します。そのうえで、システム開発で自社データをどちらの方式で守るかを判断する基準も示します。

まとめ：2方式は「鍵配送問題」を境に役割が分かれる

共通鍵暗号方式と公開鍵暗号方式の違いは、突き詰めると「鍵をどう相手へ届けるか」に行き着きます。共通鍵暗号方式は暗号化と復号で同じ鍵を使うため処理が速く、大量のデータ本体を守るのに向く一方、その鍵をどう相手へ安全に渡すかという鍵配送問題が残る点が弱点です。公開鍵暗号方式は、渡してよい公開鍵と手元に秘匿する秘密鍵を分けることでこの問題を解き、鍵の受け渡しや本人確認に強みを持ちます。

現実のインターネット通信は、どちらか一方ではなく両方を組み合わせたハイブリッド方式で動きます。公開鍵暗号方式で共通鍵を安全に共有し、その後の通信本体は高速な共通鍵暗号方式で流します。SSL/TLSがこの代表例です。自社システムを設計するときにまず押さえたいのは、方式そのものより「何を守るか」と「鍵を誰がどこで管理するか」の設計です。暗号方式の全体像や、企業がどこを暗号化すべきかは暗号化とはの解説記事で整理しています。

共通鍵暗号方式と公開鍵暗号方式に分かれる理由：鍵配送問題という本質

暗号方式が2種類あるのは、優劣ではなく解こうとする課題が違うためです。まず共通鍵暗号方式の限界を知ると、公開鍵暗号方式がなぜ生まれたかが見えてきます。

共通鍵暗号方式の仕組み：暗号化と復号に同じ1本の共通鍵を使う

共通鍵暗号方式は、暗号化と復号にまったく同じ鍵を使います。送信者が鍵でデータを暗号文へ変え、受信者は同じ鍵で元の平文へ戻す仕組みです。単純で計算量が小さいため処理が速く、ファイルやディスク、通信本体といった大きなデータの暗号化に向きます。対称鍵暗号方式とも呼ばれます。弱点は一つだけです。暗号文を送る前に、その鍵を受信者へ安全に渡しておく必要があります。

公開鍵暗号方式の仕組み：公開鍵と秘密鍵のペアで役割を分ける方式

公開鍵暗号方式は、数学的に対応した2つの鍵をペアで使います。公開鍵は誰に配っても構わない鍵で、秘密鍵は本人だけが握る鍵です。公開鍵で暗号化したデータは、対応する秘密鍵でしか復号できません。この非対称性により、事前に秘密の鍵を共有しなくても、相手の公開鍵さえ手に入れば暗号化して送れます。非対称鍵暗号方式とも呼ばれ、代表的なアルゴリズムはRSA暗号や楕円曲線暗号です。

鍵配送問題：共通鍵と公開鍵の分岐点になる鍵をどう届けるかの壁

共通鍵暗号方式で通信しようとすると、最初に同じ鍵を相手へ渡す場面が必ず生じます。ところが、その鍵を盗聴される経路で送れば、暗号文もろとも解読されてしまいます。かといって別の安全な経路を毎回用意するのは現実的ではありません。これが鍵配送問題です。利用者が n 人いれば、全員が互いに別々の共通鍵を持つ組み合わせは膨大になり、管理も破綻します。公開鍵暗号方式は、秘密の鍵を渡さずに暗号通信を始められる仕組みで、この壁を越えるために考案されました。

代表的な暗号アルゴリズム：AES・DES・RSA・楕円曲線の違いと用途

「方式」は鍵の使い方の分類で、実際に計算を行う手順が「アルゴリズム」です。共通鍵系と公開鍵系それぞれに代表的なアルゴリズムがあり、世代交代も進んでいます。

共通鍵系のアルゴリズム：DESからAESへ移行した理由と鍵長

共通鍵系で長く使われたのがDESです。鍵長が56ビットと短く、計算機の性能向上によって総当たり攻撃で現実的に破られるようになり、鍵を3回かけて強度を上げた3DESを経て、現在はAESが標準です。AESは128・192・256ビットの鍵長を選べ、米国NISTが標準として採用しています。保存データや通信本体の暗号化で広く使われ、新規のシステムでDESや3DESを選ぶ理由はありません。共通鍵系を選ぶなら、実務ではまずAESを前提に考えます。

公開鍵系のアルゴリズム：RSA暗号と楕円曲線暗号の鍵長の違い

公開鍵系の代表がRSA暗号です。巨大な素数の積を素因数分解する難しさを安全性の根拠にし、鍵配送や電子署名で長く使われてきました。推奨鍵長は2048ビット以上で、より高い強度には3072ビットが目安とされます。一方の楕円曲線暗号は、同じ強度をより短い鍵長で実現できる点が違いです。RSAの2048ビットに相当する強度が楕円曲線暗号では256ビット前後で得られ、鍵やデータが軽くなるため、計算資源が限られるスマートフォンやIoT機器で採用が広がっています。

共通鍵と公開鍵方式の比較：鍵の数・速度・主な用途を一覧で整理

ここまでの違いを、実務で判断に使う観点でまとめます。速度と用途が逆の性質を持つことが、両者を組み合わせる理由になります。

速い共通鍵方式でデータを守り、鍵の受け渡しだけを公開鍵方式に任せる。この役割分担が、次に述べるハイブリッド方式の設計思想です。

2方式を組み合わせるハイブリッド方式：SSL/TLSで動く実際の流れ

実務のインターネット通信は、共通鍵方式と公開鍵方式のどちらか一方だけでは成り立ちません。両方の長所を組み合わせるハイブリッド方式が、私たちが毎日使うhttps通信を支えています。

ハイブリッド方式の流れ：公開鍵で共通鍵を渡し本体は共通鍵で守る

ハイブリッド方式は、2つの方式を工程で使い分けます。まず通信の入口で、相手の公開鍵を使ってその場限りの共通鍵を安全に相手へ渡します。鍵配送問題を、この一瞬だけ公開鍵方式に任せて解決する仕組みです。共通鍵を両者で共有できたら、以降の大量のデータ本体は高速な共通鍵方式でやり取りします。公開鍵方式の重い計算は鍵の受け渡しにだけ使い、通信の中身は速い共通鍵方式が担います。

SSL/TLSハンドシェイクでの動き：証明書確認から鍵共有までの順序

ブラウザとサーバーがhttps通信を始める前に行うのがTLSハンドシェイクです。おおまかな順序は次のようになります。

1. ブラウザがサーバーへ接続を要求し、サーバーがデジタル証明書（公開鍵を含む）を返す
2. ブラウザが証明書を認証局の署名で検証し、相手が本物かを確認する
3. 公開鍵を使い、その通信専用の共通鍵の材料を安全に共有する
4. 以降のWebページのデータは、共有した共通鍵（AESなど）で暗号化して送受信する

鍵を安全に配り終えたら主役が共通鍵方式へ切り替わる、という流れが実際のプロトコルに落とし込まれています。TLSの新しい版では、この手順を短縮して接続を速める改良も進んでいます。

公開鍵暗号方式が支える電子署名とデジタル証明書・PKIの仕組み

公開鍵暗号方式の価値は暗号化だけではありません。鍵の使い方を逆にすると、データが本物かを証明する電子署名になります。この仕組みが、Web全体の信頼を支えるPKIの土台です。

電子署名：秘密鍵で署名し公開鍵で検証する暗号化と逆向きの使い方

暗号化では公開鍵でかけて秘密鍵で戻しますが、電子署名は逆の使い方です。送信者が自分の秘密鍵でデータの要約に署名し、受信者は送信者の公開鍵でそれを検証します。秘密鍵を持つ本人しか作れない署名を、誰もが持てる公開鍵で確かめられる点が特徴です。これにより「確かにこの人が作った」「途中で改ざんされていない」を同時に示せます。契約書の電子契約や、ソフトウェアの配布元の証明などで使われています。

デジタル証明書と認証局：公開鍵が本物であることを保証するPKI

公開鍵暗号方式には、受け取った公開鍵が本当に相手のものかを確かめる必要が残ります。偽の公開鍵をつかまされれば、なりすましに気づけないためです。ここで信頼できる第三者である認証局が、公開鍵とその持ち主を結びつけたデジタル証明書を発行します。認証局・証明書・鍵の管理を含む仕組み全体をPKI（公開鍵基盤）と呼びます。httpsの鍵マークは、このPKIによって相手の正当性が検証できた印です。

Kerberos：共通鍵方式を社内認証へ応用したチケット型の仕組み

共通鍵方式は暗号化専用ではなく、認証にも応用されています。その代表がKerberosです。信頼できる認証サーバーが利用者ごとの共通鍵を管理し、ログイン時に「チケット」と呼ばれる暗号化された通行証を発行します。利用者はこのチケットを提示するだけで、社内の複数サービスへ都度パスワードを送らずにアクセスできます。Windowsのドメイン認証などで動いており、鍵配送問題を「信頼できる中央サーバー」を置くことで回避した共通鍵方式の実装例です。

システム開発で暗号方式をどう選ぶか：守る対象から決める判断基準

ここまでの技術差を、実際のシステム設計での判断に落とします。結論から言えば、方式は好みで選ぶものではなく「何を守るか」から自動的に決まります。そして多くの場面で、開発者が方式を意識してゼロから実装することは推奨されません。

守る対象で決まる方式：保存はAES・鍵の受け渡しは公開鍵方式

自社データベースや業務端末に保存するデータ、つまり動かないデータ本体を守るなら、速く大量に処理できる共通鍵方式のAESが向きます。外部とのやり取りやログイン、他システムとの通信のように鍵や本人確認が絡む場面では、公開鍵方式が必要です。実際にはこの2つを設計者が別々に選ぶ場面は少なく、TLSやライブラリが内部でハイブリッド方式として自動で組み合わせます。設計者が判断すべきは、通信を必ずTLSで保護し、保存データにAES暗号化を掛けるという「どこに暗号化を適用するか」の線引きです。

やってはいけない実装：暗号アルゴリズムの自作と鍵のソース直書き

方式選び以前に、避けるべき失敗が2つあります。一つは、暗号アルゴリズムを自作したり、既存方式を独自にアレンジしたりすることです。暗号は世界中の攻撃に耐えて標準化されたものに価値があり、自作の暗号は思わぬ穴を残します。実務では、AESやTLSを実装した検証済みのライブラリやOS標準機能を使い、設計者が新しい暗号を発明しません。もう一つは、秘密鍵や共通鍵をソースコードや設定ファイルに直接書き込むことです。鍵が漏れれば暗号化そのものが無意味になります。鍵はソースから切り離し、専用の鍵管理サービスや保管領域で分離して管理する設計が前提です。個人情報や認証情報を扱う会員基盤では、この鍵管理まで含めて要件になります。こうしたデータを扱う会員管理システムの開発では、暗号方式の選定と鍵管理の設計を最初から要件に組み込みます。

暗号化を見送る判断：アプリ層で追加の暗号を持つべきでない場面

暗号化はどこにでも掛ければよいものではありません。データベースやストレージが標準の暗号化機能を備えている場合、その上でアプリケーション側がさらに独自暗号を重ねると、検索や集計ができなくなり、鍵管理の複雑さだけが増します。この場面ではアプリ層での追加暗号は見送り、基盤側の暗号化と通信のTLSに任せる判断が適切です。暗号化は多重に掛けるほど安全になるわけではなく、鍵の管理点を増やすほどむしろ漏えいリスクの入口が増えます。

公開鍵暗号方式と共通鍵暗号方式の使い分けに関するよくある質問

2方式の違いを調べる際に多い疑問を、実務の観点で整理します。

公開鍵暗号方式と共通鍵暗号方式はどちらが安全ですか？

安全性の優劣ではなく役割が違うため、一概にどちらが安全とは言えません。同じ強度なら、鍵を秘密に共有できている前提では共通鍵方式のAESも十分に堅牢です。公開鍵方式の強みは安全性そのものより、鍵を事前共有せずに暗号通信や本人確認を始められる点にあります。実際のシステムは両者を組み合わせ、それぞれの弱点を補って使います。

共通鍵暗号方式のデメリットは何ですか？

最大のデメリットは鍵配送問題です。暗号化と復号で同じ鍵を使うため、その鍵を相手へ安全に届ける手段が別途必要になります。加えて、通信相手が増えるほど管理する鍵の数が急増し、鍵の保管と更新の運用が重くなります。処理が速い一方で、鍵の共有と管理に課題が残る方式です。

公開鍵暗号方式はなぜ処理が遅いのですか？

RSA暗号などの公開鍵方式は、巨大な数の素因数分解や離散対数といった重い数学的計算を安全性の根拠にしているためです。この計算量が、共通鍵方式に比べて暗号化・復号を遅くします。そのため大きなデータ本体をそのまま公開鍵方式で暗号化することは少なく、鍵の受け渡しや署名など短いデータの処理に用途を絞って使われます。

AESとRSAはどちらの方式に分類されますか？

AESは共通鍵暗号方式、RSAは公開鍵暗号方式のアルゴリズムです。AESは暗号化と復号に同じ鍵を使いデータ本体の保護に向き、RSAは公開鍵と秘密鍵のペアで鍵配送や電子署名に使われます。SSL/TLSでは、RSAや鍵交換で共通鍵を渡し、通信本体をAESで暗号化する、というように両者が役割分担して同時に動いています。

電子署名は暗号化とどう違いますか？

暗号化が「中身を第三者に読ませない」ための処理なのに対し、電子署名は「作成者が本物で、改ざんされていない」ことを証明するための処理です。どちらも公開鍵暗号方式の鍵ペアを使いますが、暗号化は公開鍵でかけ秘密鍵で戻し、電子署名は秘密鍵で署名し公開鍵で検証する、と鍵の使う向きが逆になります。目的が秘匿か証明かで区別します。

関連記事

• 暗号化とは？共通鍵・公開鍵の違いと企業が守るべきデータの判断を解説：暗号化の全体像と、企業が保存データ・通信・バックアップのどこを暗号化すべきかの判断はこちらで整理しています。
• 二段階認証とは？二要素認証・多要素認証との違いと企業の導入判断を解説：暗号方式が支える「本人確認」を、認証の側から扱った記事です。暗号化と認証の役割の違いを押さえられます。