公開鍵暗号の仕組みとRSAの原理図解

ブラウザの錠前アイコンを開いて証明書の詳細をのぞくと、Public-Key: RSA 2048 と Exponent: 65537 が並んでいて、公開鍵暗号は教科書の中だけの話ではなく、いま目の前の通信を支える現役技術なのだと実感します。
この記事は、RSAを名前だけ知っている人から、式は見たことがあるが腹落ちしていない人までを対象に、公開鍵暗号が鍵配送問題をどう解いたのかを、南京錠と郵便受けの比喩から数式までつなげて整理します。
そのうえで、p, q, n, φ(n), e, d という骨格と C = M^e mod n、M = C^d mod n の意味を図で俯瞰し、手計算で追体験しながら、教科書どおりのRSAがそのままでは危うい理由と、RSA-OAEPが加えるランダム化の価値を掘り下げます。
あわせて、現代のTLSではRSAが通信本文を丸ごと暗号化しているわけではなく、署名や鍵輸送の一部を担い、実データはAESなどの共通鍵暗号が処理するという現在地も押さえます。
視野を少し先まで広げ、RSA-2048やRSA-3072、ECC-256の強度感と、Shorのアルゴリズムを見据えたPQC移行の流れまで、一枚の地図としてつかめるようにしていきます。

公開鍵暗号は何を解決したのか

鍵配送問題とは

公開鍵暗号がもたらした転換をひと言でいえば、「暗号化そのもの」より先に、「鍵をどう渡すか」という詰みやすい問題に突破口を開いたことにあります。
しかも実運用では、公開鍵暗号だけで通信本文を丸ごと処理するのではなく、公開鍵で共通鍵を安全に合意したり封緘したりして、その後の本文はAESのような共通鍵暗号で高速に処理する構成が主流です。
ここを先に押さえると、公開鍵暗号の役割が一気に見通せます。

共通鍵暗号は、送る側と受け取る側が同じ鍵を持っていることを前提にします。
たとえば筆者が友人に秘密のメッセージを送りたいとして、あらかじめ二人だけが知る合言葉のような鍵を決め、その鍵で暗号化して送るイメージです。
暗号化の処理自体は高速で、長いデータでも軽快に扱えます。
問題は、その「同じ鍵」を最初にどうやって共有するかです。

離れた相手と安全に同じ鍵を持つのは、言葉で聞く以上に難題です。
メールで鍵を送れば、そのメールを盗み見された時点で終わりです。
メッセージアプリで送っても、相手本人に届いたと信じる根拠がなければ安心できません。
電話で読み上げる方法も、盗聴の心配や聞き間違いが残ります。
直接会って紙に書いて渡せるなら安全性は上がりますが、その時点で「ネット越しに安全にやり取りしたい」という目的から外れてしまいます。

スマホのメッセージでの疑似体験を例にすると、鍵の受け渡しに潜む違和感が直感として理解しやすくなります。

ここが暗号の美しいところなのですが、公開鍵暗号はこの循環を断ち切りました。
相手と事前に同じ秘密を持っていなくても、まずは相手の公開鍵を使って情報を送れるようにしたのです。
これによって、遠く離れた相手とも、最初の一歩を踏み出せるようになりました。

郵便受け/南京錠の比喩で理解する

公開鍵と秘密鍵の役割は、郵便受けと南京錠で考えると直感に乗ります。公開鍵は、誰でも投函できる投入口です。秘密鍵は、自分だけが開けられる鍵です。

たとえば自宅の郵便受けは、住所さえ分かれば配達員でも来客でも手紙を入れられます。
しかし、中身を取り出せるのは持ち主だけです。
公開鍵暗号もこの構図に近く、相手の公開鍵は広く配ってかまいません。
むしろ公開されていることに意味があります。
その公開鍵を使えば、誰でもその相手宛ての暗号文を作れますが、復号できるのは対応する秘密鍵を持つ本人だけです。

南京錠の比喩も同じ発想です。
相手が開いた状態の南京錠を大量に配っていると考えてください。
筆者はその南京錠で箱を閉じて送れますが、閉じた箱を再び開けられるのは鍵を持つ本人だけです。
送り手は「閉じる」ことだけでき、受け手は「開ける」ことができます。
この非対称性こそが、公開鍵暗号の核心です。
共通鍵暗号のように、最初から両者が同じ鍵を持っている必要がありません。

もちろん、この比喩には限界もあります。
実際の公開鍵は金属の錠前ではなく数学的な構造で、公開鍵から秘密鍵を逆算できないことが前提です。
RSAなら公開鍵は通常 (n, e) の形で表され、秘密鍵は d です。
暗号化は C = M^e mod n、復号は M = C^d mod n と書けます。
式だけ見ると無機質ですが、意味としては「投入口は公開してよいが、取り出す能力は本人だけが保持する」という設計になっています。

直感に反するかもしれませんが、公開鍵は知られても困らないどころか、知られていないと仕組みが回りません。
守るべき対象は秘密鍵です。
通信相手の公開鍵を手に入れ、その鍵でランダムに生成した共通鍵を包んで送る。
受け手だけがそれを取り出し、以後の本文はAESで処理する。
この流れが、いまのウェブやアプリの暗号通信の基本形です。

Diffie–HellmanとRSAの歴史的位置づけ

公開鍵暗号の歴史では、1976年のDiffie–Hellmanと1977年のRSAが連続した転換点として並びます。
両者は同じ「非対称暗号」という大きな流れに属しますが、担った役割は少し違います。

Diffie–Hellmanが示したのは、事前に秘密を共有していない二者が、公開されたやり取りを通じて共通の秘密を作れるという発想でした。
これは鍵配送問題に対する衝撃的な回答で、「最初に同じ鍵を安全に渡せない」という壁そのものを、別の角度から乗り越えたことになります。
現代のTLS 1.3でエフェメラルなECDHEが鍵共有の中心にいるのは、この系譜の延長です。

その翌年に現れたRSAは、公開鍵で暗号化し、秘密鍵で復号するという形を広く理解可能なものにしました。
加えて、RSAは暗号化だけでなくデジタル署名にも使えます。
つまり「秘密を送る」と「本人性を証明する」という、通信の二つの柱にまたがる存在として普及したわけです。
1977年にRonald RivestAdi ShamirLeonard Adlemanが公表したこの方式は、公開鍵暗号を理論から実用へ押し出した代表例といえます。

この二つを対比すると、公開鍵暗号が何を変えたのかがはっきりします。
Diffie–Hellmanは「秘密を共有する方法」を変え、RSAは「公開してよい鍵と秘匿すべき鍵を分ける設計」を社会実装のレベルまで押し広げました。
どちらも、共通鍵暗号だけでは避けられなかった事前共有の制約を崩した点で画期的です。

ただし、現代の実装は歴史の教科書そのままではありません。
RSAは計算負荷が重く、教科書どおりの決定論的な使い方では安全になりません。
そのため暗号化ではランダム性を入れるOAEPのようなパディングを使い、署名でもRSASSA-PSSのような現代的な方式が選ばれます。
また、鍵交換の主役は静的なRSA鍵輸送からDiffie–Hellman系へ移りました。
TLS 1.3で静的RSA鍵交換が姿を消し、RSAは署名用途として残ったという事実は、その歴史的位置づけをよく表しています。

公開鍵暗号は、共通鍵暗号を置き換えた技術というより、共通鍵暗号を現実のネットワークで使えるようにした接着剤として捉えると腑に落ちます。
非対称という発想が入ったことで、離れた相手と最初の秘密を作れるようになった。
そこから先は高速な共通鍵暗号が引き受ける。
この役割分担が定着したことで、暗号は軍や外交の専用品ではなく、ブラウザ、スマホ、証明書、署名検証まで含む日常のインフラになりました。

RSAの仕組みを図でつかむ

鍵生成の全体像

RSAの流れは、まず2つの大きな素数 p と q を選ぶところから始まります。
ここで作る中心部品が n = p × q です。
この n は公開鍵にも秘密鍵にも関わる土台で、公開鍵の片方の値として外に出ます。
もうひとつ用意するのが φ(n) で、p と q が素数なら φ(n) = (p-1)(q-1) と書けます。
実装や証明の整理では、これより小さいことがあるカルマイケル関数 λ(n) を使う流儀もあります。

概念図にすると、頭の中では次のような並びです。

p, q を秘密に選ぶ （図示）工程は上から下へ順に進みます。
p と q を秘密に選び、n = p × q を作り、φ(n) を計算して e を選び、最後に d を決めて公開鍵 (n, e) と秘密鍵 d を得る一連の流れを示しています。
n = p × q を作る ↓ φ(n) を計算する ↓ e を選ぶ ↓ d を、e と組にしたとき逆向きに戻せる数として決める ↓ 公開鍵 = (n, e)、秘密鍵 = d`

ここでの肝は、公開してよいものと、絶対に伏せるものが分かれていることです。
n は公開してかまいませんし、e も公開します。
公開鍵は (n, e) です。
一方で、d は秘密に保持します。
実装上の秘密鍵は d だけでなく、復号や署名を速くするためのCRTパラメータも含みますが、まず骨格だけつかむなら「公開鍵は (n, e)、秘密鍵は d」で十分です。

筆者はこの部分を説明するとき、ノートに楕円の鍵穴を2つ描いて、片方に「公開鍵で閉じる」、もう片方に「秘密鍵で開く」と書き込みます。
数学の話に入る前に、施錠は誰でもできるが、開錠は持ち主だけという流れを手でスケッチすると、記号が急に道具として見えてきます。
RSAは式から入ると固く見えますが、図にすると「閉じる役」と「開ける役」が非対称に分かれた仕組みだとつかめます。

この時点では、なぜ p と q を2つ使うのか、なぜ n を公開してよいのかが気になるはずです。
直感としては、n は掛け算で作るのに、そこから元の p と q を取り出すのは難しい、という非対称性を利用しています。
ここが安全性の背景ですが、ここでは図の理解を優先して、まずは「2つの素数から作った合成数 n を公開鍵に載せる」と押さえておけば十分です。

暗号化/復号の対応関係

鍵ができたら、送る側は公開鍵で暗号化し、受け取る側は秘密鍵で復号します。式は教科書どおりに書くとこうなります。

暗号化は C = M^e mod n です。 復号は M = C^d mod n です。

図にすると、流れは次の一枚で見えます。

平文 M ↓ 公開鍵 (n, e) で施錠 C = M^e mod n ↓ 秘密鍵 d で開錠 M = C^d mod n

この図の見どころは、閉じるときと開けるときで使う鍵が違うのに、元の M に戻ることです。
送り手は秘密鍵を知りません。
それでも公開鍵 (n, e) だけで C を作れます。
受け手は d を使って C から M を取り戻します。
公開鍵暗号の「公開してよい鍵」と「秘匿すべき鍵」の役割分担が、ここにそのまま現れています。

では、なぜ逆向きが成立するのでしょうか。式をつなげると、逆向きも成り立ちます。

C^d = (M^e)^d = M^{ed} mod n

となるので、知りたいのは M^{ed} ≡ M (mod n) になる理由です。
ここが暗号の美しいところなのですが、d はただの適当な数ではなく、e と組にしたときに指数の掛け算 ed がうまく1周して戻るよう選ばれています。
φ(n) を使う書き方なら、ed が φ(n) と整合する形になるように d を決めます。
そうすると、オイラーの定理を足場にして「べき乗しても元に戻る」見通しが立ちます。
より引き締まった説明では λ(n) を使うとまとまりがよいのですが、この段階では 指数を2回かけても、合同式の世界ではちゃんと元のメッセージに戻るよう鍵が作られているという直感を持てれば十分です。
厳密な証明は後回しでも、仕組みの輪郭は崩れません。
この結果、ed が適切に選ばれていれば、合同式の世界では M に戻ることが期待できます。
要点は、d を e の逆元となるように選ぶことで、べき乗操作が「一周して戻る」性質を満たす点です。
もちろん、ここでいう M はそのままの文章ではなく、n を法とする整数として扱える形に載せたデータです。
教科書では単純な数に見えますが、実運用ではこの前後にエンコードやパディングが入ります。
とはいえ、図として理解する段階では、M を箱の中身、C を閉じた箱と見れば十分です。
送信者は公開鍵で箱を閉じられるが、秘密鍵がないと中身は取り出せません。

公開指数 e=65537 が選ばれる理由

実務では計算効率と安全性の折り合いが良く、2^16+1 の形をした e = 65537（0x10001）が広く選ばれています。
公開鍵の e は理論上いろいろ選べますが、実務では 65537 が主流です。
ブラウザの証明書表示で Exponent: 65537 を見かけるのは、そのためです。
16進数では 0x10001 で、ビットの立ち方が扱いやすく、公開鍵側の計算を軽く保ちやすい値です。

ここでの狙いは、計算効率と安全性のバランスです。
e が小さいと暗号化や署名検証は速くなります。
公開鍵演算は繰り返し二乗法で処理するので、1の立っているビットが少ない 65537 は都合がよいわけです。
一方で、小さすぎる指数には歴史的に扱いの難しい場面があり、パディングの不備と組み合わさると危うくなります。
3 のようなもっと小さい指数も理論上は使えますが、現代の運用では 65537 が収まりのよい選択として定着しました。

この値が広く採用されているのは偶然ではありません。
公開鍵演算の軽さを確保しつつ、乱暴に小さすぎる指数を避けられるからです。
証明書の観測でも e = 65537 がほとんどを占める状態になっており、教科書の例としても実務の感覚としても、この値を基準に理解しておくと見通しが合います。

ここでも図の発想に戻ると、e は「誰でも使える施錠側のハンドル」の重さを決めるつまみのようなものです。
軽すぎる設定には癖が出やすく、重すぎる設定は無駄が出る。
その中で 65537 は、公開鍵で閉じる処理を現実的なコストに保ちながら、長年の運用で安定してきた落としどころです。
数学的には e と φ(n) が互いに素になるよう選ぶ必要があり、その条件を満たしたうえで、広く使われている代表値が 65537 だと捉えると整理できます。

小さな数でRSAを実際に計算してみる

それでは、p と q を小さな素数に設定して、鍵生成→暗号化→復号の流れを手計算で追い、各手順の意味を体感してみましょう。

鍵生成を手計算する

抽象的に見える RSA も、小さな数に固定すると手で追えます。
教科書でよく使われる例として、素数を p = 61、q = 53 と置きます。
すると公開鍵の土台になる合成数は n = pq = 3233 です。
さらに、鍵作成で使うオイラーのトーシェントは φ(n) = (p-1)(q-1) = 60 × 52 = 3120 になります。

ここで公開指数として e = 17 を選びます。
条件は e と φ(n) が互いに素であることなので、17 と 3120 の最大公約数が 1 なら先へ進めます。
この例では条件を満たしています。
次に必要なのが秘密指数 d です。
d はただの大きな数ではなく、e × d ≡ 1 (mod 3120) を満たす数、つまり 17 の法 3120 における逆元です。

この逆元を出すところが、紙とペンで追うと急に RSA が生き物のように見えてきます。
筆者も最初は互除法の式を縦に並べていき、途中で「この引き算の列が本当に秘密鍵につながるのか」と半信半疑でした。
ですが、拡張ユークリッド互除法でたどると、ちゃんと d = 2753 に着地します。

まず通常のユークリッド互除法で割り算を並べます。

1. 3120 = 17 × 183 + 9
2. 17 = 9 × 1 + 8
3. 9 = 8 × 1 + 1
4. 8 = 1 × 8 + 0

最大公約数が 1 なので逆元が存在します。ここから 1 を 17 と 3120 の式に戻していきます。

1 = 9 - 8 × 1

そして 8 = 17 - 9 × 1 なので、8 は 17 と 9 の一次結合として表せます。

1 = 9 - (17 - 9) = 2×9 - 17

さらに 9 = 3120 - 17 × 183 を代入すると、8 を 3120 と 17 の線形結合で表せます。

1 = 2×(3120 - 17×183) - 17 = 2×3120 - 17×366 - 17 = 2×3120 - 17×367

したがって、

1 = 2×3120 + 17×(-367)

これは 17×(-367) ≡ 1 (mod 3120) を意味します。
負の値のままだと扱いにくいので 3120 を足して正に直すと、2753 となり、17×2753 ≡ 1 (mod 3120) つまり逆元は 2753 です。

-367 + 3120 = 2753

となり、d = 2753 が得られます。
実際に 17 × 2753 = 46801 で、46801 mod 3120 = 1 です。
ここまで手でたどると、秘密鍵が「どこかから与えられる謎の数字」ではなく、公開指数と φ(n) の関係から機械的に決まる量だと腹落ちします。

この例で鍵は次の形になります。公開鍵は (n, e) = (3233, 17)、秘密鍵は (n, d) = (3233, 2753) です。

暗号化と復号を追う

鍵ができたので、平文を 1 つの整数 M = 65 として暗号化してみます。RSA の教科書どおり、暗号文は

C = M^e mod n

で計算します。この例では

C = 65^17 mod 3233 = 2790

です。
指数が 17 乗と聞くと気が遠くなりますが、実際の計算は繰り返し二乗法で進めます。
つまり、65^2 mod 3233、65^4 mod 3233、65^8 mod 3233、65^16 mod 3233 を順に作り、17 = 16 + 1 なので最後に 65^16 × 65 を法 3233 でまとめます。
暗号の実装が高速に動く理由も、この積み上げ方にあります。
指数が 17 乗と聞くと大きく見えますが、実際の計算は繰り返し二乗法で効率的に進めます。
つまり、65^2 mod 3233、65^4 mod 3233、65^8 mod 3233、65^16 mod 3233 を順に作り、17 = 16 + 1 に対応させて最後にまとめるのです。
復号は逆向きに

M = C^d mod n

で行います。実際に代入すると

M = 2790^2753 mod 3233 = 65

となって、元の値に戻ります。
ここが暗号の美しいところなのですが、手元の数字が本当に輪を閉じる瞬間を見ると、式だけで読んだときと納得感が違います。
筆者も互除法は紙に書き、暗号化と復号は電卓や REPL で一歩ずつ追いました。
2790 になった値を 2753 乗して、最終的に 65 が現れたとき、「理屈として戻る」ではなく「本当に戻る」に変わります。

もちろん、この例は説明のために小さく作った教科書 RSA です。
現実の鍵では桁数がはるかに大きく、手計算はできません。
それでも、鍵生成で d がどう決まり、公開鍵で施錠した値が秘密鍵で元に戻る流れは、巨大な鍵でも同じです。
抽象論の芯はこの小さな例にそのまま入っています。

[!NOTE] この手計算は「RSA の構造を理解する練習」として最適ですが、実用の RSA はこのままの裸の形では使いません。
実務では前述のパディングを組み合わせて安全性を確保します。

文字列を数に写像する考え方

ここまでの例では M = 65 という整数をそのまま入れましたが、現実の平文は文字列やバイト列です。
そこで実務では、まずデータを整数にエンコードしてから RSA の演算に載せます。
たとえば文字をバイト列にし、そのバイト列を 1 つの大きな整数とみなす、という発想です。
英字 1 文字なら ASCII の数値に対応づける見方もできますし、複数文字なら連結したバイト列をまとめて整数にします。

ただし、ここには 1 つはっきりした条件があります。
RSA に入力する整数 M は M < n でなければなりません。
今回の例では n = 3233 なので、3233 以上の整数はそのまま 1 ブロックとして入れられません。
だから実務では、データをブロックに分けて各ブロックを整数化し、各整数が n より小さくなるように扱います。

この「文字列を数に写す」という段階を意識すると、RSA が文章を直接読んでいるわけではなく、整数の世界で演算する仕組みだと見えてきます。
たとえば A を 65 とみなすような単純化は学習用として便利ですが、実運用ではもっと一般的に「任意のバイト列を整数へ写像する」と捉えるほうが自然です。
そのうえで RSA が扱うのは、あくまで 0 以上 n-1 以下の整数です。

この感覚があると、前の節で出てきた M^e mod n も、急に読みやすくなります。
暗号化している対象は文章そのものではなく、文章をきちんと整数へ載せ替えた結果です。
RSA を手計算で追う価値は、こうした前処理も含めて「どこまでが数学で、どこからがデータ表現なのか」の境界が見えるところにあります。

なぜ公開鍵から秘密鍵を求めにくいのか

素因数分解問題とRSA問題

RSA の安全性は、大きな合成数 n = pq を素因数分解するのが計算量的に難しいという仮定の上に立っています。
ここでいう「難しい」は、数学的に不可能という意味ではなく、十分大きな桁数では現実的な計算資源で解くのが見合わない、という意味です。
公開鍵には n と e が含まれますが、秘密鍵 d を作るには本質的に φ(n) の情報が要ります。
そして φ(n) を知るには、通常は n を構成する素数 p と q を知る必要があります。
だから公開鍵から秘密鍵を逆算する道筋は、結局のところ素因数分解へぶつかります。

ここで直感に反するかもしれませんが、RSA で本当に問われている問題は「n を分解できるか」だけではありません。
暗号として見たときの中心は、与えられた公開鍵 (n, e) と暗号文 C から平文 M を求める RSA問題 です。
これは「復号そのものの困難性」を表した問題で、素因数分解問題とは深く結びついています。
実際、n を分解できれば φ(n) を計算でき、d を求めて復号できます。
その意味で、素因数分解が解ければ RSA も破れます。

ただし、RSA問題と素因数分解問題が一般的に同値であることは未証明です。
つまり、RSA問題を効率的に解ける方法が見つかったとしても、それが必ずしも任意の大きさの整数に対する効率的な素因数分解法の存在を意味するとは証明されていません。
この点は入門記事では省略されがちですが、安全性の議論を正確にするなら外せないところです。
RSA は「素因数分解が難しいから安全」と説明して大筋では合っていますが、厳密には「RSA問題と素因数分解問題は強く関連しており、実用上はその困難性に依拠している」と捉えるのが適切です。

筆者がこの感覚をつかんだのは、学習用の小さな n = 3233 をオンラインの因数分解ツールに入れたときでした。
61 × 53 への分解は一瞬で返ってきます。
ところが、対象が数百ビット級に上がると、同じ「分解する」という言葉でも様相が一変します。
小さな教材例で見ていた世界と、実運用の鍵長で見ている世界は地続きでありながら、計算量の壁の高さがまるで違います。
RSA が頼っているのは、その壁です。

なお、実装では CRT（中国剰余定理）を使って秘密鍵演算を高速化することがあります。
これは mod p と mod q に分けて計算してから結果を合成する最適化で、秘密鍵処理を軽くするための工夫です。
ここで変わるのは計算手順だけで、RSA の安全性仮定そのものは変わりません。
速く計算するための実装上の技法であって、「分解しにくさ」の根拠が別物になるわけではない、という整理になります。

歴史的な補足も触れておくと、RSA は 1977 年に公開され、その後は特許の影響がありましたが、RSA 特許US 4,405,829は 2000 年 9 月に満了しました。
以後は自由に利用できる公開鍵暗号として広く定着しています。
数学の美しさだけでなく、制度面の障壁がなくなったことも普及の背景にあります。

一般数体篩法（GNFS）とは

大きな整数をどう分解するのかという点で、古典計算機上の既知手法として代表的なのが 一般数体篩法（GNFS: General Number Field Sieve） です。
RSA の法 n が特別な形をしていない一般の大きな合成数であるとき、GNFS は実用的に最も有力な素因数分解アルゴリズムとして扱われます。

発想を大づかみに言えば、GNFS は「正面から割り算を繰り返す」方法ではありません。
ある種の合同関係を大量に集め、そこから平方剰余の構造を引き出して、最終的に n の非自明な因子を得ます。
細部は数論と線形代数が組み合わさった長い手順になりますが、ポイントは、単純な総当たりよりずっと洗練されていることです。
RSA の安全性を考えるとき、敵は素朴な試し割りではなく、この種の最先端アルゴリズムです。

だからこそ、RSA の鍵長は「何桁なら大丈夫そうか」ではなく、「GNFS のような既知の最速級アルゴリズムに対して、どれだけ計算資源を要求するか」という観点で決まります。
暗号設計では、相手が最善の既知手法を使う前提で考える必要があります。
安全性は楽観ではなく、最悪寄りの想定で見積もるものです。

ここでも誤解されやすいのが、CRT による高速化との関係です。
CRT を使うと秘密鍵演算は速くなりますが、それは正規の復号者が持つ p と q を活用しているからです。
攻撃者が公開鍵から秘密鍵を求める難しさ、つまり GNFS が相手にしている問題の大きさとは別の話です。
実装が賢くなっても、公開鍵から p と q を引きはがす難しさそのものは残ります。

鍵長2048bit以上の現状評価

現代の実務では、適切に生成された RSA-2048 以上の鍵は、古典計算機を前提にすれば実用上安全という評価が定着しています。
運用上よく使われる長さは 2048bit、3072bit、4096bit で、強度余裕と処理負荷の折り合いで選ばれます。
2048bit は広い互換性と実用性のバランスが取れた標準的な選択で、3072bit はより長期の余裕を見込みたい場面で採られます。
4096bit まで伸ばすと秘密鍵演算の重さが目に見えて増えるため、単純に「長ければよい」とも言えません。

強度の目安としては、RSA-2048 は 112 ビット安全性級、RSA-3072 は 128 ビット安全性級の文脈で語られます。
この比較軸に立つと、楕円曲線暗号の 256bit 級が RSA-3072 と近い水準に置かれる理由も見えてきます。
公開鍵暗号は鍵長の数字をそのまま横並びに見ても意味がなく、背後にある問題の難しさで読む必要があります。

ここでの「安全」は、もちろん古典計算機に対する現状評価です。
量子計算機の文脈では事情が変わります。
1994 年に示されたShorのアルゴリズムは、十分に実用的な量子計算機が実現すれば整数の素因数分解を多項式時間で進められることを示しました。
理論上は RSA にとって本質的な脅威です。
このため、公開鍵基盤の世界ではポスト量子暗号への移行が進み始めています。
ただし、現時点で広く運用されている RSA-2048 や RSA-3072 が、通常の古典計算環境で直ちに破られるという話ではありません。
現行システムの安全性評価と将来の移行戦略は、同じ話題の中にありつつ、時間軸が異なります。

筆者の実感としても、小さな教材例を触っていると RSA は「分解できそう」に見えてしまいます。
ですが、実運用の 2048bit 鍵を前にすると、その感覚は役に立ちません。
暗号の強さは、式の見た目より、既知最速アルゴリズムに対してどれだけ計算量が膨らむかで決まります。
公開鍵から秘密鍵が求まりにくい理由は、秘密の式が隠されているからではなく、公開されている n の背後にある素因数分解が、現在の計算資源では手に負えない規模に置かれているからです。

教科書どおりのRSAをそのまま使わない理由

教科書RSAの落とし穴

ここまで見てきた RSA の式は、仕組みを理解するためには美しいのですが、そのまま実装に持ち込むと安全ではありません。
いわゆる教科書RSA（textbook RSA）は、公開鍵で平文 m をそのままべき乗して暗号文にする考え方です。
この方式は決定論的で、同じ平文を同じ公開鍵で暗号化すると、毎回まったく同じ暗号文になります。

直感に反するかもしれませんが、これは暗号としては困る性質です。
たとえば候補になる平文が短く、しかも数が限られている場面では、攻撃者は候補を順に公開鍵で暗号化し、得られた暗号文を見比べるだけで中身を推測できます。
平文そのものを復号しなくても、「この候補と一致した」という照合で当たってしまうからです。
yes か no のように候補が少ないデータ、短いコード値、固定的なフラグ類は、この種の比較に弱くなります。

筆者も、学習用に簡単なスクリプトを書いてこの挙動を確かめたことがあります。
同じ文字列を教科書RSAで何度か暗号化すると、出てくる暗号文が毎回ぴたりと一致しました。
最初は「数学通りに動いていて気持ちいい」と感じるのですが、暗号として見るとむしろ危険信号です。
そのあと OAEP をかぶせて同じ平文を暗号化すると、今度は毎回異なる暗号文になりました。
この差を一度見ると、実装でランダム性を加える意味が腹落ちします。

RSA 暗号化で必要なのは、ただ計算できることではなく、同じメッセージでも毎回見え方を変えることです。
そこで使われるのがパディング、より正確には安全性を意識したエンコード方式です。
RSA 本体の数論だけでは足りず、その前段で平文にランダム性を混ぜ込む設計が必要になります。

PKCS#1 v1.5とBleichenbacher攻撃

RSA の実装では、歴史的に PKCS#1 v1.5 という暗号化パディングが広く使われてきました。
教科書RSAの決定論性を避けるためにランダム値を入れる点では前進でしたが、これで万事解決とはなりませんでした。
暗号の世界では、平文の見え方だけでなく、復号時のエラーの返し方まで攻撃面になることがあります。

その代表例が、1998年に公表された Bleichenbacher攻撃です。
これはPKCS#1 v1.5の復号結果が「形式として正しいかどうか」を外部から少しでも観測できると、その反応を足掛かりに平文へ迫れるという選択暗号文攻撃です。
数式を真正面から破るというより、実装が返す yes/no の反応を情報源に変えてしまう攻撃だと捉えるとイメージしやすいはずです。

ここが暗号の実務で怖いところで、アルゴリズム名だけ見て「RSA を使っているから安全」とは言えません。
実際には「RSA の前にどのパディングを置いたか」「復号失敗をどう扱うか」「通信プロトコルがその差を外に漏らさないか」まで含めて安全性が決まります。
PKCS#1 v1.5は長く使われ、互換性の都合で残っている場面もありますが、歴史的な攻撃事例を踏まえると、扱いは慎重であるべき方式です。

この文脈は、RSA の署名方式と混同しないように整理しておくと見通しがよくなります。
ここで話しているのは暗号化のパディングです。
署名では別の設計が必要で、現代的には RSASSA-PSS のような方式が主役になります。
OAEP は暗号化、PSS は署名という役割分担で考えると、頭の中が整理されます。

RSA-OAEPの役割とハッシュ/MGF設定

現代の RSA 暗号化で標準的な選択肢になるのが RSA-OAEP です。
OAEP は Optimal Asymmetric Encryption Padding の略で、平文にランダム性を導入し、そのうえで RSA に渡すための方式です。
教科書RSAのように同じ平文が同じ暗号文へ固定されることを避け、実用上の安全性を引き上げる役割を担います。

OAEP の感覚的な理解としては、「平文をそのまま RSA に入れないで、乱数とハッシュを使って一度かき混ぜてから暗号化する」と考えると近いです。
このランダム化によって、同じ平文を同じ鍵で暗号化しても、暗号文は毎回異なります。
先ほど触れた筆者の検証でも、OAEP をかけた瞬間に暗号文の見え方が一変しました。
比較照合で平文を当てる、という教科書RSAの素朴な攻撃筋が、その時点で崩れます。

OAEP で見逃せないのが、ハッシュ関数と MGF（Mask Generation Function） の設定です。
実務では MGF1 を使う構成が一般的で、ハッシュには SHA-256 系が選ばれます。
ここで大切なのは、単に「OAEP」と書いてあれば同じではないことです。
RSA-OAEP という名前の裏側には、どのハッシュを使うか、MGF1 に何を指定するかという具体設定があります。
送信側と受信側でこの指定が揃っていなければ復号できませんし、設計の古い組み合わせを引きずると現代的な選択から外れます。

実務でよく案内される表記の一つが RSA-OAEP-256 です。
これは SHA-256 系を使う OAEP を指す呼び方で、現在の運用ではこの系統が中心です。
SHA-1 系の OAEP も互換性のために残っている場面はありますが、新規設計の中心に置く位置づけではありません。
暗号スイート名だけで安心せず、OAEP の中身が SHA-256 と MGF1 で整っているかまで読んで初めて、設定を正しく理解したことになります。

[!NOTE] RSA を安全に使ううえでの実務感覚は明快で、暗号化はRSA-OAEP、署名はRSASSA-PSSという別設計で捉えると混乱が減ります。
同じ "RSA" の名前でも用途に応じた前処理を必ず確認してください。

RSA は数式だけ眺めると単純なべき乗計算に見えますが、実際の安全性はその前後の設計で決まります。
教科書どおりの RSA は学習用として価値があります。
しかし現場で必要なのは、ランダム性を加え、攻撃者に比較材料を与えず、復号処理のふるまいまで含めて整えた RSA です。
暗号アルゴリズムを「式」として理解する段階から、「安全なスキーム」として扱う段階へ進むとき、OAEP の存在は避けて通れません。

RSAは現代のインターネットでどう使われているか

ハイブリッド暗号の流れ

日常的に使っているHTTPSの通信では、RSA がファイル本体やWebページ本文をそのまま暗号化しているわけではありません。
実際のTLS/SSLはハイブリッド暗号として動いており、公開鍵暗号と共通鍵暗号を役割分担させています。
ここが現代のインターネットでのRSAの立ち位置を理解する要点です。

流れをざっくり言えば、ハンドシェイクの最初の段階で「相手が本物のサーバーか」を証明し、そのうえで通信に使うセッション鍵を安全に共有し、以後の本文はAESのような共通鍵暗号で暗号化します。
公開鍵暗号は鍵配送やデジタル署名には向いていますが、本文を丸ごと処理するには重すぎます。
RSA の公開鍵演算は比較的軽くても、秘密鍵側の処理は負荷が高く、しかも公開鍵暗号そのものが共通鍵暗号より桁違いに遅いからです。
ブラウザで画像やHTML、APIレスポンスを高速にやり取りできるのは、本文の暗号化をAES側に任せているからです。

この分担は、宅配便のたとえで考えると腑に落ちます。
RSA は「鍵付きの小箱を安全に渡す仕組み」、AES は「大量の荷物を速く運ぶトラック」に近い存在です。
RSA で毎回すべての荷物を運ぶ設計にすると、計算量も通信量も膨らみます。
そこでTLS/SSLでは、最初に公開鍵暗号で安全な足場を作り、そのあと本データは共通鍵で一気に処理します。

サーバー証明書がここで果たす役割も見逃せません。
ブラウザは受け取った証明書を検証し、その公開鍵が本当にそのサーバーのものだと確認します。
ここで登場するのがRSAのデジタル署名です。
RSA は「秘密を隠す暗号」としてよりも、「正しい相手だと証明する署名」の側面で触れる機会が増えました。
証明書チェーンの検証でも、サーバーがハンドシェイク中に示す署名の確認でも、RSA は信頼の連鎖を支える部品として働きます。

筆者がWiresharkでTLSハンドシェイクを眺めたときも、面白かったのは暗号化された本文より前の部分でした。
Certificateメッセージを開くと、証明書まわりに rsaEncryption が見えたり、署名アルゴリズムとして rsaPSS を確認できたりします。
ブラウザの錠前アイコンだけだと「RSAを使っている」程度の理解で終わりがちですが、パケットをのぞくと、RSA が本文暗号ではなく認証と署名の側に置かれていることが手触りとして見えてきます。

TLS 1.3時代のRSAの位置づけ

現代のTLSを語るなら、TLS 1.3でRSAの役割が整理し直された点を押さえる必要があります。
古い世代のTLSでは、RSA がサーバー公開鍵を使ってプレマスターシークレットを直接包む、いわゆるRSA鍵交換が使われていました。
歴史的にはこれが「TLSでRSAが使われる」の代表例でしたが、現在の主流ではこの位置は後退しています。

TLS 1.3では、鍵交換は主にECDHEやDHEのようなエフェメラルDiffie-Hellman系が担います。
セッション鍵を作る中心はRSAではなく、前方秘匿性を持つ鍵共有です。
RSA はハンドシェイクから消えたわけではなく、サーバー証明書の署名検証やCertificateVerify の署名といった認証の場面に軸足を移しました。
ここが直感に反するかもしれませんが、現代のTLSでRSAが残っている理由は「鍵交換が得意だから」ではなく、「既存PKIとの親和性が高く、署名基盤として広く普及しているから」です。

この変化を見ると、RSA の役割は「秘密を運ぶアルゴリズム」から「相手の正当性を証明するアルゴリズム」へと比重が移ったと言えます。
たとえばRSA 2048の証明書は今でも広く見かけますし、より余裕を見た構成ではRSA 3072やRSA 4096もあります。
ただし、鍵長を伸ばすほど秘密鍵演算は重くなります。
サーバーが同時に多くの接続をさばく場面では、この重さがCPU負荷として効いてきます。
ここでECDSA P-256のような楕円曲線署名が選ばれる理由も見えてきます。
一般にECC 256bitはRSA 3072bitに近い強度感で扱われ、証明書サイズや署名サイズの面でも軽量です。

とはいえ、RSA が時代遅れという話ではありません。
互換性の広さ、証明書運用の成熟度、監査やHSMとの親和性を含めて、RSA は今も実務の中心にいます。
ただし主戦場は本文暗号ではなく、署名と証明書です。
Wireshark で実際にハンドシェイクを追うと、その構図がよく見えます。
鍵共有の部分は key_share を通じて進み、証明書側では rsaEncryption や rsaPSS が現れる。
この分業を目で確認すると、TLS 1.3 でのRSAの現在地が一気に具体化します。

[!NOTE] 現代のTLSを一文で捉えるなら、鍵交換は主に（EC）DHE、実データ暗号化はAES、RSAは証明書とデジタル署名、という分担が実務の中心です。

公開指数 e=65537 の実観測

RSA の公開鍵を開くと、モジュラス n と並んで公開指数 e が入っています。
そして現実の証明書を見ていると、この e はほとんど同じ値です。
事実上の標準になっているのが 65537 です。
証明書の観測でも大半がこの値に集中しており、公開指数は「各サイトが自由にバラバラの値を選んでいる」というより、実務上ほぼ固定パラメータとして扱われています。

なぜ 65537 なのか。
理由は、公開鍵側の計算を効率よく保ちつつ、小さすぎる指数にまつわる古い設計上の問題を避けやすい、ちょうどよいバランスにあるからです。
2の累乗に1を足した形なので実装上も扱いやすく、公開鍵演算の回数を抑えられます。
公開鍵暗号の世界では、数学的にどんな値でもよいわけではなく、「安全性と性能の折り合いがついた定番」が残ります。
65537 はその代表例です。

この値は証明書ビューアでもすぐ見つかりますし、ブラウザの証明書詳細に Exponent: 65537 と出ることも珍しくありません。
筆者も検証用に複数の証明書を開いて確認しましたが、公開指数の欄はほぼこの値で揃っていました。
Wireshark で証明書を展開したときも、署名アルゴリズムとして rsaPSS が見え、公開鍵情報側では rsaEncryption とともに指数が定番どおり並んでいて、「理論の教科書で見た値が、そのまま本番環境でも流れている」と実感した記憶があります。

小さなコラムとして覚えておくと面白いのは、RSA では「公開鍵演算は軽め、秘密鍵演算は重め」という非対称性が、こうしたパラメータ選びにも表れていることです。
公開指数を 65537 に寄せるのは、サーバーやクライアントが大量に行う公開鍵側の検証を無駄なく回すためでもあります。
証明書検証はインターネット全体で何度も繰り返される処理なので、こうした“地味な定番値”が積み重なって全体の効率を支えています。

RSAとECC、そして耐量子暗号への移行

強度目安の比較表

現代の公開鍵暗号をざっくり俯瞰すると、互換性の広いRSAと、より短い鍵で同等級の強度を確保できるECCが並び立っています。
実務ではこの「同等級」という感覚が設計判断の軸になります。
証明書の鍵種別を選ぶときも、署名の重さやチェーン全体のサイズを見るときも、まずは安全性の目安を同じ土俵に並べる必要があります。

代表的な比較は次の通りです。
ここでいうビット安全性は、鍵長そのものではなく、攻撃コストの目安を共通の尺度に載せたものです。
RSA 2048は約112ビット安全性、RSA 3072は約128ビット安全性として扱われる文脈が定着しており、ECC 256、具体的にはsecp256r1（NIST P-256）はRSA 3072相当の強度感で語られます。
比較の整理にはCRYPTRECの強度対応表やDigiCertの解説がよく整っています。

ここで暗号の美しいところなのですが、強度目安が近くても、データの大きさは同じになりません。
RSAは同等の安全性を得ようとすると鍵が長くなり、署名も大きくなります。
たとえばRSA-2048の署名はモジュラス長に対応するため256バイトです。
一方でECDSA P-256の署名は典型的な生の表現で64バイト程度で、TLS や証明書のエンコードでは多少前後するものの、感覚としてはRSA-2048署名のほうがひと回りどころか数倍大きいと捉えて差し支えありません。

筆者も同一サイトでRSA 2048とECDSA P-256の証明書チェーンを差し替えて見比べたことがあります。
ページロード全体が別物になるほどの差ではありませんが、証明書チェーンの転送量と検証時のCPU使用量に、じわっとした違いが出ます。
とくに接続を何度も繰り返して観察すると、ECDSA P-256のほうが証明書まわりが軽く、ブラウザ側の検証も少しすっきり進む感触がありました。
単発の閲覧では見逃す程度の微差でも、接続回数が積み上がるサービスでは無視しづらい差になります。

ECCの実装上の利点

ECCの強みは、理論上の強度比較だけでなく、実装したときの取り回しにもあります。
同等級の強度なら鍵が短く、署名も短い。
この性質は、証明書サイズ、ハンドシェイクで流れるデータ量、署名生成や検証の計算量にそのまま跳ね返ります。
TLS 1.3で鍵交換の中心がECDHEへ移り、証明書でもECDSA P-256が広く使われるようになった背景には、この軽さがあります。

とくにモバイル端末や組込み機器では、鍵や署名のサイズ差がそのまま扱いやすさの差になります。
通信路が細い場面では証明書チェーンの数百バイト単位の増減が効きますし、CPUや電力に余裕の少ない機器では、署名検証の積み重ねが無視できません。
RSAは成熟した実装資産と互換性で依然強い存在ですが、同じ128ビット級を狙うならECC-256のほうが全体を軽くまとめやすい、というのが現場での実感です。

実装者の視点でも、ECCはモダンなTLSスタックとの相性がよい場面が多くあります。
証明書、鍵共有、署名の各要素が楕円曲線系で揃うと、構成の見通しが立ちやすく、性能面でも素直です。
もちろん曲線選定やライブラリの品質は前提になりますが、P-256のように普及した曲線はサポートが厚く、運用知見も蓄積されています。
RSA-3072へ鍵長を伸ばしていくと、強度の余裕と引き換えに秘密鍵演算の重さが前面に出てきます。
そのため、性能と強度の釣り合いを考えるとECC-256へ寄る設計が自然に見えてきます。

量子計算機と移行の現在地

ただし、RSAとECCはどちらが勝ち残るかという二者択一では終わりません。
両者には共通の長期課題があります。
量子計算機上で動くShor のアルゴリズムは、整数の素因数分解と離散対数問題を多項式時間で解けるため、理論上はRSAにもECCにも効きます。
RSAは素因数分解、ECCは楕円曲線上の離散対数に安全性を依存しているので、十分な規模の誤り訂正量子計算機が実現した世界では、どちらも計算量的な前提が崩れます。

現状は明確に移行期です。NIST による標準化作業や各社の実験導入が進む一方で、互換性や実装成熟度を踏まえた段階的な移行が現実的です。

インターネットの現場感をつかむにはCloudflareの2025年の観測がわかりやすく、PQC対応通信はすでに珍しい実験ではなくなっています。
ただし主流の考え方は、従来方式を即座に捨てることではなく、ハイブリッド運用で安全側に倒しつつ移行することです。
従来の公開鍵方式とPQCを組み合わせ、互換性を保ちながら切り替える設計です。
この発想の中心にあるのがアルゴリズム・アジリティ、言い換えると「暗号方式を固定観念なく差し替えられる構成」にしておくことです。

国内でもこの流れは同じで、NTTデータのPQC移行ホワイトペーパーのように、資産棚卸し、長期保護データの洗い出し、プロトコル単位の優先順位づけを進める整理が定着しています。
公開Web、社内PKI、コード署名、長期保管文書では移行の難しさが異なるため、単純な一斉切替にはなりません。
だからこそ、今の段階で見るべきポイントは「RSAかECCか」だけではなく、「将来PQCへ乗り換えられる構成になっているか」です。

日本語で全体像を押さえる入口としては、CRYPTRECの暗号リストや関連ガイドラインが整理に向いています。
安全性の等級、推奨アルゴリズム、用途別の位置づけを国内実務の文脈で確認できるからです。
公開鍵暗号の選択は、もはや単一アルゴリズムの優劣だけでは決まりません。
RSAは成熟と互換性、ECCは軽量さと効率、そしてPQCは将来耐性という軸で並び、設計はその三者を見ながら進む段階に入っています。

比較と選び方の要点

用途別の推奨と注意

比較の軸を先に整理すると、RSAは互換性の広さと歴史の長さが武器で、ECCは同等強度をより小さい鍵で実現できる軽さが武器です。
一方、実データの暗号化そのものはAESのような共通鍵暗号が担います。
ここが暗号の美しいところなのですが、公開鍵暗号は「何でも1本で済ませる万能鍵」ではありません。
RSAは鍵配送問題、つまり安全に共通鍵を渡す難しさを解決するために使われ、実際の本文データは高速な共通鍵暗号へ渡す。
このハイブリッド構成が現代インターネットの基本形です。

そのため、ファイル全体や通信本文をRSAで直接暗号化する発想は、実務では素直ではありません。
処理負荷が重く、扱える平文長にも制約があるからです。
RSAに向いているのは、共通鍵のラップ、証明書の公開鍵、署名検証基盤のような「入口を守る役割」です。
通信路ではTLS 1.3以降、静的RSA鍵輸送は退き、鍵共有はECDHE系、認証や署名でRSAまたはECDSAを使う構図が鮮明になりました。
暗号化用途のRSAと署名用途のRSAは、数式の骨格が近くても運用上は別物として見るべきです。

RSAとECCの選択は、理論比較だけでなく、既存資産との接続で決まる場面が多くあります。
社内PKI、古い機器、既存証明書運用との整合を優先するならRSAが残る理由ははっきりしています。
逆に、モバイル通信、組込み機器、高トラフィックのWeb終端ではECCの軽さが効きます。
ECC-256がRSA-3072級の強度感を、小さな鍵サイズで実現するためです。
筆者が検証業務で構成表を読むときも、互換性を最優先したい基盤ではRSA、性能と帯域を削りたい新規構成ではP-256が自然に候補へ上がりました。

注意したいのは、方式名だけ見て安心しないことです。
RSAを選んでも、暗号化に教科書RSAを使えば意味がありません。
教科書RSAは決定論的で、同じ平文から同じ暗号文が出るため、実用上の前提を満たしません。
暗号化ならRSAES-OAEP、署名ならRSASSA-PSSという現代方式まで含めて、はじめて「RSAを正しく選んだ」と言えます。
古いPKCS#1 v1.5は歴史的な実装資産が多い一方で、運用上の神経を使う場面が増えるため、新規設計で積極的に選ぶ理由は薄くなっています。

クラウドKMSの画面でアルゴリズムを選ぶ作業でも、この違いはそのまま表れます。
筆者が実務で触れるときは、まず鍵の用途を「暗号化」か「署名」かで分け、暗号化鍵ならRSA-OAEP-256、署名鍵ならRSASSA-PSSを選びます。
ここで迷いやすいのが、ハッシュとマスク生成関数の組み合わせです。
OAEPではハッシュとMGF1の設定が食い違うと、復号側で想定通りに通らない構成になります。
署名ではPSSの salt 長さまで含めて整合が取れているかを見る必要があります。
UI上はプルダウンを1つ選ぶだけに見えても、裏では「何に使う鍵か」「相手側がどの方式を受け付けるか」を先に確定しておかないと、あとから鍵の作り直しになりがちです。

鍵長と性能のトレードオフ

RSA-2048とRSA-3072の違いは、強度の余裕と計算負荷の交換だと捉えると整理しやすくなります。
前者は広い互換性を持つ標準的な選択で、後者はより長い保護寿命や厳しめの要件を見据えた選択です。
ただし、鍵長を伸ばすと秘密鍵演算は確実に重くなります。
署名生成、復号、ハンドシェイク時のCPU消費にそのまま返ってくるため、単に「長いほど安全」とだけ言って済む話ではありません。

この差は、数字以上に運用の感触へ出ます。
RSA-2048の署名は256バイトで、証明書やハンドシェイクに載る追加データとしては大きめです。
ECDSA P-256系と比べると、署名サイズだけでも見た目に差があります。
単発の通信なら埋もれますが、接続回数が積み上がる公開サービスでは、証明書チェーンの転送量と検証コストの差がじわじわ効いてきます。
前のセクションで触れた通り、ECCが好まれる理由はこの積み重ねにあります。

RSAは公開鍵演算の理解が比較的直線的で、既存システムとの折り合いもつけやすい方式です。
公開指数として65537が定番なのも、この実務上の安定感と結びついています。
証明書で長く使われてきたため、設定や監査の現場で会話が通じやすいことも利点です。
新旧さまざまな機器が混在する環境では、この「理解されていること」自体がコスト削減につながります。

ただし、性能面まで含めて俯瞰すると、RSA-3072へ伸ばすくらいならECC-256へ寄せたほうが、同等級の強度をより軽い構成で実現できる場面は多くあります。
とくに多数の同時接続を受けるWebサーバでは、その差がCPU使用量とレイテンシに現れます。
証明書の公開鍵方式をECDSA P-256にした構成は、同じハードウェアでもハンドシェイク処理が軽くまとまりやすく、サーバ側の息切れが起きにくい印象があります。
RSAが不利というより、「鍵長を積み増して強度を確保する設計」が、現代の通信基盤では重く映るというほうが実態に近いです。

ここでもう一つ切り分けておきたいのが、暗号化用途のRSAと署名用途のRSAです。
暗号化で使うならOAEP、署名で使うならPSSという区別は、単なる規格の好みではありません。
攻撃モデルが異なるので、防御の形も変わります。
数学の骨格が同じでも、パディングやエンコーディングが変われば安全性の前提が変わる。
直感に反するかもしれませんが、「RSAを使っている」という言い方だけでは、実務上ほとんど情報になりません。
鍵長、用途、パディング方式まで並べて、初めて比較可能な設定になります。

実装時のチェックリスト

実装段階では、方式名だけでなくパラメータの組をひとまとまりで固定する視点が欠かせません。
RSA-OAEP-256なら、RSA鍵長、OAEP、ハッシュ、そしてMGF1に使うハッシュが揃っている必要があります。
RSASSA-PSSなら、ハッシュ関数、salt 長さ、検証側の期待値まで一致していないと運用は崩れます。
たとえばSHA-256を使うPSSでは、salt 長さをハッシュ出力長に合わせる構成がよく使われますが、署名長そのものは鍵長で決まるので、RSA-2048なら署名は256バイトのままです。
内部構造と最終出力のサイズを混同しないことが、トラブル回避の第一歩になります。

実務で見るべき点を絞るなら、次の3つに集約できます。

1. 鍵の役割を先に固定すること

暗号化鍵なのか署名鍵なのかを曖昧にしないことが出発点です。
KMSの鍵作成画面でも、ここを先に分けるだけで選ぶアルゴリズムが定まります。
暗号化用途にPSS、署名用途にOAEPという取り違えは、画面上では似て見えても役割が逆です。

1. パディングとハッシュをセットで扱うこと

OAEPとPSSは、どちらもハッシュとMGF1の指定が実装の一部です。
送信側と受信側、署名側と検証側で片方だけ設定が違うと、原因が見えにくい失敗になります。
ライブラリのデフォルト値に任せた結果、片側だけ別ハッシュになっていた、という事故は珍しくありません。

1. 互換性の境界を構成表に明記すること

RSASSA-PSSは現代的な署名方式ですが、古いクライアントや機器を相手にすると詰まる地点があります。
RSAという単語だけを台帳に残すのではなく、RSA-PSSRSA-OAEP-256のように方式名まで書き切ると、更新時の混乱が減ります。
アルゴリズム・アジリティは、抽象論ではなくこの粒度の記録から始まります。

[!WARNING] この順序を守ることで手戻りを減らし、暗号化鍵と署名鍵の混線を防げます。
運用設計まで含めると、将来の移行余地も見逃せません。
RSA-2048で始めるのか、RSA-3072へ伸ばすのか、ECC-256へ寄せるのか、さらに先でPQCとのハイブリッドを視野に入れるのか。
この判断は単独のアルゴリズム比較ではなく、証明書、TLS終端、KMS、署名基盤を横断して整合が取れているかで決まります。
暗号の選び方は、結局のところ「いま安全に動くこと」と「数年後に無理なく差し替えられること」を両立させる設計問題です。

まとめと次のアクション

公開鍵で暗号化し、対応する秘密鍵でだけ戻せるのは、同じ鍵を事前共有しなくてよい点に公開鍵暗号の価値があるからです。
共通鍵暗号が抱える鍵配送問題に対し、RSAは「渡してよい鍵」と「隠す鍵」を分けることで入口を開きました。
紙と電卓で追った小さな例は、その対応関係が偶然ではなく数学で結び付いていると腹落ちさせてくれます。
手計算を終えたら、自分のノートに今日の理解メモとして鍵の対応図と式を書き写しておくと、記憶が驚くほど残ります。

次に進むなら、実装では教科書RSAではなく暗号化はRSAES-OAEP、署名はRSASSA-PSSを前提に設定名まで確認してください。
そのうえで、RSAが実際にどこで使われるかをつかむためにTLSとデジタル署名の流れまで読むと、証明書やハンドシェイクの見え方が変わります。
将来の更新計画まで含めて考えるなら、CRYPTRECの暗号リストや各社ホワイトペーパーを定期的に見直し、PQC移行の足並みを追う視点も持っておくと判断がぶれません。