Ed25519 と Ed448 の比較｜128 ビットと 224 ビットの EdDSA

Ed25519 と Ed448 のどちらを選ぶかは、マージンの問題です。どちらも RFC 8032 の同じアルゴリズムファミリーに属し、どちらも FIPS 186-5 で承認されており、どちらも署名ごとの乱数を使わずに決定的に署名します。Ed448 はより大きな曲線を使うことで、約 128 ビットではなく約 224 ビットの古典的セキュリティを実現し、その代償をサイズ、速度、エコシステムのサポートで支払います。

比較表

速度は、Apple M4 Max の 1 コアで openssl speed を使って測定しました。

セキュリティマージン

どちらも、完全な加算公式、決定的な nonce、厳格なエンコーディングを備えたエドワーズ曲線上の EdDSA なので、実装ミスに対して同じ堅牢性を持ちます。違いは群の大きさです。Ed25519 の群は約 2²⁵² 個の元からなり、ポラードのロー法に対して約 128 ビットのセキュリティを提供します。これは P-256、AES-128、SHA-256 の衝突と同じセキュリティレベルです。Ed448 の群は約 2⁴⁴⁶ 個の元からなり、約 224 ビットを提供します。これは P-384（192）より高く、P-521 に近い水準です。

古典的な攻撃者にとって 128 ビットははるかに手の届かない水準なので、追加のマージンは総当たり攻撃ではなく、楕円曲線暗号の解読手法が予想外に進歩した場合への備えになります。大規模な量子コンピューターに対しては、どちらの曲線もショアのアルゴリズムで破られ、大きいほうの曲線でも追加のコストはわずかです。そのため、NIST のポスト量子移行計画では両者を同じように扱っています。

設計上の違い

Ed448 は Ed25519 を単に大きくしたものではありません。ハッシュには SHA-512 ではなく SHAKE256 を使うため、依存関係ツリーに別のハッシュ関数が加わります。また、常に最大 255 バイトのコンテキストを含むドメイン文字列を先頭に付加します。Ed25519 の純粋な形式にはコンテキストがありません。Ed25519ctx も存在しますが、実装されることはまれです。1 つの鍵の異なる用途の間でドメイン分離が必要なプロトコルでは、Ed448 なら追加の手間なしにそれが得られますが、Ed25519 では分離のための情報を署名対象のメッセージに含める必要があります。

どちらにも事前ハッシュ版の Ed25519ph と Ed448ph（FIPS 186-5 §7.8 の HashEdDSA）がありますが、これらは署名に互換性のない別のアルゴリズムです。一度に渡せないデータに署名しなければならない場合を除き、純粋版を使ってください。

次のスクリプトを Node.js 26.10（OpenSSL 3.6.5）で実行すると、サイズの違いがわかります。

import { generateKeyPairSync, sign, verify } from "node:crypto";

const message = Buffer.from("release-2026.10.tar.gz digest");

for (const type of ["ed25519", "ed448"]) {
  const { privateKey, publicKey } = generateKeyPairSync(type);
  const signature = sign(null, message, privateKey);
  const raw = publicKey.export({ format: "jwk" }).x;
  console.log(
    type.padEnd(8),
    "public key:", Buffer.from(raw, "base64url").length, "bytes,",
    "SPKI DER:", publicKey.export({ type: "spki", format: "der" }).length, "bytes,",
    "signature:", signature.length, "bytes,",
    "verifies:", verify(null, message, publicKey, signature),
  );
}

ed25519  public key: 32 bytes, SPKI DER: 44 bytes, signature: 64 bytes, verifies: true
ed448    public key: 57 bytes, SPKI DER: 69 bytes, signature: 114 bytes, verifies: true

エコシステムの対応状況

Ed25519 は広く利用できます。OpenSSH（9.5 以降はデフォルトの鍵タイプ）、Go の標準ライブラリ、libsodium、BoringSSL、Java 15 以降、ライブラリ経由の .NET、主要なすべての JOSE ライブラリ、OpenPGP v6 の鍵、Apple CryptoKit、現行のすべてのブラウザーの WebCrypto、そして SSH と FIDO2 向けの多くのセキュリティキーが対応しています。

Ed448 は、OpenSSL、Bouncy Castle、Java 15 以降、Node.js、Python の cryptography、一部の RFC 9580 OpenPGP 実装（Ed448 の実装は任意）、一部の JOSE ライブラリで利用できます。OpenSSH、Go の標準ライブラリ、BoringSSL、ブラウザーの WebCrypto にはありません（MDN の sign() のアルゴリズム一覧には Ed25519 が含まれますが、Ed448 は含まれません）。どちらの曲線も、公的に信頼される TLS 証明書では使用が認められていません。こうした証明書の鍵は RSA と NIST 曲線に限られています。

どちらを選ぶべきか

• SSH、Git の署名、ソフトウェアリリース、JWT、サービス間認証：Ed25519 を使います。
• WebCrypto によるブラウザー側での署名：Ed25519（古いブラウザー向けには ECDSA P-256）を使います。Ed448 は利用できません。
• 署名に 192 ビット以上の古典的セキュリティを要求するポリシー：Ed448 を使います。ポリシーが NIST 曲線を前提としている場合は P-384 か P-521 を使います（たとえば CNSA 1.0 が指定したのは Ed448 ではなく P-384 でした）。
• 組み込みのドメイン分離が必要なプロトコル：Ed448 の必須のコンテキストが役立ちます。Ed25519 では、署名対象のデータに固定のラベルを含めます。
• 帯域や容量が非常に限られた通信路やストレージ：Ed25519 を使います。署名が 50 バイト、鍵が 25 バイト短くなります。

移行時の注意点

両者の間で移行するには新しい鍵が必要です。曲線もハッシュ関数も識別子も異なるためです。

1. まずすべての検証者を確認します。Ed448 への対応がボトルネックで、Go の標準ライブラリや OpenSSH を使う利用側が 1 つでもあれば Ed448 は使えません。
2. 識別子を明示的に変更します：OID 1.3.101.113、JOSE の alg Ed448（RFC 9864）、古いライブラリでは crv が Ed448 の EdDSA、COSE −53、v6 鍵の OpenPGP アルゴリズム 28。
3. 57 バイトの鍵と 114 バイトの署名に合わせてバッファーとスキーマのサイズを決めます。32 バイトや 64 バイトの固定長フィールドは、典型的な不具合の原因です。
4. コンテキストを決めます。Ed448 を採用する場合は、プロトコルで使うコンテキスト文字列を定義してください。署名者と検証者は同じ文字列を渡さなければならないためです。
5. Ed25519 から Ed448 へ移行するよりも、長期的な保護のためにはポスト量子暗号への移行計画を優先します（ML-DSA。Ed25519 や Ed448 との複合方式も考えられます）。

参考資料

• RFC 8032：EdDSA（§5.1 Ed25519、§5.2 Ed448）
• FIPS 186-5：デジタル署名標準（§7）
• NIST SP 800-186（§3.2.3.1 Edwards25519、§3.2.3.2 Edwards448）
• RFC 8410：X.509 における Ed25519 と Ed448
• RFC 9864：完全に指定された JOSE と COSE のアルゴリズム
• RFC 9580：OpenPGP
• MDN：SubtleCrypto.sign() がサポートするアルゴリズム