ML-DSA と ECDSA の比較は、ポスト量子暗号への移行のうち、署名に関わる半分の話です。P-256 の ECDSA は署名が 64 バイトで、あらゆる場所で使われていますが、ショアのアルゴリズムで破られます。ML-DSA（FIPS 204、2024年8月）は既知の量子攻撃に耐え、高速ですが、鍵と署名のサイズはキロバイト単位です。ブラウザーですでにハイブリッドの ML-KEM がデフォルトになっている鍵交換とは異なり、署名の移行はまだほとんどがこれからです。
比較表
| ECDSA P-256 | ML-DSA-44 | ML-DSA-65 | ML-DSA-87 | |
|---|---|---|---|---|
| 安全性 | 古典的には約 128 ビット、ショアのアルゴリズムで破られる | カテゴリ 2 | カテゴリ 3 | カテゴリ 5 |
| 公開鍵 | 65 バイト（SPKI DER で 91） | 1,312（SPKI DER で 1,334） | 1,952（1,974） | 2,592 |
| 署名 | 生の値で 64 バイト、DER で 70〜72 | 2,420 バイト | 3,309 バイト | 4,627 バイト |
| 自己署名証明書（実測） | 約 388 バイト | 約 3,985 バイト | 約 5,514 バイト | 未計測 |
| 毎秒の署名回数（OpenSSL 3.6.5） | 約 87,000 | 約 3,900 | 約 2,400 | 約 2,050 |
| 毎秒の検証回数 | 約 29,000 | 約 20,800 | 約 13,600 | 約 8,500 |
| 標準 | FIPS 186-5（2023年） | FIPS 204（2024年） | FIPS 204 | FIPS 204 |
| X.509 の識別子 | ecdsa-with-SHA256 | RFC 9881 の OID（…3.4.3.17〜.19） | ||
| NIST IR 8547（ドラフト） | 2035年より後は禁止 | 承認 | 承認 | 承認（CNSA 2.0 が採用） |
速度は Apple M4 Max の 1 コアで openssl speed を使って計測しました。OpenSSL の ML-DSA はポータブルな C 実装で、最適化された実装では署名が数倍高速になります。
移行が必要な理由
ECDSA の安全性は楕円曲線上の離散対数問題に依拠しており、この問題は大規模な誤り耐性量子コンピューター上でショアのアルゴリズムを使えば効率的に解けます。そのような計算機はまだ存在せず、いつ実現するかの見積もりも大きくばらついていますが、署名には緊急度を左右する性質があります。後から署名を偽造できるようになっても、過去の認証が覆るわけではないという点です。2026年に ECDSA で認証された TLS ハンドシェイクが、記録された鍵交換のように後からさかのぼって攻撃されることはありません。早めの対応が必要なのは、署名が長年にわたって信頼できる状態でなければならないものです。具体的には、ルート CA と中間 CA の鍵、ファームウェアとブートチェーン、コード署名のルート、法的文書、長期アーカイブです。
ML-DSA は（CRYSTALS-Dilithium に由来する）格子ベースの署名で、その安全性は Module-LWE と Module-SIS に基づいており、汎用的な手法を超える量子的な高速化は知られていません。NIST IR 8547（初期公開ドラフト）は 2035年より後に ECDSA、EdDSA、RSA を禁止することを提案しています。また NSA の CNSA 2.0 は国家安全保障システムに ML-DSA-87 を義務付けており、ソフトウェアとファームウェアの署名が先行して移行します。
サイズの問題
移行を難しくしているのはサイズです。TLS サーバーは、証明書チェーンとハンドシェイクの署名で自身を認証します。ECDSA では、リーフ証明書と中間証明書の鍵、それらの署名、埋め込まれた 2 つの SCT、CertificateVerify の署名を合わせても数百バイトです。ML-DSA-44 では同じ要素が約 14.7 KB になり（内訳は 1,312 バイトの公開鍵 2 つと 2,420 バイトの署名 5 つで、署名は証明書に 2 つ、SCT に 2 つ、CertificateVerify に 1 つです）、ML-DSA-65 ではさらに大きくなります。その結果、サーバーの最初のフライトが TCP の初期輻輳ウィンドウに収まらなくなってラウンドトリップが増え、QUIC の増幅制限にも達しやすくなります。
#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
for alg in EC ML-DSA-44 ML-DSA-65; do
if [ "$alg" = EC ]; then
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out key.pem 2>/dev/null
label="ECDSA P-256"
else
openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
label="$alg"
fi
openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
printf '%-12s certificate %5s bytes\n' "$label" "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"
ECDSA P-256 certificate 388 bytes
ML-DSA-44 certificate 3985 bytes
ML-DSA-65 certificate 5514 bytes
Web PKI としての解決策は、まだ設計の途中です。Chrome は 2026年2月、Merkle Tree Certificates（IETF の PLANTS ワーキンググループのインターネットドラフト）を採用する計画を発表しました。これは証明書ごとの署名の大部分を短い包含証明に置き換える仕組みです。同時に、現在のルートストアにポスト量子の X.509 証明書を追加する予定はないとしています。CA/Browser Forum は、公的に信頼される TLS 証明書での ML-DSA の使用をまだ承認していません。プライベート PKI では、すでに RFC 9881 に基づいて ML-DSA 証明書を発行でき、OpenSSL 3.5 以降、Bouncy Castle などのライブラリがこれに対応しています。
ハイブリッドと複合署名の選択肢
移行期間中は、新旧どちらのクライアントでも検証できる署名や、どちらか一方のアルゴリズムが破られても安全性を保てる署名が求められることが多くあります。
- 複合署名（draft-ietf-lamps-pq-composite-sigs。まだインターネットドラフトの段階）は、ML-DSA-65 と ECDSA P-256 の組み合わせのような単一のアルゴリズム識別子を定義します。その署名は、両方の部分の検証に成功した場合にだけ有効です。OpenPGP の RFC 9980 も ML-DSA-65+Ed25519 で同じ方式をとっており、OpenSSH 10.4 では実験的な ML-DSA-44+Ed25519 の鍵タイプが追加されました。
- 二重署名は、独立した 2 つの署名を付ける方式です（CMS は複数の
SignerInfo構造に対応しており、一部の文書形式では複数の署名フィールドを持てます）。各検証者は、自分が理解できるほうの署名を検証します。 - 並行 PKI では、従来方式とポスト量子方式の両方の証明書を発行し、クライアントに選ばせます。これは、TLS のネゴシエーションが
signature_algorithmsによってすでにサポートしているモデルです。
どちらを選ぶべきか
- 公開 TLS のサーバー証明書、パスキー、OIDC、外部に公開する JWT：現時点では ECDSA（または Ed25519）を使います。切り替えについては、ブラウザーと IETF の動向を追ってください。
- 長期間運用するサービスやデバイス向けのプライベート PKI：ML-DSA-65 を使います。両方の種類の検証者が存在する場合は、ML-DSA と ECDSA の複合署名を使います。
- ファームウェアとセキュアブート：CNSA 2.0 への準拠が必要かどうかに応じて、ML-DSA-87、またはハッシュベースの LMS、XMSS、SLH-DSA を使います。
- コード署名とパッケージ署名：エコシステム（Sigstore、OS ベンダー）の対応が進むのに合わせて、既存の署名に ML-DSA を追加します。
- ブロックチェーン：どちらを使うかを自分で選ぶことはできません。いくつかのチェーンにはポスト量子署名の提案がありますが、Bitcoin や Ethereum で広く導入されているものはありません。
- 有効期間の短いトークンとセッション：偽造のリスクはその時点でしか生じないため、検証者が移行するまでは ECDSA のままで問題ありません。
移行時の注意点
- すべての署名鍵と検証者を棚卸しします（暗号部品表が役立ちます）。鍵の有効期間と、誰が検証するのかも記録してください。
- サイズの前提をなくす：データベースのカラム、HTTP ヘッダーの上限（ML-DSA-65 の署名は base64 で約 4.4 KB）、スマートカードの容量、QR コード、DNS レコードを見直します。
- アルゴリズムをネゴシエーションできるようにする：データ形式にはアルゴリズム識別子を、検証者には許可リストを持たせ、鍵識別子を使って古い鍵と並行して新しい鍵を導入できるようにします。
- 長期間使うルートから始める：ルートの配布には何年もかかるため、プライベート PKI 向けに ML-DSA または複合署名のルート CA と中間 CA を今のうちに作成します。
- 実際の経路で性能を試験する：大きくなったチェーンでのハンドシェイクのレイテンシー、署名のスループット（ポータブルなコードでは ECDSA よりひと桁遅い）、リソースの限られたデバイスでの検証を確認します。
- FIPS とポリシーの状況を把握しておく：FIPS 204 は最終版ですが、NIST IR 8547 はまだドラフトで、複合署名もまだドラフトの段階です。WebPKI のルールもまだ変わっていません。