1 RSAの概要
1.1 RSAとは何か
RSA（Rivest–Shamir–Adleman）は、公開鍵暗号方式の代表例であり、通信の機密性確保と、文書やデータの真正性確認（電子署名）を同じ枠組みの数学的操作として扱える点が特徴である。公開情報を利用して暗号文や署名検証に進める一方、復号や署名作成は秘密情報に依存するため、鍵の役割分担が安全性の核になる。
RSAは素因数分解の困難性に基づく。具体的には、ある合成数を成り立たせる素数の組を、公開される合成数から現実的な計算資源で見つけることが難しい、という前提が長年の研究と実務の積み重ねによって支えられてきた。
1.2 仕組みの基本構造
1.2.1 公開鍵と秘密鍵の役割分担
RSAでは、公開鍵は一般に配布され、暗号化（および署名検証）に必要な情報を含む。対して秘密鍵は当事者が厳重に管理し、復号（および署名作成）にのみ用いる。これにより、第三者は公開鍵から暗号化や検証に進めるが、秘密鍵なしには意味のある復号や署名生成ができない設計となる。
公開鍵と秘密鍵は数学的な関係で結ばれているため、秘密情報の保護と、公開情報の正しい利用が同時に成立することで、機密性と真正性の両方を実現できる。
1.2.2 合成数と素因数分解に基づく安全性
RSAの安全性は、大きな合成数 \(N\) を素数 \(p,q\) の積として表したとき、\(N\) の素因数分解が計算上困難であることに依存する。鍵生成段階では生成者が \(p,q\) を知り、そこから秘密鍵に相当する値を計算する。
攻撃者が知っているのは通常 \(N\) と公開指数などの公開鍵成分である。もし因数分解が容易になれば、秘密指数の計算が現実的になり、安全性の前提が崩れる。そのため鍵長の選択と、前提となる計算困難性の維持が運用上の重要課題になる。
1.3 RSAで実現できること
1.3.1 暗号化と復号
RSAによる暗号化は、公開鍵を使って平文を数値として変換し、その後の受信者側で秘密鍵によって元の内容へ戻せるように設計される。数学的には、指数演算と剰余（mod \(N\)）の組で表現されるため、暗号化は公開鍵で実行可能であり、復号は秘密鍵に紐づく逆変換として成立する。
ただし、RSA単体の素朴な変換をそのまま使うと危険になり得る。そこで実務では、平文をそのまま暗号化せず、ランダム性を含む整形（パディング）を施すことが要点となる。
1.3.2 電子署名と検証
RSAの電子署名では、署名者が文書（通常は文書のハッシュ値）に対して秘密鍵を用いた指数演算を行い、署名データを生成する。検証者は公開鍵を使って、署名が対象データに対する正しい変換であるかを判定する。
この仕組みにより、署名の内容が改ざんされていないことの確認や、署名者が秘密鍵を保持していたことへの依拠が可能になる。実務的には、ハッシュ関数、署名フォーマット、検証手順の厳密な実装が結果の信頼性を左右する。
2 数学的基礎
2.1 素数と合成数
2.1.1 素数判定と生成
素数は1と自分自身以外の正の約数を持たない整数である。RSAでは、鍵生成の前段として大きな素数を複数回生成する必要がある。素数判定には、厳密な方法と確率的な方法があり、実装では現実的な計算量で高い確信度を得られる確率的判定（代表例としてミラー・ラブィン型の判定）を組み合わせることが多い。
生成では、ランダムに候補を作り、判定を通過したものを採用する。ここでの重要点は「候補が素数である可能性をどれだけ抑え込むか」であり、十分な検証回数や追加条件が設計に含まれる。
2.1.2 合成数の扱い
合成数は、2つ以上の整数の積として表せる整数である。RSAの公開鍵には合成数 \(N\) が含まれ、これは秘密に保たれる素数 \(p\) と \(q\) の積である。
合成数の扱いでは、以後の計算（剰余演算や指数演算）が常に \(N\) を法として行われる点が中核になる。さらに、鍵生成では \(p\) と \(q\) が同一ではないことや、特殊な関係が生じないような条件設定が行われる。
2.2 合同算術（モジュラ演算）
2.2.1 復号に対応する数学的関係
RSAの鍵ペアは、指数演算を打ち消し合うように設計される。鍵生成では、秘密鍵に対応する指数 \(d\) と公開指数 \(e\) が、ある数学的条件（位数や関数値に関する合同条件）を満たすように選ばれる。
この条件によって、平文を一度公開指数で変換し、それを秘密指数で変換したときに、元の値に戻る関係が成り立つ。厳密な導出にはオイラー関数や合同算術の性質が用いられる。
2.2.2 掛け算・冪乗と剰余
合同算術では、「法 \(N\) による剰余」を基本に考える。RSAの操作は、主に冪乗（指数演算）と剰余の繰り返しとして実行される。直接の冪乗は巨大な中間値を生むため、実装では平方・乗算などの方法で計算を効率化する。
同時に、計算結果が常に剰余範囲に収まることで扱いやすい形式になる。計算が正しく実装されていれば、鍵ペアの数学的関係に沿って復号や検証が成立する。
2.3 オイラーの定理と指数の性質
2.3.1 指数選択の考え方
オイラーの定理は、互いに素な整数に対し、ある指数での冪が法において恒等的な振る舞いを示すことを保証する。RSAではこの考え方を応用して、公開指数と秘密指数の組が「互いに逆関係を持つ」状態になるよう設計する。
具体的には、公開指数 \(e\) が適切に選ばれ、秘密指数 \(d\) がその逆元として合同条件を満たす。逆元の存在には、関連する量（例えばオイラー関数の値）と \(e\) の互いに素であることが必要になる。
2.3.2 鍵生成での整合条件
鍵生成では、\(p\) と \(q\) を用いて \(N\) を作り、さらにそれらから関連する関数値（代表的にはオイラー関数）を求める。その後、公開指数 \(e\) が秘密指数計算のための逆元として整合することを確認する。
整合条件が満たされない場合、復号に必要な逆演算が成立せず、鍵ペアとしての機能を果たさない。したがって生成手順は、単に素数を作るだけでなく、指数や合同関係の成立性まで含めてチェックされる。
3 鍵生成・暗号化・署名の手順
3.1 鍵生成の流れ
3.1.1 素数の選び方
鍵生成の第一段階は、大きな素数 \(p\) と \(q\) を選ぶことである。十分なサイズを確保することで、因数分解の現実的困難性が維持される。さらに、同じ値の重複を避けることや、偏りのある候補を選ばないことが望ましい。
実務では、ランダム性のある生成手順と、素数判定の確率誤差を十分に小さく抑える設計が採用される。加えて、鍵特性によって性能や脆弱性リスクが変わり得るため、素数の条件づけが行われることがある。
3.1.2 公開指数と秘密指数
次に、公開指数 \(e\) を決め、秘密指数 \(d\) を関連する量に関する合同の逆元として算出する。ここでの計算は、逆元計算（拡張ユークリッド互除法など）に基づく。
公開指数は、実装しやすさや演算効率の観点から特定の値が選ばれる傾向がある一方、秘密指数が安全に計算できる整合性が必須である。結果として、公開鍵として配布する値と、秘密鍵として保持する値が数学的に結びつく。
3.1.3 鍵の整合性チェック
生成した鍵は、機能するだけでなく、利用時の安全性を損なわない形で整合している必要がある。したがって、合同条件が満たされていること、公開鍵として提示される情報が一貫していることなどが確認される。
また、実装では並列処理や保存形式の違いにより、誤りが紛れ込む可能性があるため、鍵生成後に簡易なテスト（例として暗号化と復号の整合性）を行う運用も見られる。
3.2 暗号化と復号
3.2.1 平文の扱い（ブロック化）
RSAに入力する値は、法 \(N\) より小さい数値として表される必要がある。そのため、長い平文はそのままでは扱えず、ブロック化や符号化によって数値列に変換される。
さらに、機密性を保つにはランダム性を含む整形が不可欠になる。パディングにより、同じ平文でも異なる暗号文が生成され、単純な照合や構造推測を困難にする。整形方式は運用要件や相互運用性と結びつくため、選択には注意が払われる。
3.2.2 復号の計算手順
受信者は秘密指数 \(d\) を用い、暗号文を法 \(N\) のもとで指数演算して復号値を得る。その後、パディングが施されている場合は整形解除（アンパディング）を行い、平文として取り出す。
復号結果の検査も重要である。整形解除に失敗する場合はエラーとして扱い、曖昧な挙動を避ける。これは安全性だけでなく、実装の頑健性にも関わる。
3.3 電子署名と検証
3.3.1 署名対象（ハッシュ）の位置づけ
署名は通常、元データ全体ではなく、そのハッシュ値に対して行われる。ハッシュにより、入力の長さを一定に揃え、改ざん時に署名検証が失敗する性質を得る。
この構成では、ハッシュ関数の選択と、ハッシュ結果が署名形式に正しく埋め込まれることが重要になる。署名フォーマットの不適切な処理は、検証の意味を変質させる可能性があるため、規格に沿った実装が求められる。
3.3.2 検証の計算手順
検証者は公開指数 \(e\) を用いて署名値を指数演算し、復元された値が期待されるハッシュや形式と一致するかを確認する。一致すれば、当該秘密鍵に基づく正当な署名である可能性が高いと判断される。
ここでも、形式の検査（署名パディング、埋め込み構造）が必須である。計算結果の一致だけに依存すると、意図しない入力に対して誤判定が起こる場合がある。
4 安全性と運用上の注意
4.1 パディングの重要性
4.1.1 PKCS系列とその役割
RSAの暗号化や署名では、入力値の整形としてPKCS系列の仕組みが歴史的に用いられてきた。整形は、平文やハッシュ値に対して所定の構造とランダム性を与え、単純な変換で起こり得る脆弱性を緩和する役割を担う。
特に暗号化では、同一平文の暗号文が一致することを避け、攻撃者による情報推測を難しくする設計が中心となる。署名では、ハッシュ埋め込みの整合性を確認できるようにする点が重視される。
4.1.2 OAEPや運用要件の考え方
OAEP（Optimal Asymmetric Encryption Padding）は、暗号化のためのパディング方式として知られている。OAEPは、乱数を含む構造を用いることで、RSA単体が抱える可能性のある攻撃面を縮小することを目的とする。
運用要件の観点では、相互運用性、既存システムとの互換性、エラー処理方針、鍵更新の頻度といった要素が絡む。パディング方式の選択は暗号強度だけでなく実装の複雑性とも関係するため、仕様書に従った統一運用が望ましい。
4.2 チューニングと鍵長
4.2.1 鍵長がもたらす安全性と性能
鍵長は、法 \(N\) のサイズに相当し、安全性の根拠である因数分解困難性の強さを左右する。一般に鍵が長いほど攻撃に必要な計算量は増えるが、指数演算や復号処理の計算負荷も増える。
性能面では、署名検証や復号の頻度、通信遅延の許容範囲、装置の計算能力などに応じて最適点が異なる。結果として、長すぎる鍵は速度や電力の面で不利になり、短すぎる鍵は安全性の不足につながるため、要件に見合うバランスが求められる。
4.2.2 鍵寿命・更新ポリシー
鍵寿命は、暗号に関する前提（計算能力の向上や攻撃手法の進展）を織り込んだ運用計画である。長期運用では、脆弱性情報の更新や鍵漏えいリスクも考慮し、定期的な更新や失効手続の整備が必要になる。
RSAは実装が成熟している一方、利用環境が変化すると要求される強度も変わる。したがって更新ポリシーは、採用年、鍵長、利用用途（署名か暗号か）、システムの長寿命性などを踏まえて設計される。
4.3 実装の落とし穴
4.3.1 サイドチャネル攻撃への対策
RSAの理論的安全性が成立しても、実装が漏えいを生むと攻撃が成立し得る。代表例として、処理時間、電力消費、キャッシュ挙動などにより秘密鍵に関する情報が推測されるサイドチャネル攻撃が挙げられる。
対策としては、演算の分岐を抑えた定時間実装、乱数化、適切なメモリアクセス制御、保護された乱数生成などが用いられる。さらに、複数回の観測に耐える設計や、テストによる回帰確認も実務では重要になる。
4.3.2 乱数生成の品質
暗号化のパディングや署名周辺の処理では、乱数が安全性に直結することが多い。乱数が偏っていたり予測可能だったりすると、暗号文の再現性が上がり、攻撃の足場になる。
運用では、暗号用途に適した疑似乱数生成器または真性乱数源を選び、適切なシード管理と健全性検査を行うことが求められる。乱数生成器の不具合は広範な影響を与えるため、監視と障害時の挙動設計も欠かせない。
4.4 代表的な用途
4.4.1 TLS等での利用形態
RSAはTLSなどの通信プロトコルで利用されることがある。利用形態としては、鍵交換や署名検証のために組み込まれる形が典型である。
ただし、実務では安全性要求や性能、既存の実装事情により、他の鍵交換方式との併用や切り替えも起こりやすい。したがってRSAの採用は「どの場面で」「どの方式と組み合わせて」成立するかという設計に依存する。
4.4.2 署名証明書とインフラでの使われ方
RSAは公開鍵証明書の発行や署名に関連するインフラで広く用いられてきた。認証局（CA）による証明書の署名や、サーバ・クライアント間での公開鍵の信頼性確立において、電子署名の枠組みが活躍する。
この文脈では、鍵管理、失効、証明書チェーンの検証、アルゴリズム選択の整合性など、運用要素が全体の品質を左右する。署名検証ができても、証明書の配布や更新が不適切であれば信頼性は確保できないため、手続きも含めた設計が重要となる。