Ed25519 vs Ed448: 128-bit or 224-bit EdDSA

Ed25519 vs Ed448 is a question of margin. Both are the same algorithm family from RFC 8032, both are approved in FIPS 186-5, and both sign deterministically with no per-signature randomness. Ed448 runs on a larger curve for about 224-bit classical security instead of about 128, and pays for it in size, speed and ecosystem support.

At a glance

Speeds were measured on one core of an Apple M4 Max with openssl speed.

Security margin

Both are EdDSA over Edwards curves with complete addition formulas, deterministic nonces and strict encodings, so they share the same robustness against implementation mistakes. The difference is the size of the group. Ed25519's group of about 2²⁵² elements gives about 128-bit security against Pollard's rho, the same level as P-256, AES-128 and SHA-256 collisions. Ed448's group of about 2⁴⁴⁶ elements gives about 224 bits, more than P-384 (192) and close to P-521.

For classical attackers 128 bits is far beyond reach, so the extra margin hedges against unexpected advances in elliptic-curve cryptanalysis rather than against brute force. Against a large quantum computer both curves fall to Shor's algorithm with modest extra cost for the larger one, which is why NIST's post-quantum plans treat them the same way.

Design differences

Ed448 is not a scaled-up copy. It hashes with SHAKE256 instead of SHA-512, which means a different hash in your dependency tree, and it always prefixes a domain string with a context of up to 255 bytes. Ed25519 has no context in its pure form; Ed25519ctx exists but is rarely implemented. If your protocol needs domain separation between different uses of one key, Ed448 gives it for free, while with Ed25519 you must put the separation into the signed message.

Both have prehash variants, Ed25519ph and Ed448ph (HashEdDSA in FIPS 186-5 §7.8), which are separate algorithms with incompatible signatures; use the pure versions unless you must sign data you cannot pass through in one piece.

The script below, run with Node.js 26.10 (OpenSSL 3.6.5), shows the size difference.

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

Ecosystem support

Ed25519 is widely available: OpenSSH (the default key type since 9.5), Go's standard library, libsodium, BoringSSL, Java 15 and later, .NET through libraries, every major JOSE library, OpenPGP v6 keys, Apple CryptoKit, WebCrypto in all current browsers, and many security keys for SSH and FIDO2.

Ed448 is available in OpenSSL, Bouncy Castle, Java 15 and later, Node.js, Python's cryptography, some RFC 9580 OpenPGP implementations (where it is optional) and some JOSE libraries. It is absent from OpenSSH, Go's standard library, BoringSSL and browser WebCrypto (MDN's list of sign() algorithms includes Ed25519 but not Ed448). Neither curve is allowed in publicly trusted TLS certificates, whose keys are limited to RSA and the NIST curves.

When to choose which

• SSH, Git signing, software releases, JWTs, service-to-service authentication: Ed25519.
• Browser-side signing with WebCrypto: Ed25519 (or ECDSA P-256 for older browsers); Ed448 is not available.
• A policy that requires at least 192-bit classical security for signatures: Ed448, or P-384 or P-521 if the policy is NIST-curve based (for example CNSA 1.0 named P-384, not Ed448).
• Protocols that need built-in domain separation: Ed448's mandatory context helps; with Ed25519, include a fixed label in the signed data.
• Very constrained links or storage: Ed25519, since signatures are 50 bytes shorter and keys 25 bytes shorter.

Migration notes

Moving between the two means new keys: they are different curves, different hashes and different identifiers.

1. Check every verifier first. Ed448 support is the bottleneck; a single consumer on Go's standard library or OpenSSH rules it out.
2. Change identifiers explicitly: OID 1.3.101.113, JOSE alg Ed448 (RFC 9864) or EdDSA with crv Ed448 for older libraries, COSE −53, OpenPGP algorithm 28 in v6 keys.
3. Size buffers and schemas for 57-byte keys and 114-byte signatures; fixed 32- and 64-byte fields are the classic breakage.
4. Decide on contexts. If you adopt Ed448, define the context string your protocol uses, because signer and verifier must pass the same one.
5. For long-term protection, prefer a post-quantum plan (ML-DSA, possibly in a composite with Ed25519 or Ed448) over moving from Ed25519 to Ed448.

References

• RFC 8032, EdDSA (§5.1 Ed25519, §5.2 Ed448)
• FIPS 186-5, Digital Signature Standard (§7)
• NIST SP 800-186 (§3.2.3.1 Edwards25519, §3.2.3.2 Edwards448)
• RFC 8410, Ed25519 and Ed448 in X.509
• RFC 9864, fully-specified JOSE and COSE algorithms
• RFC 9580, OpenPGP
• MDN: SubtleCrypto.sign() supported algorithms