現代のインターネットセキュリティを支える根幹技術、それが公開鍵暗号方式（非対称暗号）と共通鍵暗号方式（対称暗号）です。HTTPSによる安全な通信、デジタル署名による本人確認、どれも鍵暗号技術なしには成立しません。本記事では「公開鍵と秘密鍵がどのようにやり取りされるか」を段階的なアニメーションで徹底解説します。
共通鍵暗号 vs 公開鍵暗号の比較
まず2つの方式の根本的な違いを理解しましょう。
| 項目 | 共通鍵暗号（対称） | 公開鍵暗号（非対称） |
|---|---|---|
| 鍵の数 | 1つ（送受信者が同じ鍵を使用） | 2つ（公開鍵＋秘密鍵のペア） |
| 処理速度 | 高速（大量データに向く） | 低速（少量データ向き） |
| 鍵配送問題 | あり（鍵を安全に渡す手段が必要） | なし（公開鍵は誰でも取得可能） |
| 主な用途 | 大容量データの暗号化 | 鍵交換・デジタル署名 |
| 代表例 | AES、ChaCha20 | RSA、楕円曲線暗号（ECDSA） |
公開鍵暗号の暗号化フロー
アリス（送信者）がボブ（受信者）に安全にメッセージを送るシナリオで、公開鍵暗号の仕組みを理解しましょう。
公開鍵暗号による暗号化・復号の流れ（アリス → ボブ）
Step 1
ボブが鍵ペアを生成・公開鍵を公開
ボブは「公開鍵」と「秘密鍵」のペアを作成します。公開鍵は全世界に公開し、秘密鍵は絶対に自分だけが保管します。南京錠（公開鍵）を誰でも使えるようにし、その鍵（秘密鍵）は自分だけが持つイメージです。
ボブは「公開鍵」と「秘密鍵」のペアを作成します。公開鍵は全世界に公開し、秘密鍵は絶対に自分だけが保管します。南京錠（公開鍵）を誰でも使えるようにし、その鍵（秘密鍵）は自分だけが持つイメージです。
Step 2
アリスがボブの公開鍵を入手
アリスはボブの公開鍵をダウンロードします。この通信は盗聴されても問題ありません。公開鍵は「公開」されているものだからです。
アリスはボブの公開鍵をダウンロードします。この通信は盗聴されても問題ありません。公開鍵は「公開」されているものだからです。
Step 3
アリスがボブの公開鍵で平文を暗号化
アリスは送りたいメッセージ（平文）を、ボブの公開鍵を使って暗号文に変換します。一度暗号化すると、対応する秘密鍵（ボブだけが持つ）がなければ元に戻せません。
アリスは送りたいメッセージ（平文）を、ボブの公開鍵を使って暗号文に変換します。一度暗号化すると、対応する秘密鍵（ボブだけが持つ）がなければ元に戻せません。
Step 4
暗号文をインターネット経由で送信
暗号化されたメッセージをボブに送ります。途中で第三者に傍受されても、秘密鍵がなければ復号不可能なため安全です。
暗号化されたメッセージをボブに送ります。途中で第三者に傍受されても、秘密鍵がなければ復号不可能なため安全です。
Step 5
ボブだけが秘密鍵で復号
ボブは自分だけが持つ秘密鍵を使って暗号文を平文に戻します。第三者は公開鍵しか持っていないため、暗号文を傍受しても読めません。
ボブは自分だけが持つ秘密鍵を使って暗号文を平文に戻します。第三者は公開鍵しか持っていないため、暗号文を傍受しても読めません。
なぜ安全？公開鍵と秘密鍵の関係
公開鍵（Public Key）
誰でも取得・使用できる。平文を暗号化するために使う。南京錠を開いた状態で世界中に配る。
秘密鍵（Private Key）
絶対に公開しない。暗号文を復号するために使う。南京錠を閉じる唯一の鍵。漏洩したら即座に無効化が必要。
デジタル署名フロー（公開鍵の逆の使い方）
デジタル署名では、暗号化とは逆の方向で鍵を使います。「秘密鍵で署名」→「公開鍵で検証」です。
デジタル署名の生成と検証フロー
署名生成 Step 1
送信者がメッセージのハッシュ値を計算
送信者はメッセージをハッシュ関数（SHA-256など）に通し、固定長のハッシュ値（メッセージの指紋）を生成します。
送信者はメッセージをハッシュ関数（SHA-256など）に通し、固定長のハッシュ値（メッセージの指紋）を生成します。
署名生成 Step 2
送信者が秘密鍵でハッシュ値を暗号化（署名）
ハッシュ値を送信者自身の秘密鍵で暗号化します。これが「デジタル署名」です。秘密鍵を持つのは本人だけなので、署名の作成者を証明できます。
ハッシュ値を送信者自身の秘密鍵で暗号化します。これが「デジタル署名」です。秘密鍵を持つのは本人だけなので、署名の作成者を証明できます。
署名検証 Step 3
受信者が送信者の公開鍵で署名を復号
受信者は送信者の公開鍵を使って署名を復号し、元のハッシュ値を取り出します。
受信者は送信者の公開鍵を使って署名を復号し、元のハッシュ値を取り出します。
署名検証 Step 4
受信側でも同じハッシュ値を計算・照合
受信者は受け取ったメッセージを自分でもハッシュ計算し、Step3で取り出したハッシュ値と一致するか確認します。一致すれば「改ざんなし・本人からの送信」が証明されます。
受信者は受け取ったメッセージを自分でもハッシュ計算し、Step3で取り出したハッシュ値と一致するか確認します。一致すれば「改ざんなし・本人からの送信」が証明されます。
暗号化 vs デジタル署名：鍵の使い方の違い
暗号化（秘密を守る）
公開鍵で暗号化 → 秘密鍵で復号
送信者が受信者の公開鍵で暗号化。受信者の秘密鍵でのみ復号可能。
送信者が受信者の公開鍵で暗号化。受信者の秘密鍵でのみ復号可能。
デジタル署名（本人を証明）
秘密鍵で署名 → 公開鍵で検証
送信者の秘密鍵で署名。誰でも送信者の公開鍵で検証可能。
送信者の秘密鍵で署名。誰でも送信者の公開鍵で検証可能。
ハイブリッド暗号（TLS/HTTPSの実際の仕組み）
実際のHTTPS通信では、公開鍵暗号だけでなく共通鍵暗号との組み合わせ（ハイブリッド暗号）が使われます。理由は公開鍵暗号が低速で、大量データの暗号化には向かないためです。
TLS/HTTPSのハイブリッド暗号の仕組み
Phase 1
公開鍵暗号で「共通鍵」を安全に交換
クライアントがサーバーの公開鍵を使って、ランダムに生成したセッション鍵（共通鍵）を暗号化して送ります。これで共通鍵が安全に共有されます。
クライアントがサーバーの公開鍵を使って、ランダムに生成したセッション鍵（共通鍵）を暗号化して送ります。これで共通鍵が安全に共有されます。
Phase 2
共通鍵で実際のデータを高速暗号化
共有できた共通鍵（AESなど）を使い、大量のHTTPデータを高速に暗号化します。公開鍵暗号より数百倍高速なため実用的です。
共有できた共通鍵（AESなど）を使い、大量のHTTPデータを高速に暗号化します。公開鍵暗号より数百倍高速なため実用的です。
Phase 3
セッション終了で共通鍵を破棄
セッションが終わると共通鍵は破棄されます（前方秘匿性）。後から通信を傍受しても解読できません。
セッションが終わると共通鍵は破棄されます（前方秘匿性）。後から通信を傍受しても解読できません。
代表的なアルゴリズム
主要な暗号アルゴリズム一覧
公開鍵 RSA
最も広く使われる公開鍵暗号。素因数分解の困難さを安全性の根拠とする。鍵長2048bit以上が推奨。TLS証明書に多用。
公開鍵 楕円曲線暗号（ECDSA）
楕円曲線上の離散対数問題を利用。RSAより短い鍵長で同等の安全性。256bitでRSA 3072bit相当。モバイル・IoTに最適。
共通鍵 AES
現在の標準共通鍵暗号。ブロック暗号（128bitブロック）。鍵長128/192/256bit。NIST標準で政府・金融機関が採用。
共通鍵 ChaCha20
ストリーム暗号。AESハードウェア命令がないモバイル・組み込みデバイスで高速。TLS 1.3でAESと並んで採用。
鍵の長さと安全性の比較
| アルゴリズム | 鍵長 | 安全性の根拠 | 推奨用途 | 備考 |
|---|---|---|---|---|
| RSA | 2048bit〜 | 素因数分解の困難さ | TLS証明書・鍵交換 | 4096bitで長期保管向け |
| ECDSA (P-256) | 256bit | 楕円曲線離散対数 | 署名・TLS | RSA 3072bit相当の安全性 |
| AES-128 | 128bit | ブロック暗号強度 | データ暗号化 | 現時点で解読不可 |
| AES-256 | 256bit | ブロック暗号強度 | 機密データ・長期保管 | 量子コンピュータ耐性あり |
| ChaCha20 | 256bit | ストリーム暗号強度 | モバイル・IoT | ソフトウェア実装に最適 |
まとめ
公開鍵暗号の核心は「公開鍵で暗号化、秘密鍵で復号」という非対称性にあります。デジタル署名ではその逆、「秘密鍵で署名、公開鍵で検証」を利用します。実際のHTTPS通信では、公開鍵暗号で共通鍵を安全に共有し、大量データは高速な共通鍵暗号で処理するハイブリッド方式が使われています。この仕組みが現代インターネットの安全性を支えているのです。
