RSAって結局何?どの鍵長が安全?TLS/HTTPSやSSHではどう使う?署名やパディング、脆弱性、そして量子時代への備えまで気になる疑問を一気に解消します。
この記事は、RSAの仕組みと実務のベストプラクティスをやさしく図解し、失敗しない設定と運用の要点を短時間で把握できる導入ガイドです。
この記事は以下のような人におすすめ!
- RSA(Rivest–Shamir–Adleman)とは何か知りたい
- どのような仕組みで動作するのか具体的に知りたい
- 公開鍵暗号の基礎と歴史が知りたい
目次
RSAとは何か:基本と目的
インターネットで安全に情報をやりとりするための代表的な技術が「RSA」です。
RSAは公開鍵暗号の一種で、だれでも共有できる「公開鍵」と、自分だけが持つ「秘密鍵」のペアで成り立ちます。
つまり、公開鍵で暗号化した情報は秘密鍵を持つ本人だけが復号でき、逆に秘密鍵で署名した情報は公開鍵を持つ誰もが正しさを確認できます。
したがって、RSAは「機密性」と「本人性(なりすまし防止)」の両方を実現する基盤として、ウェブやメール、ソフトウェア配布など幅広い場面で使われています。
1-1. RSA(Rivest–Shamir–Adleman)とは? 公開鍵暗号の基礎と歴史
RSAは、1977年にロナルド・リベスト、アディ・シャミア、レナード・アドレマンの3人が発表した公開鍵暗号方式です。
RSAという名称は3人の頭文字に由来します。
なぜRSAが重要かというと、従来の「同じ鍵を共有する」方式では配布の手間や盗聴リスクが大きかったのに対し、RSAは「公開鍵を配って秘密鍵は各自が厳重に保管する」というモデルを可能にしたからです。
その結果、インターネットの急速な普及を安全面から支えました。
1-1-1. RSAの基本概念(公開鍵と秘密鍵)
- 公開鍵(Public Key):誰にでも渡してよい鍵。相手はこの鍵でメッセージを暗号化したり、あなたの署名を検証したりできます。
- 秘密鍵(Private Key):所有者だけが持つ鍵。この鍵で暗号文を復号したり、電子署名を作成したりします。
- つまり、「暗号化→復号」「署名→検証」が、公開鍵と秘密鍵の組み合わせで成立します。だから、鍵共有の負担を最小化できます。
1-1-2. RSAの仕組みのざっくり要点
- 大きな素数を用いて「公開鍵」と「秘密鍵」のペアを作る
- 暗号化・復号や署名・検証は、モジュラー演算(大きな数の割り算の余りを使う計算)で実現
- 安全性は主に「巨大な整数を素因数分解することの難しさ」に依存
- その結果、十分に長い鍵長(例:2048ビット以上)を使う限り、現実的な時間で破られにくいとされています
1-1-3. RSAの歴史と普及の背景
- 1970年代後半:公開鍵暗号の概念が確立し、RSAが広く知られる
- 1990年代:ウェブの商用化とともに、SSL/TLSでRSAが普及
- 現在:TLS、S/MIME、コード署名、VPN、SSH(鍵交換や署名用途)などでRSAが標準的に活躍
1-2. 対称暗号との違い/RSAがもたらすメリット
RSAとよく比較されるのが「対称暗号(共通鍵暗号)」です。対称暗号は同じ鍵で暗号化と復号を行う方式で、処理が非常に高速です。
いっぽう、RSAは公開鍵と秘密鍵が異なるため鍵配布が容易で、なりすまし防止や改ざん検出にも強みがあります。したがって、現場では両者を組み合わせる「ハイブリッド暗号」が主流です。
なぜなら、RSAで安全に「対称鍵」を交換し、その後の大量データは高速な対称暗号で処理する方が合理的だからです。
1-2-1. 対称暗号とRSAの比較表
比較項目 | RSA(公開鍵暗号) | 対称暗号(共通鍵暗号) |
---|---|---|
鍵の種類 | 公開鍵+秘密鍵(異なる鍵) | 共通鍵(同じ鍵) |
鍵配布のしやすさ | 公開鍵を配るだけでよい。配布が容易 | 共通鍵を安全に共有する手段が必要 |
代表的用途 | 鍵交換、電子署名、証明書ベースの認証 | 大量データの暗号化(本番通信) |
処理速度 | 相対的に遅い | 非常に速い |
スケーラビリティ | 大規模環境に向く(公開鍵配布) | 鍵管理が複雑になりやすい |
主な強み | なりすまし防止・改ざん検出(署名) | 高速・低オーバーヘッド |
主な弱み | 計算コストが高い | 鍵の安全な共有が課題 |
1-2-2. RSAの主なメリット(SEOを意識した要点)
- 鍵配布が簡単:RSAは公開鍵を公開できるため、初対面の相手とも安全に通信を開始しやすい
- 本人性の担保:RSA署名により、送信者が本物かどうか検証できる
- 改ざん検出:RSA署名とハッシュの組み合わせで、データ改ざんを見抜ける
- 既存インフラとの親和性:証明書(X.509)やPKIと組み合わせることで、ウェブ全体の信頼基盤を形成
1-2-3. どう使い分けるか(ハイブリッド暗号の実務)
- 最初にRSAで「セッション鍵(対称鍵)」を安全に交換
- その後は対称暗号(AESなど)で本データを高速に暗号化
- 重要なメッセージやソフトウェア配布では、RSA署名で真正性を保証
- つまり、RSAは「入口(鍵交換・署名)」、対称暗号は「本体(大量データ暗号化)」を担当します。その結果、安全性と速度を両立できます。
RSAのしくみ:鍵生成と暗号処理の流れ
RSAは「鍵を作る工程」と「暗号化・復号(および署名・検証)の工程」に分けて理解すると、全体像がすっきり見えます。
つまり、まず安全な公開鍵と秘密鍵を用意し、その後はモジュラー算術にもとづく規則でメッセージを変換します。
したがって、鍵生成の品質と数論の性質を押さえることが、実務で強いRSAを使う近道です。
2-1. 鍵の生成プロセス──大きな素数から公開鍵・秘密鍵へ
2-1-1. 鍵生成の全体像(まずは要点)
- 大きな素数を二つ選ぶ:p と q
- それらを掛けて法 n を作る:n = p × q
- φ(n) を求める:φ(n) = (p − 1)(q − 1)
- 公開指数 e を選ぶ:gcd(e, φ(n)) = 1 を満たす小さめの奇数(一般に 65537)
- 秘密指数 d を計算:e × d ≡ 1 (mod φ(n)) を満たす d
- 公開鍵=(n, e)、秘密鍵=(n, d) を得る(p, q は厳重に秘匿)
この流れがわかれば、RSAの「柱」は押さえられています。なぜなら、暗号化も署名も最終的には n と e・d を使った冪乗の演算だからです。
2-1-2. 用語と記号の整理(RSAで頻出)
記号 | 意味 | 補足 |
---|---|---|
p, q | 異なる大きな素数 | 推測されにくい十分なビット長が必須 |
n | 法(モジュラス):n = p × q | 公開鍵・秘密鍵の両方に含まれる |
φ(n) | オイラーのトーシェント | φ(n) = (p − 1)(q − 1) |
e | 公開指数 | よく使う既定値は 65537 |
d | 秘密指数 | e の逆元(mod φ(n)) |
m | 平文メッセージ | 0 ≤ m < n を満たす整数表現 |
c | 暗号文 | c = m^e mod n |
2-1-3. e の選び方と鍵長の目安
- 公開指数 e は 65537(2^16 + 1)が事実上の標準。計算効率と安全性のバランスが良いからです。
- 鍵長は少なくとも 2048 ビット、長期運用や将来性を見て 3072 ビット以上を検討。つまり、鍵長はRSAの実用的な強度をほぼ決めます。
- 乱数生成器は暗号学的に安全なものを使用。したがって、ここが弱いと p・q が推測されやすくなり、RSA全体が破られます。
2-1-4. ミニ例(教育目的の小さな数)
学習用に小さい数でRSAを体験してみます(実運用では絶対に使わないサイズです)。
- p = 61, q = 53 → n = 61 × 53 = 3233
- φ(n) = (61 − 1)(53 − 1) = 60 × 52 = 3120
- e = 17(gcd(17, 3120) = 1)
- d は 17 × d ≡ 1 (mod 3120) を満たす数 → d = 2753
- m = 65 を暗号化:c = 65^17 mod 3233 = 2790
- 復号:m = 2790^2753 mod 3233 = 65 に戻る
つまり、公開鍵 (n=3233, e=17) で暗号化した結果は、秘密鍵 (n=3233, d=2753) でしか復号できません。
2-1-5. 実務での注意(RSA鍵の品質が命)
- 強力な乱数源と十分な素数テスト(ミラー–ラビンなど)を使う
- p と q が近すぎる、あるいは再利用される事態を避ける
- 秘密鍵はハードウェア(HSM、TPM、スマートカードなど)で保護
- その結果、RSAの根本的な安全性を落とさずに運用できます
2-2. 暗号化・復号の仕組みと数学的背景(モジュラー算術)
2-2-1. 暗号化・復号・署名の式(RSAの基本形)
- 暗号化:c = m^e mod n
- 復号:m = c^d mod n
- 署名:s = H(m)^d mod n(H はハッシュ)
- 検証:s^e mod n が H(m) と一致すれば正当
ここで重要なのは、RSAでは「べき乗して余りを取る」モジュラー算術が核だという点です。したがって、計算は巨大でも規則はシンプルです。
2-2-2. なぜ元に戻るのか(数論の直感)
前提:e × d ≡ 1 (mod φ(n))、つまり e と d は φ(n) 上の逆元
オイラーの定理:gcd(m, n) = 1 のとき m^φ(n) ≡ 1 (mod n)
よって m^(ed) = m^(1 + kφ(n)) ≡ m × (m^φ(n))^k ≡ m (mod n)
実装では中国剰余定理(CRT)を使い、p と q それぞれの法で計算してから結合すると高速化できます。だから実務のRSA復号や署名はCRT最適化が定番です。
2-2-3. パディングの役割(教科書的RSAは使わない)
生の RSA(いわゆる textbook RSA)は安全ではありません。
なぜなら、構造が単純すぎて推測や改ざんの余地があるからです。
- 暗号化では OAEP を使用(ランダム性を導入して安全性を高める)
- 署名では PSS を使用(確率的な署名で改ざん耐性を向上)
- したがって、実務では「RSA+適切なパディング」が必須です。
2-2-4. なぜ大量データに使わないのか(性能とハイブリッド)
RSAは計算が重く、ブロック制限もあります。そこで、実世界では次のハイブリッド構成が主流です。
- RSAでセッション鍵(対称鍵)だけを安全に交換
- その後は高速な対称暗号(例:AES)で大容量データを保護
結果として、RSAの強み(鍵配送と署名)と対称暗号の強み(高速処理)を両立できます。
2-2-5. よくある落とし穴(避けたい実装)
- パディング未使用や旧式パディングのまま
- 鍵長が不足(2048ビット未満)
- 乱数生成が弱い(鍵やOAEPのランダム性が破綻)
- メッセージ長や符号化規則の扱いミス(署名検証の妥当性チェック不足)
- e の選択やCRT最適化実装のバグ(サイドチャネルの温床)
RSAの使われ方と実例
RSAは「鍵の配布」と「署名による真正性の保証」を得意とする暗号方式です。つまり、実社会のプロトコルでは、RSAは大量データの暗号化そのものよりも、鍵交換や電子署名の場面で中心的な役割を果たします。したがって、どの場面でどのようにRSAが働くのかを理解すると、日々の設計やトラブルシュートが一気に楽になります。
3-1. TLS/SSL、HTTPS、SSH、S/MIME、OpenPGP などの通信プロトコルでの役割
3-1-1. TLS/SSL・HTTPSにおけるRSAの現在地
- 役割の要点:サーバ証明書の公開鍵としてRSAが広く利用され、クライアントはそのRSA公開鍵で署名検証を行い、相手が正当なサーバであることを確認します。
- いまの常識:TLS 1.3では鍵交換は主に楕円曲線方式(ECDHE)が担い、RSAによる鍵交換は原則使われません。つまり、RSAは主として署名と証明書の領域に残っています。
- 実務のヒント:証明書の鍵長は2048ビット以上、署名はRSASSA-PSSが推奨される場面が増えています。したがって、更新時はCAの発行ポリシーと合わせて見直しましょう。
3-1-2. SSHにおけるRSA(ログイン認証とホスト認証)
- 役割の要点:クライアントやサーバの認証鍵としてRSAが使われ、サーバはクライアントの署名を検証し、信頼できる相手かを判断します。
- いまの常識:旧式の ssh-rsa(SHA-1)署名は非推奨で、rsa-sha2-256/rsa-sha2-512 に移行するのが基本です。だから、既存環境の鍵と設定を点検することが重要です。
- 実務のヒント:秘密鍵はパスフレーズで保護し、可能ならハードウェアトークンやエージェント転送の制限を活用しましょう。
3-1-3. S/MIME(社内メールの暗号化と署名)
- 役割の要点:受信者のRSA公開鍵でメールの対称鍵を暗号化し、送信者はRSA署名で改ざん防止と本人性を示します。
- 運用のコツ:社内PKIやディレクトリに証明書を配布し、失効管理(CRL/OCSP)を徹底。つまり、鍵と証明書のライフサイクル運用が成否を分けます。
3-1-4. OpenPGP/GnuPG(個人間の暗号化と署名)
- 役割の要点:RSAは暗号化キーや署名キーとして今も定番。公開鍵は相手に渡し、秘密鍵は厳重に保管します。
- 運用のコツ:メイン鍵とサブ鍵を分離し、日常はサブ鍵を使用。つまり、鍵漏えい時の影響を最小化できます。
3-1-5. 主要プロトコルにおけるRSAの使いどころ(要約表)
プロトコル | RSAの主な役割 | 現行ベストプラクティス | 注意点 |
---|---|---|---|
TLS/HTTPS | 証明書の署名検証、サーバ認証 | 署名はPSS、鍵長2048ビット以上 | RSA鍵交換は旧来手法。TLS 1.3はECDHE中心 |
SSH | クライアント/サーバ認証 | rsa-sha2-256/512 を使用 | ssh-rsa(SHA-1)は非推奨 |
S/MIME | メールの鍵配送と署名 | 失効管理と証明書配布を標準化 | ライフサイクル運用を怠ると形骸化 |
OpenPGP | 個人間の暗号化と署名 | サブ鍵運用・定期ローテーション | 鍵配布の信頼モデルを理解する |
3-2. デジタル署名におけるRSAの活用例(認証と改ざん防止)
3-2-1. コード署名とソフトウェア配布
- 背景:ダウンロードした実行ファイルが本物かどうかを、ユーザーは常に気にします。そこでRSA署名です。
- 流れ:開発者がバイナリのハッシュにRSA秘密鍵で署名し、ユーザー側はRSA公開鍵(証明書)で検証。つまり、配布途中で改ざんされていないと確認できます。
- 実務の要点:ハッシュはSHA-256以上、署名形式はPSS推奨、秘密鍵はHSMやセキュアトークンで保護。
3-2-2. 電子文書署名(PDF・契約書・帳票)
- 背景:電子契約や電子請求で「誰がいつ署名したか」を証明する必要があります。
- 流れ:文書ハッシュに対してRSA署名し、検証時に証明書チェーンとタイムスタンプを確認。したがって、長期検証を見据えたアルゴリズム選択が重要です。
- 実務の要点:タイムスタンプを併用し、ハッシュと署名形式を将来も検証可能な組み合わせに。

3-2-3. サーバ・デバイス・APIの認証(機械同士の信頼)
- 背景:マイクロサービスやIoTでは、相手が正当なサービス・デバイスかを自動で判定したい場面が増えています。
- パターン例:相互TLSでサーバ/クライアント双方に証明書を配布し、RSA署名で相互認証。さらに、トークン署名ではRS256(RSA+SHA-256)などが広く使われます。
- 実務の要点:鍵のローテーション、短寿命証明書、失効の自動化。つまり、手運用に頼らない仕組みづくりが鍵です。
3-2-4. 署名の安全性を高めるためのベストプラクティス
- 鍵長:RSAは2048ビット以上を基本、長期運用は3072ビットも選択肢
- 署名方式:RSASSA-PSS を第一候補に(互換要件があればPKCS#1 v1.5も理解して使い分け)
- ハッシュ:SHA-256以上を使用
- 鍵保護:HSMや専用トークンで秘密鍵を扱い、アクセス制御と監査ログを整備
- ライフサイクル:鍵の発行、配布、ローテーション、失効、アーカイブを手順化
- テスト:署名検証の失敗時メッセージや例外処理を明確化。なぜなら、検証失敗はしばしば設定ミスやチェーン不備に起因するからです。
3-2-5. よくある落とし穴(避けたい運用)
- 古い署名方式やSHA-1を惰性で使用
- 鍵の共有や再利用(複数用途で同じRSA鍵を使い回す)
- 失効運用の欠如(証明書を失効しても配布が反映されない)
- 監査・ログ不足によりインシデント時の追跡が困難