暗号技術とハイブリッド暗号：共通鍵AES・公開鍵RSA・デジタル署名の完全理解

内容を秘密にしたいときと、送信者や改ざんを確かめたいときは、同じ鍵を使うのでしょうか？

暗号化と署名では、目的も鍵の使い方も異なります。共通鍵・公開鍵の違いを押さえ、ハイブリッド暗号と署名を別々に追ってみましょう。

共通鍵暗号方式（Symmetric Key）の特徴と鍵配送問題

暗号化と復号に「まったく同じ1つの鍵（秘密の鍵）」を用いる方式を「共通鍵暗号方式」と呼びます。

項目	内容・特徴	解説・具体例
代表的アルゴリズム	AES（128・192・256ビット鍵）。DES・3DESは旧方式で、新しい設計に推奨する例ではない。	現在のデファクトスタンダードは米政府標準の「AES（鍵長128/192/256ビット）」。
長所（メリット）	暗号化・復号の処理速度が極めて高速！	ビット演算や換字・転置の組み合わせのためハードウェア/ソフトウェア双方で高速動作。
短所（デメリット）	① 鍵配送問題（Key Distribution Problem）、② 管理すべき鍵の数が膨大になる	通信相手に事前にどうやって安全に鍵を届けるかという根本的課題が存在。
必要な鍵の数（公式）	n 人が相互に安全に通信する場合： n × (n - 1) / 2 個	通信相手ペアごとに異なる共通鍵が必要（例: 100人なら 100×99/2 = 4,950個！）。

公開鍵暗号方式（Asymmetric Key）の革新と暗号化ルール

公開鍵暗号では、公開鍵を配布して秘密鍵を持つ相手への暗号化ができます。公開鍵が本当に相手のものかという確認は別に必要です。証明書などで信頼できる鍵との対応を確かめます。

項目	内容・特徴	解説・具体例
代表的アルゴリズム	RSA, 楕円曲線暗号 (ECC), ElGamal	巨大な素数の積の素因数分解の困難性（RSA）や楕円曲線上の離散対数問題を利用。
暗号化通信の鉄則	【受信者の公開鍵】で暗号化し、【受信者の秘密鍵】でのみ復号できる！	送信者は誰でも入手可能な「受信者の公開鍵」で暗号化する。復号できるのは世界で唯一、秘密鍵を持つ受信者本人だけ。
管理すべき鍵の数	n 人が通信する場合： 2n 個（1人あたり公開鍵1個＋秘密鍵1個）	各人が1鍵ペアを持つならnペア、鍵を個別に数えれば2n個。100人では100ペア・200個。
短所（弱点）	一般に共通鍵暗号より処理が重い。具体的な速度比は方式・鍵長・実装・ハードウェアで異なる。	長文や大容量ファイルの直接暗号化には向かない。

ハイブリッド暗号：RSAによる鍵配送の例

共通鍵による本文の高速な暗号化と、公開鍵技術による鍵共有・認証を組み合わせる考え方です。以下はRSAで共通鍵を配送する例で、TLS 1.3そのものの手順ではありません。

セッション鍵の生成：送信側が、その通信セッション限りの一時的な「共通鍵（セッション鍵）」をランダム生成する。
本文の暗号化：大量のデータ（メッセージ本文）を、高速な【共通鍵】で暗号化する。
セッション鍵の暗号化：受信者の【公開鍵】を使って、一時的な【共通鍵】を安全に暗号化する。
暗号文の送信：暗号化された本文と、暗号化された共通鍵をセットにして相手へ送信する。
セッション鍵の復号：受信側が、自身の【秘密鍵】を使って暗号化された共通鍵を復号し、元の共通鍵を取り出す。
本文の復号：取り出した【共通鍵】を使って、暗号化された本文を高速復号する！

デジタル署名：秘密鍵で生成し、公開鍵で検証する

署名は機密性ではなく、改ざん検知と署名者の確認に使います。署名者は秘密鍵で署名を生成し、受信者は署名者の公開鍵で検証します。

署名アルゴリズムに従ってメッセージを処理し、秘密鍵で署名を作ります。
受信したメッセージ、署名、署名者の公開鍵を使って妥当性を確認します。
証明書などで公開鍵と署名者の対応を確かめます。鍵の漏えいや証明書の有効性も確認が必要です。

「秘密鍵で暗号化し、公開鍵で復号する」は署名一般の説明として適切ではありません。RSA署名にも専用の符号化があり、ECDSAなどは公開鍵で復号する方式ではありません。署名付きの本文は、別に暗号化しなければ読めます。

実戦演習問題とステップ別解説

問1：共通鍵暗号方式における鍵の総数計算

20人のグループ全員が、互いに他のメンバーに内容を知られることなく1対1で通信を行いたい。共通鍵暗号方式を用いる場合、グループ全体で最低限必要となる鍵の個数は何個か。

20個
40個
190個
380個

【正解】ウ

【解説】n 人が共通鍵暗号方式で相互通信を行う場合に必要な鍵の数は、数学の組み合わせ公式 n(n - 1) / 2 個です。20 × (20 - 1) / 2 = 20 × 19 / 2 = 190個となります。正解はウです。

（※なお、公開鍵暗号方式であれば 2n = 40個で済みます）。

問2：デジタル署名の生成と検証における鍵の組み合わせ

送信者Aが受信者Bに対して、メッセージ本文とともにデジタル署名を送信する。デジタル署名の「生成」に使用する鍵と、受信者Bがデジタル署名の「検証」に使用する鍵の組み合わせとして、適切なものはどれか。

生成: Aの公開鍵／検証: Aの秘密鍵
生成: Aの秘密鍵／検証: Aの公開鍵
生成: Bの公開鍵／検証: Bの秘密鍵
生成: Bの秘密鍵／検証: Bの公開鍵

【正解】イ

【解説】デジタル署名は「送信者A本人が作成したこと（本人性）」を証明しなければなりません。したがって、Aしか持っていない「Aの秘密鍵」で署名を生成します。

受信者Bおよび第三者は、誰でも入手できる「Aの公開鍵」を使ってその署名を検証し、Aが作成したことを確かめます。正解はイです。

TLS 1.3ではRSAで通信鍵を配送しない

上の手順は、共通鍵を受信者のRSA公開鍵で暗号化するハイブリッド暗号の例です。TLS 1.3の通常の証明書認証付き接続では、(EC)DHEなどで鍵素材を共有し、通信鍵を導出します。PSKを使う方式もあります。

TLS 1.3でRSAの署名を使う場合でも、RSAで通信鍵を暗号化して送る旧方式とは役割が異なります。

公開鍵と本人の対応を確認するPKI

認証局CAは、公開鍵と主体の対応を表すデジタル証明書に署名します。利用者は信頼する認証局につながる証明書の連鎖、有効期間、対象名、失効情報などを確認します。証明書があるだけで無条件に信頼するわけではありません。

出典と仕様を確認する

IPA：FEシラバス Ver.9.2

NIST：FIPS 186-5 デジタル署名

RFC 8446：TLS 1.3

RFC 8017：RSA暗号と署名