本文へスキップ
ecdsa.com

RSA-2048 と RSA-4096 の比較|鍵長、速度、2030年の期限

RSA-4096 は古典的な攻撃に対してより強い一方、署名のコストは 6 倍になります。本当に重要な期限である量子コンピューターに対しては、ほとんど何の効果もありません。
比較対象RSA

RSA-2048 と RSA-4096 のどちらを使うかは、PKI で最もよくある鍵長の疑問です。RSA-2048 は公的に信頼される証明書で認められる最小の鍵長で、NIST の 112 ビットのセキュリティレベルにあたります。RSA-4096 は 128 ビットを大きく上回ります。大きな鍵のコストは、署名にかかる時間、鍵生成にかかる時間、そして通信路を流れるすべての署名に現れます。そのため、正しい答えは、その鍵がどのくらいの頻度で署名するか、どのくらいの期間信頼できる状態を保たなければならないかによって決まります。

比較表

RSA-2048RSA-3072RSA-4096
古典的なセキュリティ(SP 800-57 Part 1)112 ビット128 ビット128 ビット超(該当する行なし、7680 ビット = 192)
NIST IR 8547(ドラフト)2030年より後は非推奨、2035年より後は使用禁止2035年より後は使用禁止2035年より後は使用禁止
署名サイズ256 バイト384 バイト512 バイト
公開鍵(SPKI DER)294 バイト422 バイト550 バイト
毎秒の署名回数(OpenSSL 3.6.5)約 3,000約 1,045約 470
毎秒の検証回数約 114,000約 54,000約 31,500
鍵生成平均約 26 ms約 100 ms約 250〜280 ms、ばらつきが大きい
CA/Browser Forum の最小要件満たす満たす満たす

Apple M4 Max の 1 コアで、openssl speed rsa2048 rsa3072 rsa4096 を使って測定しました。

安全性のマージン

RSA の安全性は、一般数体篩法でモジュラスを素因数分解することの難しさに基づいています。そのコストは鍵長に対して準指数関数的に増加するため、RSA 鍵は楕円曲線の鍵よりもはるかに速いペースで大きくしなければなりません。NIST SP 800-57 Part 1 は、2048 ビットの RSA を 112 ビットセキュリティ、3072 ビットを 128 ビット、7680 ビットを 192 ビットに相当するとしています。4096 ビットの行はなく、その安全性は 128 と 192 の間に位置します。公開の場で素因数分解された最大の RSA チャレンジ数は 829 ビット(RSA-250、2020年)で、2048 ビットにはほど遠い大きさです。

より重要なのは量子コンピューターによる期限です。大規模な誤り耐性量子コンピューターがあれば、ショアのアルゴリズムは 3 つのサイズすべてを多項式時間で素因数分解します。鍵長を 2 倍にすると必要な量子ビットはおよそ 2 倍になり、実行時間もいくらか延びますが、結果は変わりません。Craig Gidney は 2025年に、ノイズのある量子ビットが 1,000,000 個未満でも RSA-2048 を 1 週間未満で素因数分解できると見積もりました。そのため NIST IR 8547(初期公開ドラフト)は、すべての RSA の鍵長に同じ終了時期である 2035年を提案し、RSA-2048 については古典的なセキュリティレベルが 112 ビットであることから、さらに 2030年より後に非推奨とするとしています。RSA-4096 で広がるのは古典的な攻撃に対するマージンであり、ポスト量子への移行期限は延びません。

性能

秘密鍵の演算のコストはモジュラスのサイズのおよそ 3 乗に比例して増え、公開鍵の演算は 2 乗に比例して増えます。

Apple M4 Max の 1 コアでの OpenSSL 3.6.5
openssl speed -seconds 2 rsa2048 rsa3072 rsa4096
出力(抜粋)
                   sign    verify    encrypt   decrypt   sign/s verify/s  encr./s  decr./s
rsa  2048 bits 0.000334s 0.000009s 0.000009s 0.000339s   2994.9 114178.1 108513.6   2950.3
rsa  3072 bits 0.000957s 0.000019s 0.000019s 0.000965s   1044.7  53948.7  52312.0   1036.7
rsa  4096 bits 0.002117s 0.000032s 0.000032s 0.002121s    472.4  31522.3  30870.7    471.6

フルハンドシェイクごとに 1 回署名する TLS サーバーでは、2048 ビットから 4096 ビットに移行すると、そのコストが約 6 倍になります。10 年に数枚の中間証明書に署名するだけのルート CA では、このコストは問題になりません。鍵生成も、2 つの大きな素数を探索するため大幅に遅くなります。このマシンでは 2048 ビットが平均約 26 ms なのに対して 4096 ビットは 4 分の 1 秒かかり、しかもまれに大幅に長くかかることがあります。これは小型のデバイスや、鍵を繰り返し生成するテストで問題になります。

公開指数が小さい(65537)ため、検証はどのサイズでも低コストのままです。これが、何十億回も検証される証明書チェーンで RSA が使われ続けている理由です。

ハードウェアとプロトコルの制約

サイズの制約は、RSA そのものよりも周囲の環境から生じます。

  • スマートカードとトークン:多くの PIV カードや古いセキュリティトークンは RSA-2048 にしか対応していません。新しいデバイスは 3072 と 4096 にも対応しています。ハードウェアを発注する前に確認してください。
  • HSM とクラウド KMS:3 つのサイズはいずれも標準的にサポートされています(AWS KMS には RSA_2048、RSA_3072、RSA_4096 があります)が、操作ごとの料金とスループットの上限があるため、大量に使うと 4096 は目に見えて高くつきます。
  • DNS:4096 ビットの DKIM 鍵は base64 で 736 文字になり、複数の TXT 文字列に分割しなければなりません。一部の DNS プロバイダーや古いリゾルバーは、長いレコードをうまく扱えません。RSA-4096 を使う DNSSEC ゾーンは大きなレスポンスを返すため、TCP が必要になることがあります。
  • 証明書チェーン:RSA-4096 の証明書は 1 枚ごとに約 512 バイトの署名と 550 バイトの鍵を加え、ECDSA の場合の数百バイトと比べて大きくなります。これはリソースの限られたクライアントで問題になります。

どちらを選ぶべきか

  • 新しい TLS サーバー証明書:まず ECDSA P-256 を使います。RSA でなければならない場合、RSA-2048 は今もすべてのクライアントと CA に受け入れられますが、RSA-3072 なら 2030年より後も余裕があります。
  • ルート CA と長期間使う中間 CA:RSA-4096(または ECDSA P-384)を使います。署名のコストは無視でき、有効期間は長くなります。Let's Encrypt の ISRG Root X1 は RSA-4096 で、RSA の中間証明書は RSA-2048 です。
  • JWT の署名(RS256):RSA-2048 が一般的で、使用も認められています(RFC 7518 は 2048 ビット以上を要求しています)。新しい鍵には RSA-3072 を使います。代わりに ES256 も検討してください。
  • SSH 鍵:Ed25519 を優先します。RSA を使う場合は 3072 ビット以上にします。
  • コード署名と文書署名の鍵:CA が提供する鍵長と、署名に想定される有効期間に合わせて RSA-3072 または 4096 を使い、タイムスタンプも付与します。
  • リソースの限られたハードウェア:対応している鍵長(多くの場合は RSA-2048)を使い、置き換えの計画を文書化しておきます。

移行時の注意点

RSA の鍵長を変えるには新しい鍵ペアが必要になり、証明書の場合は新しい証明書も必要になります。

  1. 鍵をサイズ別に棚卸しする:対象は、証明書(openssl x509 -noout -text)、JWKS(n の長さ)、SSH 鍵(ssh-keygen -l)、DKIM レコード、HSM の鍵ハンドルです。有効期間が 2030年より後まで続く RSA-2048 鍵から先にローテーションします。
  2. 新しい鍵は使用する場所で生成する:openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 か、HSM の同等の機能を使います。サイズを変えるために鍵をエクスポートするのは避けてください。
  3. 新旧の鍵の併用期間を設ける:JWKS に両方の鍵を異なる kid の値で公開し、切り替える前に新しい DKIM セレクターを追加し、移行期間中は SSH のホスト鍵を両方とも提示します。
  4. 大きな鍵で利用側をテストする:問題が起きやすいのは、固定サイズのバッファー、DNS レコードの制限、組み込み向けの TLS スタックです。
  5. ローテーションを機にアルゴリズムを見直す:すべての利用側が ECDSA または EdDSA に対応しているなら、RSA から完全に移行するほうが、たいていはよい投資になります。また、ポスト量子署名のために 2035年までにもう一度ローテーションが必要になります。

参考資料

すべての比較