--- title: "ECDSAとRSAの違い｜鍵長・安全性・速度を実測で比較し、SSH・TLSでの選び方を解説" url: "https://www.issoh.co.jp/tech/details/4585/" published: 2024-12-20 updated: 2026-10-17 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ECDSAとRSAの違い｜鍵長・安全性・速度を実測で比較し、SSH・TLSでの選び方を解説 ECDSAとRSAは、どちらもSSH・TLS証明書・電子署名で使う公開鍵アルゴリズムです。違いの根は安全性の土台にあります。RSAは巨大な数の素因数分解の難しさ、ECDSAは楕円曲線上の離散対数問題の難しさに依存します。この差から、128bit強度ではRSA 3072bitとECDSA P-256の鍵長に12倍の差が生まれ、署名と検証の速さにも違いが出ます（速度差は曲線・実装・実行環境で変わります）。本記事では鍵長の対応表に加え、OpenSSL 4.0.3で署名・検証の速度と署名サイズを実測した値で両者を比べ、SSH鍵とTLS証明書での選び方、ECDSA特有の秘密鍵漏えいの仕組み、2030年と2035年の移行期限までを扱います。 ## まとめ：ECDSAとRSAの違いと選び方の結論 **新規のSSH鍵はEd25519、TLS証明書はECDSA（P-256）を第一候補とし、RSA（3072bit以上）は互換性や検証性能の要件に応じて選ぶ**が結論です。広く使われているRSA 2048bitの強度は112bitで、NISTの草案では2030年後に非推奨となります。 | 観点 | ECDSA（P-256） | RSA（3072bit） | | --------- | --------------- | --------------- | | 安全性の根拠 | 楕円曲線離散対数問題 | 素因数分解問題 | | セキュリティ強度 | 128bit | 128bit | | 署名生成（実測） | 27,605回/秒 | 348回/秒 | | 署名検証（実測） | 9,854回/秒 | 15,140回/秒 | | 署名サイズ | 最大72byte（DER） | 384byte | | 公開鍵（DER） | 91byte | 422byte | | 暗号化への利用 | 不可（署名専用） | 可 | | 実装・運用上の注意 | nonce再利用で秘密鍵漏えい | 鍵長増大で署名・鍵生成の負荷増 | | 量子耐性 | なし | なし | - **SSH鍵**：新規はEd25519。ECDSAは次点、RSAは古いサーバー向け。 - **TLS証明書**：ECDSAを第一候補にし、古いクライアントが残るならRSA証明書と併用する。 - **乱数生成に不安がある実装**：素のECDSAを避け、決定論的ECDSA（RFC 6979）かEd25519を使う。 ## ECDSAとRSAの鍵長とセキュリティ強度の対応 鍵長は両者で数え方が違うため、ビット数を直接比べても意味がありません。共通の物差しは「セキュリティ強度」で、破るのにおよそ2のn乗回の計算が要ることを n bit と表します。[NIST SP 800-57 Part 1 Rev.5](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf)の表2は、両者を次のように対応づけています。 | セキュリティ強度 | RSA鍵長 | 楕円曲線の鍵長 | 代表的な曲線 | | -------- | -------- | ---------- | ------ | | 112bit | 2048bit | 224〜255bit | P-224 | | 128bit | 3072bit | 256〜383bit | P-256 | | 192bit | 7680bit | 384〜511bit | P-384 | | 256bit | 15360bit | 512bit以上 | P-521 | よく見る「RSA 2048bit＝ECDSA 256bit」は1段ずれています。RSA 2048bitは112bit強度でP-224相当、P-256と同じ128bit強度を出すにはRSA 3072bitが要ります。128bitから192bitへ強度を上げる例では、RSAの鍵長は2.5倍（3072→7680）になるのに対し、楕円曲線は1.5倍（256→384）で済みます。この伸び方の差が、強度を上げるほどECDSAが有利になる理由です。 RSAの安全性は、2つの大きな素数の積から元の素数を求める計算（一般数体ふるい法が最速）の難しさに依存します。楕円曲線では、基点Gをk回足した点P＝kGから回数kを逆算する計算が難しく、知られている最良の攻撃でも鍵長の半分のビット数に相当する計算量がかかります。256bitの曲線が128bit強度になるのはこのためです。RSA単体の鍵生成やパディング（PKCS#1 v1.5とPSS）の選び方は[RSA暗号とは？仕組みと鍵長・パディングの選び方をOpenSSLの実装で解説](/tech/details/17520/)で扱っています。 ## 署名生成と検証の速度をOpenSSL 4.0.3で実測 「ECDSAは速い」「RSAは遅い」という説明は半分だけ正しく、署名を作る側と確かめる側で優劣が入れ替わります。次のコマンドで、同じマシン（Intel Core i9-9880H・macOS・OpenSSL 4.0.3）の1スレッドで3秒ずつ計測しました。 ``` openssl speed -seconds 3 rsa2048 rsa3072 ecdsap256 ecdsap384 ed25519 ``` | アルゴリズム | 強度 | 署名生成（回/秒） | 署名検証（回/秒） | | ----------- | ------ | --------- | --------- | | RSA 2048bit | 112bit | 980 | 34,604 | | RSA 3072bit | 128bit | 348 | 15,140 | | ECDSA P-256 | 128bit | 27,605 | 9,854 | | ECDSA P-384 | 192bit | 2,370 | 1,086 | | Ed25519 | 128bit | 14,214 | 5,232 | 同じ128bit強度で比べると、**署名生成はP-256がRSA 3072bitの約79倍速く、検証はRSA 3072bitがP-256の約1.5倍速い**結果でした。同じマシンで約2時間後にもう1度測ると、P-256の署名は22,516回/秒、検証は8,516回/秒、RSA 3072bitの署名は331回/秒、検証は15,280回/秒で、倍率は約68倍と約1.8倍でした。今回の2回の計測ではP-256の署名速度に約18％の差がありましたが、署名生成と検証それぞれの速度の優劣は逆転しませんでした。RSAの検証が速いのは、公開指数に小さな値（65537）を使い、検証のべき乗計算が軽く済むためです。鍵の生成も差が大きく、RSA 3072bitは1本あたり約0.26秒かかりました。 この非対称性は用途で効き方が変わります。証明書認証を行うTLSハンドシェイクではサーバーが署名するため、ECDSAは署名処理のCPU負荷を抑えられます。ただし、PSKによるセッション再開では通常この署名処理を省略します。逆に、1度署名したファイルを多数の端末が検証し続ける配布物の署名では、検証の速いRSAが不利になりません。なおP-384はP-256の約12分の1の署名速度で、192bit強度が求められない限り、P-256を選ぶほうが性能面で得です。数値はCPUとOpenSSLのビルドで変わるため、選定時は自分の環境で同じコマンドを流して確かめてください。 ## 鍵・署名サイズの比較とECDSAのDER符号化による長さの変動 証明書チェーンや署名付きトークンを大量に送る用途では、速度よりサイズが効きます。OpenSSL 4.0.3で鍵と署名を作り、公開鍵はSubjectPublicKeyInfo形式をDER符号化したサイズ、署名は署名値単体のサイズを数えました。P-256の公開鍵には非圧縮点形式を使っています（SSH公開鍵はOpenSSH 10.3で空コメントにして作り、末尾の空白と改行を除いた文字数）。参考として、耐量子署名のML-DSA-65も並べます。 | アルゴリズム | 公開鍵（DER） | 署名 | SSH公開鍵の行（文字数） | | ----------- | --------- | ------------- | ------------- | | RSA 2048bit | 294byte | 256byte | － | | RSA 3072bit | 422byte | 384byte | 552文字 | | ECDSA P-256 | 91byte | 69〜72byte（実測） | 160文字 | | Ed25519 | 44byte | 64byte | 80文字 | | ML-DSA-65 | 1,974byte | 3,309byte | － | RSAの署名は鍵長と同じ長さになります（[RFC 8017](https://www.rfc-editor.org/rfc/rfc8017.html)は署名長を法nのオクテット長kと定めています）。ECDSAの署名は2つの整数 r と s の組で、X.509証明書やOpenSSLでは各整数をDER符号化するため長さが揺れます。同じ鍵でP-256署名を2,000回作ると、71バイトが1,012回、70バイトが497回、72バイトが489回、69バイトが2回でした。正整数を最短の符号付き整数として表すため、不要な先頭の0x00を除き、最上位ビットが1なら符号用の0x00を残すか追加します。P-256のDER署名は最大72バイトですが、69バイト未満にもなり得るため、表の69〜72バイトは規格上の下限・上限ではありません。 一方、JWTのES256は r と s を32バイトずつ連結した固定64バイトで表します（[RFC 7518 3.4節](https://www.rfc-editor.org/rfc/rfc7518.html#section-3.4)）。OpenSSLが返すDER署名をそのままJWTに入れると検証で落ちるため、64バイトへ変換する処理が要ります。JWTの署名検証の流れは[JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説](/tech/details/13453/)で解説しています。 ## ECDSAとは：楕円曲線で署名する仕組みと曲線の名前 ECDSA（Elliptic Curve Digital Signature Algorithm）は、楕円曲線暗号を土台にした署名専用のアルゴリズムです。現行の規格は[FIPS 186-5](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf)（2023年2月）です。RSAが暗号化と署名の両方に使えるのに対し、ECDSAは署名にしか使えず、楕円曲線で鍵を共有したいときはECDH、暗号化したいときはECIESなど別の方式を組み合わせます。 「ECDSAにはNSAのバックドアが仕込まれている」という説明を見かけますが、これは別の規格の話です。2014年4月に[NISTが推奨から外した](https://www.nist.gov/news-events/news/2014/04/nist-removes-cryptography-algorithm-random-number-generator-recommendations)のは乱数生成器のDual\_EC\_DRBGで、署名方式のECDSAではありません。ECDSAはFIPS 186-5でも承認方式のままで、国内の[CRYPTREC暗号リスト](https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2022r2.pdf)（2026年3月30日最終更新）でも、電子政府推奨暗号リストの署名にEdDSA・RSA-PSSと並んで載っています。 ### 署名（r, s）の作り方と検証の流れ 秘密鍵はランダムな整数d、公開鍵は基点Gをd回足した点Q＝dGです。署名ごとにnonceと呼ぶ整数kを用意し（乱数で選ぶか、後述のRFC 6979の方式で決定論的に導く）、点kGのx座標から r を、メッセージのハッシュ値と d・k から s を計算します。検証はFIPS 186-5の6.4.2節の手順で行い、rとsが1〜n－1の範囲にあるかを確認してから、公開鍵Qと署名・ハッシュ値から点を計算します。その点が無限遠点でなく、x座標を整数に変換して基点の位数nで割った余りがrと一致すれば署名を受理します。異なるハッシュ値への署名で同じkを再利用すると、後述する秘密鍵漏えいにつながります。決定論的ECDSAでは、同じ秘密鍵と同じメッセージから同じkが生成されます。 ### P-256・P-384・P-521とsecp256k1の呼び名の対応 同じ曲線が規格や製品ごとに別の名前で呼ばれるため、設定ファイルやエラーメッセージで混乱しがちです。名前は次のように対応します。 | NIST名 | SECG名 | OpenSSL名 | SSHの鍵型 | JWT | | ----- | --------- | ---------- | ------------------- | ------ | | P-256 | secp256r1 | prime256v1 | ecdsa-sha2-nistp256 | ES256 | | P-384 | secp384r1 | secp384r1 | ecdsa-sha2-nistp384 | ES384 | | P-521 | secp521r1 | secp521r1 | ecdsa-sha2-nistp521 | ES512 | | － | secp256k1 | secp256k1 | － | ES256K | 証明書の署名アルゴリズム欄に出る「ecdsa-with-SHA256」は、発行者がECDSAとSHA-256で証明書に署名したことを表します。この欄だけでは、証明書の主体の公開鍵方式や曲線は分かりません。それらはSubjectPublicKeyInfoで確認します。secp256k1はビットコインやイーサリアムが採用する曲線です。公開信頼されたTLS証明書ではCAの発行基準の対象外で、OpenSSHのECDSA鍵でも選択できません。 ## RSAとは：暗号化にも署名にも使える最古参の方式 RSAは1977年に発表された公開鍵暗号で、2つの大きな素数の積を公開鍵の材料にします。**署名だけでなくデータの暗号化にも使える**のがECDSAとの機能面の違いで、S/MIMEやPGPのメール暗号、古いTLSの鍵交換まで幅広く使われてきました。実装が長く枯れており、組み込み機器や古いクライアントでもまず対応している互換性が最大の強みです。 ただしTLS 1.3ではRSAで鍵を運ぶ方式が廃止され、[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446.html#section-1.2)は「Static RSA and Diffie-Hellman cipher suites have been removed」と明記しています。TLS 1.3でのRSA証明書は、ハンドシェイクの署名にだけ使われます。RSAの弱点は、強度を上げる方法が鍵長を伸ばすことしかなく、前章の実測どおり署名と鍵生成が急に遅くなる点です。 ## ECDSAとEdDSA（Ed25519）の違い EdDSAはECDSAと同じく楕円曲線を使う署名方式で、Ed25519はその代表です。[RFC 8032](https://www.rfc-editor.org/rfc/rfc8032.html)で規定され、FIPS 186-5で米国政府の承認方式にも加わりました。ECDSAとの違いを、nonce・署名サイズ・公開TLS証明書・SSHの4項目で比較します。 | 観点 | ECDSA（P-256） | Ed25519 | | ------------------ | ------------- | ------------- | | nonceの作り方 | 乱数（決定論的方式も可） | 常に決定論的 | | 署名サイズ | 最大72byte（DER） | 64byte固定 | | 公開TLS証明書 | 発行できる | 発行できない | | SSH（OpenSSH 9.5以降） | 選択可 | ssh-keygenの既定 | 最大の違いはnonceです。Ed25519は秘密鍵とメッセージからnonceを導くため、署名時の乱数不良によるnonce再利用を避けられます。ただし、秘密鍵の生成には安全な乱数が必要です。一方、Ed25519はCAが発行する公開信頼されたTLSサーバー証明書の鍵には、現行のBaseline Requirementsでは使えません。認証局の業界基準である[CA/Browser Forum Baseline Requirements（v2.3.1）](https://github.com/cabforum/servercert/blob/main/docs/BR.md)の6.1.5節は、RSA（2048bit以上）とECDSA（P-256・P-384・P-521）以外を「No other algorithms or key sizes are permitted.」と定めています。なお今回の実測では、署名速度はP-256のほうがEd25519の約2倍速く、速さはEd25519を選ぶ理由になりませんでした。 ## SSH鍵の選び方：Ed25519・ECDSA・RSAとOpenSSH 10系の変化 SSH鍵では、**新規作成はEd25519、相手がEd25519に対応しないときにECDSA、さらに古い相手にはRSA 3072bit以上**の順で選びます。OpenSSH 9.5（2023年10月4日）で、[ssh-keygenの既定がEd25519](https://www.openssh.org/txt/release-9.5)になりました。鍵型を指定するコマンドは次のとおりです。 ``` ssh-keygen -t ed25519 ssh-keygen -t ecdsa -b 256 ssh-keygen -t rsa -b 3072 ``` ECDSAで指定できる鍵長は256・384・521だけで、OpenSSH 10.3で `-b 255` を渡すと「Invalid ECDSA key length: valid lengths are 256, 384 or 521 bits」で止まりました。旧来のDSAはOpenSSH 10.0（2025年4月9日）で[対応自体が削除](https://www.openssh.org/txt/release-10.0)され、`ssh-keygen -t dsa` は「unknown key type dsa」になります。古い機器のDSA鍵で接続している場合は、クライアントを更新した時点で入れなくなります。 RSA鍵の扱いで誤解が多いのは、OpenSSH 8.8（2021年9月26日）の変更です。このとき[既定で無効になった](https://www.openssh.org/txt/release-8.8)のはSHA-1を使う署名方式「ssh-rsa」で、RSA鍵そのものではありません。既存のRSA鍵はrsa-sha2-256・rsa-sha2-512の署名で使い続けられます。古いサーバーへの接続が8.8以降で失敗する場合は、鍵の作り直しよりサーバー側の更新を先に検討してください。 大手のサービスはホスト鍵を複数の鍵型で併記しています。2026年10月17日に `ssh-keyscan github.com gitlab.com` で確かめると、どちらもssh-rsa・ecdsa-sha2-nistp256・ssh-ed25519の3種類のホスト鍵を提示していました。併記しておけば、3種類のうち1つにしか対応しないクライアントとも鍵型を合わせられます。自社のサーバーでRSAのホスト鍵を消すと、RSAにしか対応しない古いクライアントは接続できなくなります。 量子コンピュータへの備えも始まっています。OpenSSH 10.4（2026年7月6日）はML-DSA-44とEd25519を組み合わせた署名を実験的に追加し、[10.6（2026年10月6日）](https://www.openssh.org/txt/release-10.6)で「ssh-mldsa44-ed25519」として有効にしました。10.4の実験版で作った鍵は作り直しが要ります。鍵交換のほうは10.0から耐量子のmlkem768x25519-sha256が既定です。公開鍵認証の設定手順は[SSH接続とは？仕組み・公開鍵認証・ポート22から安全な運用設定まで実装者向けに解説](/tech/details/13544/)、OpenSSHの版の確認と更新は[OpenSSHとは？最新バージョン10.6の確認方法とアップデート手順【2026年10月】](/tech/details/10191/)を参照してください。 ## TLS証明書の選び方：ECDSA証明書とRSA証明書の併用 Webサーバーの証明書は**ECDSA（P-256）が第一候補**です。Let’s EncryptのクライアントCertbotは、[2.0.0から新規証明書の既定をECDSAのP-256](https://eff-certbot.readthedocs.io/en/stable/using.html#rsa-and-ecdsa-keys)にしています。既存証明書の更新では元の鍵種別が引き継がれるため、RSAのまま運用している証明書は明示的に切り替えない限りECDSAになりません。 ECDSAに対応しない古いクライアントが残る場合は、RSA証明書とECDSA証明書を両方配る構成にします。nginxは1.11.0から `ssl_certificate` を[種類の違う証明書の数だけ書ける](https://nginx.org/en/docs/http/ngx%5Fhttp%5Fssl%5Fmodule.html#ssl%5Fcertificate)ため、クライアントが対応する側を自動で選ばせられます。 ``` certbot certonly --nginx --key-type ecdsa --cert-name example.com-ecdsa -d example.com certbot certonly --nginx --key-type rsa --rsa-key-size 3072 --cert-name example.com-rsa -d example.com ``` ``` server { listen 443 ssl; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com-ecdsa/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com-ecdsa/privkey.pem; ssl_certificate /etc/letsencrypt/live/example.com-rsa/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com-rsa/privkey.pem; } ``` 大手サイトもこの併用で互換性を確保しています。2026年10月17日に `openssl s_client` で証明書を取得すると、Google・GitHub・Cloudflare・楽天は通常の接続にはECDSA P-256の証明書を返し、RSA系の署名アルゴリズムだけを提示する接続にはRSA証明書を返しました。一方、Yahoo! JAPAN・Amazon.co.jp・デジタル庁・国税庁はどちらの接続にもRSA 2048bitの証明書を返しました。 | サイト | 通常の接続 | RSAだけを提示した接続 | | ------------------ | ----------- | ------------ | | www.google.com | ECDSA P-256 | RSA 2048bit | | www.cloudflare.com | ECDSA P-256 | RSA 2048bit | | github.com | ECDSA P-256 | RSA 4096bit | | www.rakuten.co.jp | ECDSA P-256 | RSA 2048bit | | www.yahoo.co.jp | RSA 2048bit | RSA 2048bit | | www.amazon.co.jp | RSA 2048bit | RSA 2048bit | | www.digital.go.jp | RSA 2048bit | RSA 2048bit | 自社サイトや取引先が何を配っているかは、次の2行で確かめられます。1行目が通常の接続、2行目がRSAにしか対応しない古いクライアントを模した接続です。1行目がECDSAで2行目がRSAなら、両方の証明書を提示できることを確認できます。ただし、2行目の失敗だけではRSA証明書の有無は判断できません。TLS 1.2の無効化や、提示した署名方式・暗号スイートとの不一致でも失敗します。 ``` openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep -m1 "a:PKEY" openssl s_client -connect example.com:443 -servername example.com -tls1_2 -sigalgs "RSA-PSS+SHA256:RSA+SHA256" < /dev/null 2>/dev/null | grep -m1 "a:PKEY" ``` OpenSSL 4.0.3では、出力の「a:PKEY: EC, (prime256v1)」がECDSA P-256、「a:PKEY: RSA, 2048 (bit)」がRSA 2048bitを表します。 公開TLS証明書とは別に、国内の電子署名法に基づく認定認証業務では、GPKIブリッジ認証局との相互認証に関するECDSA対応が予定されています。デジタル庁・法務省の2024年6月11日の[事務連絡](https://digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/614eb74c-d84f-4945-8293-8f36d3a2d4c7/4cf07134/20240611%5Fdigitalsign%5Flaw%5F01.pdf)によると、政府認証基盤（GPKI）のブリッジ認証局はECDSAWithSHA384（P-384）に対応する予定で、相互認証する認定認証業務には2028年中をめどに新暗号での運用開始を求めています。TLSのバージョンや暗号スイートの選び方は[TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説【2026年最新】](/tech/details/13318/)、クライアント証明書での相互認証は[mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断を実装目線で解説](/tech/details/14378/)で扱っています。 ## ECDSAの落とし穴：nonceの再利用で秘密鍵が漏れる仕組み ECDSAには、RSAに無い危険があります。**同じ秘密鍵で、署名計算に使うハッシュ値が異なる2つのメッセージに同じnonce（k）を使うと、署名とメッセージから秘密鍵を計算できてしまいます**。2010年12月の講演「[Console Hacking 2010](https://fahrplan.events.ccc.de/congress/2010/Fahrplan/attachments/1780%5F27c3%5Fconsole%5Fhacking%5F2010.pdf)」（27C3）では、PlayStation 3の署名に使われていた秘密鍵を、nonceの使い回しから算出したことが示され、スライドには「from a pair of signatures that use the same m, we can compute m and k」とあります（スライドではnonceをm、秘密鍵をkと表記）。2013年8月には、Androidの乱数生成部品の欠陥で、Android上で作ったビットコインのウォレットが盗難の危険にさらされると[bitcoin.org](https://bitcoin.org/en/alert/2013-08-11-android)が告知しました。 仕組みは連立方程式です。次のPythonコードはP-256で同じkを使って2回署名し、公開されている値だけから秘密鍵を復元します。外部ライブラリは不要で、Python 3.8以降で動きます（3.9.6で実行し、2行とも True になることを確認済み）。 ``` import hashlib, secrets # P-256 の曲線パラメータ p = 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff a = p - 3 n = 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551 G = (0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296, 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5) def add(P, Q): if P is None: return Q if Q is None: return P if P[0] == Q[0] and (P[1] + Q[1]) % p == 0: return None if P == Q: l = (3 * P[0] * P[0] + a) * pow(2 * P[1], -1, p) % p else: l = (Q[1] - P[1]) * pow(Q[0] - P[0], -1, p) % p x = (l * l - P[0] - Q[0]) % p return (x, (l * (P[0] - x) - P[1]) % p) def mul(k, P): R = None while k: if k & 1: R = add(R, P) P = add(P, P); k >>= 1 return R def h(m): return int.from_bytes(hashlib.sha256(m).digest(), "big") def sign(d, m, k): r = mul(k, G)[0] % n s = pow(k, -1, n) * (h(m) + r * d) % n return r, s d = secrets.randbelow(n - 1) + 1 # 秘密鍵 k = secrets.randbelow(n - 1) + 1 # 本来は署名ごとに変える値 m1, m2 = b"transfer 100", b"transfer 999" r1, s1 = sign(d, m1, k) r2, s2 = sign(d, m2, k) # 攻撃者が知っているのは m1, m2 と2つの署名だけ k_rec = (h(m1) - h(m2)) * pow(s1 - s2, -1, n) % n d_rec = (s1 * k_rec - h(m1)) * pow(r1, -1, n) % n print("r1 == r2:", r1 == r2) print("秘密鍵を復元できたか:", d_rec == d) ``` 同じkなら r が一致するため、攻撃者は「同じ r を持つ2つの署名」を探すだけで再利用に気づけます。kが完全に同じでなくても安全とは限りません。スマートカードや暗号ライブラリのECDSA実装で、処理時間からnonceの情報が漏れ、多数の署名から長期の秘密鍵を復元できることが[Minerva](https://minerva.crocs.fi.muni.cz/)の研究で示されています。 対策は2つです。[RFC 6979](https://www.rfc-editor.org/rfc/rfc6979)（2013年8月）はkを秘密鍵とメッセージのハッシュから決定論的に作る方式を定め、FIPS 186-5も決定論的ECDSAを承認しています。もう1つはnonceが常に決定論的なEd25519への切り替えです。ただし、これらはnonceの再利用や乱数の偏りへの対策であり、直前に挙げたMinerva型のサイドチャネル攻撃を防ぐものではありません。処理時間などから秘密情報が漏れない実装上の対策も必要です。**自前でECDSAの署名処理を書く、乱数源の品質を保証できない組み込み機器で署名する、といった場面では素のECDSAを選ばないでください**。OpenSSLやクラウドのKMSなど実績のあるライブラリに署名を任せるのが前提で、上のコードは仕組みの確認用です。 決定論的ECDSAは[OpenSSL 3.2.0](https://github.com/openssl/openssl/blob/master/CHANGES.md)から使えます。同じ鍵と同じメッセージで2回ずつ署名すると、既定の動作では毎回違う署名になり、`-sigopt nonce-type:1` を付けると同じ署名になります。RSA（PKCS#1 v1.5）とEd25519も、同じ入力からは同じ署名を出します。 ``` openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out p256.key echo hello > m.txt # 既定（乱数のk）：2回の結果が異なる openssl dgst -sha256 -sign p256.key m.txt | shasum openssl dgst -sha256 -sign p256.key m.txt | shasum # RFC 6979（決定論的なk）：2回とも同じ openssl dgst -sha256 -sign p256.key -sigopt nonce-type:1 m.txt | shasum openssl dgst -sha256 -sign p256.key -sigopt nonce-type:1 m.txt | shasum ``` OpenSSL 4.0.3で実行すると、前の2行は別のハッシュ値、後の2行は同じハッシュ値になり、決定論的に作った署名も通常の `openssl dgst -verify` で検証できました。検証側は署名の作り方を区別しないため、署名側だけ切り替えられます。 ## RSA 2048とECDSAの移行期限：2030年・2035年と量子コンピュータ RSAもECDSAも、大規模な量子コンピュータが実現するとShorのアルゴリズムで解かれます。鍵長を伸ばしても防げないため、「量子に強いのはどちらか」という比較は成り立ちません。そのうえで、各機関は次の移行目安を示しています。NISTの草案、電子政府向けのCRYPTREC基準、電子署名法の認定基準では適用対象が異なり、一般のSSH・TLS運用すべてに一律の法的期限を課すものではありません。 | 文書 | 対象 | 期限 | 状態 | | --------------------- | ----------------- | ------------- | --------- | | NIST IR 8547 | 112bit（RSA 2048等） | 2030年後に非推奨 | 草案 | | NIST IR 8547 | RSA・ECDSAすべて | 2035年後に不許可 | 草案 | | CRYPTREC LS-0003-2022 | 112bitの新規署名 | 2030年まで条件付き許容 | 2022年7月公表 | | 電子署名法の認定基準 | 112bit→128bit以上 | 2033年末めど | 改正予定 | [NIST IR 8547](https://csrc.nist.gov/pubs/ir/8547/ipd)は2024年11月12日公開の初期公開草案のままで、2026年10月17日時点で最終版は出ていません。表2は112bit強度のRSA・ECDSAを「Deprecated after 2030」、128bit以上を含む全強度を「Disallowed after 2035」としています。国内では[CRYPTRECの設定基準](https://www.cryptrec.go.jp/list/cryptrec-ls-0003-2022.pdf)が、新たな署名には原則として2040年まで128bit以上を選ぶよう求め、112bitは短時間で完結する認証や既存システムとの互換性維持などに限り2030年まで許容しています。電子署名法の認定認証業務は、前章の事務連絡で2033年末をめどに128bit以上へ基準を改める予定です。 実務の判断は、**いまRSA 2048bitで運用しているなら、次の更新でP-256かRSA 3072bitへ上げる**ことです。署名が有効であり続ける期間で考えるのがポイントで、CRYPTRECの基準も「全ての署名検証が必要なくなる年」で判断するよう求めています。2028年に有効期間5年の証明書を発行するなら、2033年まで検証されます。 移行先の耐量子署名は、2024年8月13日にML-DSA（[FIPS 204](https://csrc.nist.gov/pubs/fips/204/final)）とSLH-DSA（FIPS 205）が標準化されました。前述の実測どおりML-DSA-65の署名は3,309バイトとP-256署名（69〜72バイト）の46〜48倍あり、OpenSSL 4.0.3で同じ主体名（CN=example.com）の自己署名証明書を作ると、DER形式でML-DSAのうち最も小さいML-DSA-44でも3,952バイトと、P-256（356バイト）の約11倍になりました（証明書全体のサイズは主体名や拡張の設定でも変わります）。このため、移行前に通信量や保存容量への影響を評価する必要があります。ハイブリッド署名は従来署名も追加するため、サイズ増大の解決策にはなりません。ハイブリッドは、新しい方式に未知の弱点が見つかっても従来方式で守れるようにする移行期の構成で、OpenSSH 10.6のssh-mldsa44-ed25519もこの形です。署名で恐れるべきは、量子計算機が実用化した後の偽造です。暗号化通信で言われる「今のうちに集めて後で解読する」攻撃は、主に鍵交換の問題です。量子コンピュータの方式と実用化の見通しは[量子コンピュータとは？仕組み・方式・実用化の現在地を実装目線で解説する技術ガイド](/tech/details/13586/)にまとめています。 ## よくある質問 ### ECDSAとRSAはどちらが安全ですか？ 同じセキュリティ強度なら、アルゴリズムとしての安全性は同等です。128bit強度ならECDSAはP-256、RSAは3072bitです。ただしECDSAはnonceの扱いを誤ると秘密鍵が漏れるため、実運用での安全性は実装の品質に左右されます。 ### ECDSA P-256はRSAの何ビット相当ですか？ NIST SP 800-57の対応ではRSA 3072bit相当（128bit強度）です。RSA 2048bitは1段低い112bit強度で、楕円曲線ではP-224に相当します。 ### ecdsa-sha2-nistp256とは何ですか？ SSHでのECDSA鍵の型名で、NIST P-256曲線とSHA-256ハッシュを使うことを表します。`ssh-keygen -t ecdsa -b 256` で作った鍵の公開鍵ファイルは、この文字列で始まります。 ### RSA 2048bitの鍵はいつまで使えますか？ NIST IR 8547の草案では2030年後に非推奨、2035年後に不許可です。CRYPTRECの設定基準も、新たな署名の生成で112bit強度を許容するのは2030年までの移行期間に限っています。有効期間が2030年をまたぐ証明書や鍵は、3072bit以上かP-256で作り直すのが安全です。 ### ECDSAの鍵でデータを暗号化できますか？ ECDSA自体は署名専用で、暗号化の手順を持ちません。楕円曲線の鍵で暗号化したい場合は、ECDHで共通鍵を共有してAESなどで暗号化するか、それを組み合わせたECIESを使います。RSAは1つのアルゴリズムで暗号化と署名の両方を扱えます。 ## 関連記事 - [RSA暗号とは？仕組みと鍵長・パディングの選び方をOpenSSLの実装で解説](/tech/details/17520/) - [SSH接続とは？仕組み・公開鍵認証・ポート22から安全な運用設定まで実装者向けに解説](/tech/details/13544/) - [TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説【2026年最新】](/tech/details/13318/) - [JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説](/tech/details/13453/) - [公開鍵暗号方式と共通鍵暗号方式の違いとは？仕組み・アルゴリズム・使い分けを解説](/column/details/13485/) --- 出典: [ECDSAとRSAの違い｜鍵長・安全性・速度を実測で比較し、SSH・TLSでの選び方を解説]()（株式会社一創）