up:: Classical Cryptography MOC

Ed448

Ed448 is a public-key digital signature algorithm, the higher-security instance of EdDSA (the Edwards-curve Digital Signature Algorithm), standardized in RFC 8032, that proves a message, file, or piece of software was signed by the holder of a specific private key and has not been altered since. It runs over edwards448, the untwisted Edwards form of Curve448 (the “Goldilocks” curve, whose prime is 2^448 − 2^224 − 1), and it targets roughly 224-bit classical security, making it the conservative, larger-margin sibling of Ed25519 for teams who want more headroom than a 128-bit curve.

Like every elliptic-curve scheme, its security rests on the elliptic-curve discrete logarithm problem, the exact problem a large quantum computer running Shor’s algorithm solves efficiently. So despite carrying a bigger security margin than Ed25519, Ed448 sits on the same list of algorithms the post-quantum transition has to retire, and the extra margin is a classical margin that buys nothing against a quantum attacker.

The short version:

1. Ed448 does one job, digital signatures. It proves authenticity and integrity (who signed, and that nothing changed). It never encrypts data or establishes a shared key.
2. It’s the high-security member of the EdDSA family, running over Curve448 at about 224-bit classical strength, versus Ed25519’s roughly 128-bit. It’s approved by NIST in FIPS 186-5 alongside Ed25519 and ECDSA.
3. It hashes with SHAKE256 rather than SHA-512, produces 57-byte keys and 114-byte signatures, and derives its per-signature secret deterministically, so it never needs a random number generator at signing time.
4. A quantum computer running Shor’s algorithm recovers the private key from the public key and can then forge any signature. Ed448’s larger curve raises the qubit count only modestly (roughly 4,060 logical qubits against about 2,330 for Ed25519), so it still falls to a far smaller machine than RSA of comparable classical strength.
5. The standardized replacements are ML-DSA (general purpose, with ML-DSA-87 matching Ed448’s high-security role), SLH-DSA (conservative, hash-based), and draft FN-DSA for compact roles. NIST’s schedule (NIST IR 8547) disallows classical signatures for federal use by 2035.

Think of two safes rated for different break-in times. Ed25519 is the strong everyday safe; Ed448 is the vault-grade one with thicker walls, chosen when whatever it protects has to hold for decades and the owner wants extra room for error. Both open with a signet ring: the private key presses a seal only its holder can make. The quantum problem is the same for both vaults, because Shor’s algorithm hands the forger a perfect copy of the ring regardless of how thick the walls are. Ed448’s thicker walls slow a classical burglar, not a quantum one.

What is Ed448?

Ed448 is the edwards448 instantiation of EdDSA, the signature scheme defined by the IETF in RFC 8032 and approved by NIST in FIPS 186-5. It signs and verifies data; it does not encrypt anything and it does not establish keys. Its curve is the Edwards form of Curve448, the curve Mike Hamburg introduced as “Ed448-Goldilocks,” named for the prime 2^448 − 2^224 − 1 where the exponent 224 sits in the middle like Goldilocks’ choice, neither too small for security nor so large it wastes performance. Where Curve448 in Montgomery form is used for key agreement (under the name X448), the same curve family in Edwards form is used by Ed448 for signatures.

Ed448 shares Ed25519’s design philosophy of fixing everything the implementer might otherwise get wrong, and turns each dial up for higher assurance:

1. A higher security target. Ed448 aims at about 224-bit classical security, where Ed25519 provides about 128-bit. That’s the whole reason to reach for it: a larger margin for long-lived keys and higher-assurance systems.
2. Deterministic signing. The per-signature secret is computed from a hash of the private key and the message, not drawn from a random source, so signing needs no runtime randomness and cannot suffer nonce-reuse key recovery.
3. A different internal hash. Ed448 uses the SHAKE256 extendable-output function (producing a 114-byte digest), rather than the SHA-512 that Ed25519 uses.
4. Built-in domain separation. Ed448 always signs under a dom4 prefix beginning with the string “SigEd448” plus an optional context, which cleanly separates signatures made for different purposes.
5. A single fixed parameter set. One curve, one hash, one encoding. Implementers don’t pick curves or parameters, which removes a whole category of misconfiguration.

Its security rests on the classical hardness of the elliptic-curve discrete logarithm problem over the 448-bit prime field of edwards448.

Sources: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, IRTF/IETF, January 2017, section 5.2, RFC 8032.

NIST, “Digital Signature Standard (DSS),” FIPS 186-5, February 2023, FIPS 186-5.

How does Ed448 actually sign and verify something?

Ed448 turns a private secret into an unforgeable stamp using arithmetic on the edwards448 curve, and its whole security comes from one hard-to-reverse operation: multiplying the curve’s fixed base point by a secret scalar is easy, but working backward from the result to the scalar is the elliptic-curve discrete logarithm problem, for which no efficient classical method is known.

1. Key generation. The signer starts from a 57-byte secret seed and hashes it with SHAKE256 to a 114-byte digest. Part of that digest becomes the secret scalar; the public key is that scalar multiplied by the base point, encoded as a 57-byte value. Publishing the public key reveals nothing usable about the scalar, because recovering it is the hard problem.
2. Signing. To sign a message, Ed448 computes the per-signature secret deterministically as a SHAKE256 hash over a private prefix, the dom4("SigEd448") domain string, any context, and the message, then produces the signature pair (R, S) using curve arithmetic. Because the secret comes from a hash of fixed inputs, the same key and message always yield the same safe value, and no random number generator is consulted.
3. Verification. Anyone holding the 57-byte public key recomputes the relevant hash and checks a single curve equation against the 114-byte signature. If it holds, the signature is valid, which proves both that the signer’s private key produced it and that the message is byte-for-byte what was signed.

Two design choices distinguish the mechanics from Ed25519. Ed448 hashes with SHAKE256 instead of SHA-512, and it always applies the dom4 domain-separation prefix, where Ed25519 in its pure form signs the message with no context prefix. RFC 8032 also defines a prehash variant, Ed448ph, which SHAKE256-hashes the message first and then signs the 64-byte digest, for settings that can only pass a short hash to the signer. As with Ed25519, RFC 8032 states plainly that “the use of a unique random number for each signature is not required,” because the secret is derived from the message rather than sampled.

Source: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, January 2017, section 5.2 (Ed448), RFC 8032.

What is Ed448 used for?

Ed448 appears in the same trust-layer protocols as Ed25519, registered side by side in the standards, and it’s the one an operator selects when policy or data lifetime calls for a security margin above 128 bits. It’s less common in practice than Ed25519 because most systems are content with a 128-bit curve, but it’s specified and available across the core protocols:

1. SSH. The ssh-ed448 public-key algorithm is standardized for SSH alongside ssh-ed25519 in RFC 8709, so an administrator can authenticate servers and users with an Ed448 key where a higher assurance level is required.
2. TLS. TLS 1.3 registers ed448 as a signature scheme for certificate and handshake authentication (RFC 8446), so a server or client can prove its identity during the handshake with an Ed448 key.
3. DNSSEC. Ed448 is a registered signing algorithm for DNSSEC (RFC 8080), for zone operators who want a larger margin on long-lived signing keys.
4. Code, package, and document signing. Ed448 is chosen for high-assurance or long-lived signing roles (firmware anchors, release keys, archival document signatures) where the signer wants confidence measured in decades rather than years.

Because this is the trust layer, an Ed448 break is mainly a trust and integrity problem rather than a secrecy problem. The failure mode is forgery: signatures, releases, tokens, and identities that look authentic but are not.

Sources: J. Harris, S. Josefsson, “Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol,” RFC 8709, February 2020, RFC 8709.

E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, August 2018, RFC 8446.

O. Sury, R. Edmonds, “Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC,” RFC 8080, February 2017, RFC 8080.

Is Ed448 quantum-vulnerable?

Yes, completely. Ed448 is broken by Shor’s algorithm, the quantum algorithm that efficiently solves the discrete logarithm problem, including its elliptic-curve form. A cryptographically relevant quantum computer running Shor’s algorithm takes the 57-byte public key and recovers the private scalar in polynomial time. Once an attacker holds that scalar, they hold the signet ring: they can produce valid Ed448 signatures for anything they choose, indistinguishable from the real signer’s.

This is a structural collapse of the security assumption, not a shrinking safety margin. It’s the same class of break that ends RSA, ECDSA, Ed25519, and Diffie-Hellman, because all of them rest on hard problems that Shor’s algorithm dissolves. Ed448’s larger curve and higher classical security level don’t change the verdict, because the vulnerability is in the underlying elliptic-curve math, not in the key size or the implementation. This is the roadmap lesson teams most often miss when they reach for a stronger curve: a higher-margin elliptic-curve signature is not a step toward quantum safety, it’s the same doomed math with more classical padding.

Grover’s algorithm, the other headline quantum attack, is close to irrelevant to Ed448. Grover speeds up brute-force search and only halves the effective strength of symmetric primitives like AES and hash functions. It does nothing to rescue a public-key scheme whose private key can be computed directly. So the honest one-line verdict is that Shor’s algorithm ends Ed448, and Grover’s is beside the point here.

Source: P. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Computing, 1997, quant-ph/9508027.

Does Ed448’s higher security margin help against a quantum computer?

No, and this is the counterintuitive part that matters most for anyone tempted to treat the stronger curve as a place to wait out the transition. Ed448’s extra strength is a classical margin: it makes a classical attacker’s job about 2^96 times harder than Ed25519’s (224-bit versus 128-bit), which is enormous against ordinary computers. Against Shor’s algorithm the picture is almost flat, because the quantum cost grows only gently, rather than exponentially, as the field gets larger.

A widely cited resource estimate lets us put figures on it. Breaking the elliptic-curve discrete logarithm over an n-bit prime field takes roughly 9n + 2⌈log₂(n)⌉ + 10 logical qubits. For the 256-bit-class curve behind Ed25519 that works out to about 2,330 logical qubits; for Ed448’s 448-bit field the same formula gives about 4,060 logical qubits. Doubling the field and quadrupling the classical work barely under doubles the qubit count, and that difference is trivial next to the total machine a full attack needs. Meanwhile, factoring an RSA modulus of comparable classical strength (somewhere between RSA-7680 and RSA-15360 for a 224-bit security level) needs a far larger quantum computer, because the modulus is enormous.

The practical takeaway is direct. Ed448 buys real protection against classical attack and essentially none against a quantum one, so migrating deeper into elliptic-curve signatures, even the strong ones, is a move in the wrong direction. The only fix is a post-quantum algorithm.

Source: M. Roetteler, M. Naehrig, K. Svore, K. Lauter, “Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms,” ASIACRYPT 2017, arXiv:1706.06752.

How does Ed448 compare to Ed25519?

Ed448 and Ed25519 are both members of the EdDSA family, both deterministic, both approved in FIPS 186-5, and both broken by Shor’s algorithm, so from a post-quantum standpoint they migrate together. The classical difference is that Ed448 trades size and speed for a higher security margin, and swaps the internal hash:

Property	Ed25519	Ed448
Curve	edwards25519 (equiv. to Curve25519)	edwards448 (Edwards form of Curve448)
Field prime	2^255 − 19	2^448 − 2^224 − 1
Classical security strength	about 128-bit	about 224-bit
Internal hash	SHA-512	SHAKE256 (114-byte output)
Public key size	32 bytes	57 bytes
Private key (seed)	32 bytes	57 bytes
Signature size	64 bytes	114 bytes
Domain-separation prefix	None in pure Ed25519	Always uses dom4 (“SigEd448”)
Per-signature secret	Deterministic, no RNG	Deterministic, no RNG
Quantum status	Broken by Shor’s algorithm	Broken by Shor’s algorithm

The choice between them is a classical risk decision. Ed25519 is the modern default, small and fast and supported nearly everywhere, and 128-bit security is comfortable for the vast majority of uses. Ed448 is the deliberate step up for keys with very long lifetimes or high-assurance mandates, at the cost of larger keys and signatures, slower operations, and thinner library support. Neither is closer to quantum safety than the other, so the higher margin is worth choosing only for the classical protection it provides.

Sources: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, January 2017, sections 5.1 and 5.2, RFC 8032.

What are Ed448’s key and signature sizes?

Ed448’s sizes are small and fixed, though larger than Ed25519’s because of the bigger curve. Every value below comes directly from RFC 8032, which specifies the curve, the internal hash, and the exact byte lengths:

Property	Value
Curve	edwards448 (Edwards form of Curve448, the “Goldilocks” curve)
Field prime	2^448 − 2^224 − 1
Classical security strength	about 224-bit
Private key (seed)	57 bytes
Public key	57 bytes
Signature	114 bytes (fixed length)
Internal hash	SHAKE256, 114-byte output
Per-signature secret	Deterministic, no random source at signing

Hold the 114-byte signature figure, because it’s the number the post-quantum replacements have to swallow, and Ed448 is already the largest classical option. The smallest ML-DSA signature is over 2,400 bytes, and SLH-DSA signatures run into the thousands of bytes, so the replacement math is the reverse of the elliptic-curve win: post-quantum signatures are far bigger, and absorbing that size is the real migration cost. It lands on artifact formats, protocol limits, parsers, and trust stores, not on CPU.

Source: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, January 2017, section 5.2.5, RFC 8032.

What are the implementation gotchas with Ed448?

Ed448 carries a few practical wrinkles that Ed25519 doesn’t, mostly stemming from its different hash and its lower deployment footprint:

1. It needs SHAKE256, not SHA-512. Ed448’s internal hash is the Keccak-based SHAKE256 extendable-output function, so a platform that only ships SHA-2 has to add a Keccak implementation. Older or minimal crypto stacks sometimes lack it, which is a real source of interoperability friction.
2. The context prefix is mandatory. Ed448 always signs under the dom4 domain-separation string, and both signer and verifier have to handle the context identically. A verifier that mishandles or omits the context will reject valid signatures.
3. Library and hardware support is thinner. Despite being standardized in the same RFCs as Ed25519, Ed448 is implemented in fewer libraries, HSMs, and protocol stacks, because most deployments are satisfied with a 128-bit curve. Reaching for Ed448 can mean discovering a dependency that doesn’t support it.
4. Pure versus prehash. RFC 8032 defines both Ed448 (which signs the whole message) and Ed448ph (which signs a SHAKE256 prehash of the message). They’re different algorithms with different domain flags, so a signer and verifier have to agree on which one is in use.
5. The safe part is inherited. Ed448 keeps Ed25519’s deterministic signing, so it structurally avoids the nonce-reuse key-recovery flaw that plagues ECDSA. That advantage carries over intact.

Source: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, January 2017, sections 2 and 5.2, RFC 8032.

What replaces Ed448?

Ed448 gets replaced by a post-quantum signature standard, not upsized or patched, because the elliptic-curve discrete logarithm problem stops being hard once Shor’s algorithm is available, and there’s no larger Goldilocks curve that helps. NIST finalized the replacement signature standards, and the right one depends on the role Ed448 was playing. Because Ed448 was usually chosen for its higher security level, its natural successor is a higher-parameter post-quantum set:

Replacement	Standard	Basis	Best fit for the Ed448 role it takes over
ML-DSA	FIPS 204	Lattice (Module-LWE)	The general-purpose successor. ML-DSA-87 (NIST security category 5) matches Ed448’s high-security intent
SLH-DSA	FIPS 205	Hash-based	Conservative, long-lived roots of trust, the same decades-horizon role Ed448 was often chosen for, with security resting on plain hash functions
FN-DSA	FIPS 206 (draft)	Lattice (NTRU)	Constrained settings where compact signatures matter most; the FALCON-derived standard, not yet finalized

For most environments ML-DSA is the direct successor, and the high-assurance ML-DSA-87 parameter set is the natural landing spot for a system that deliberately chose Ed448’s 224-bit margin. SLH-DSA is the deliberately conservative choice where a signing key protects something for decades and you want its security resting on plain hash functions rather than lattice math, which is exactly the profile of many Ed448 deployments. These are not drop-in swaps, and the transitional pattern most estates use is dual signatures, carrying both a classical and a post-quantum signature so verifiers can upgrade at their own pace, which overlaps with hybrid cryptography and composite certificates. Designing for that flexibility is crypto-agility.

Sources: NIST FIPS 204, “Module-Lattice-Based Digital Signature Standard,” August 2024, FIPS 204.

NIST FIPS 205, “Stateless Hash-Based Digital Signature Standard,” August 2024, FIPS 205.

When does Ed448 have to be gone?

The clock is set by NIST IR 8547, NIST’s transition roadmap, which puts every classical public-key algorithm, elliptic-curve signatures included, on a deprecation-then-disallowance schedule:

Milestone	Year	What it means for Ed448
Deprecated	2030	The 2030 deprecation targets 112-bit-strength public-key algorithms. Ed448’s roughly 224-bit strength sits well above that line, so it isn’t caught by the 112-bit deprecation the way RSA-2048 or a P-224 curve is
Disallowed	2035	All classical elliptic-curve signatures, Ed448 included, become disallowed for federal use, with no exceptions. This is the operative deadline for Ed448

“Deprecated” and “disallowed” are different instructions. Deprecated is “you may, but you own the documented risk.” Disallowed is a hard stop. Ed448’s higher security strength means the 2030 deprecation of weak (112-bit) algorithms doesn’t name it directly, so the binding date is the 2035 disallowance of all classical public-key. Because insurers, sector regulators, and procurement programs align to NIST, these federal dates function as the de facto industry timeline even for organizations that never touch a government contract. Anything signed today with Ed448 that still needs to be trusted after a quantum computer arrives is already living on Mosca’s borrowed time, and Ed448’s very appeal, its long-lived, high-assurance keys, is exactly what makes that exposure sharpest.

Source: NIST IR 8547 (Initial Public Draft), “Transition to Post-Quantum Cryptography Standards,” November 2024, NIST IR 8547 ipd.

Common misconceptions

1. “Ed448 has a bigger security margin, so it’s more quantum-safe than Ed25519.” It isn’t. The extra margin is entirely classical. Both rest on the elliptic-curve discrete logarithm problem, and both fall completely to Shor’s algorithm. Ed448 falls to a machine only modestly larger than the one that breaks Ed25519.
2. “Ed448 encrypts my high-value data.” It doesn’t. Ed448 is a signature algorithm; it proves authenticity and integrity. Confidentiality comes from a separate key-exchange and symmetric cipher layer, so a broken Ed448 is a forgery risk, not a data-leak risk.
3. “Ed448 and X448 are the same key.” They come from the same Curve448 family but do different jobs. Ed448 signs, X448 does key agreement, and you should not reuse one key for both roles.
4. “A bigger Edwards curve will hold up against quantum.” Shor’s algorithm scales gently with field size, so moving from a 256-bit curve to a 448-bit one buys almost nothing against a quantum attacker. The only real fix is a post-quantum algorithm.
5. “Ed448 uses SHA-512 like Ed25519.” It doesn’t. Ed448 hashes with SHAKE256, which is why a platform without a Keccak implementation can’t run it even if it supports Ed25519.
6. “If I chose Ed448 for long-lived keys, I’m covered for the future.” The opposite is true. Long-lived, high-assurance Ed448 keys are the ones most exposed to a future quantum forger, because they’re meant to stay trusted for decades, straight through the arrival of a quantum computer.

Questions people ask

Is Ed448 safe to use today? Against classical attackers, yes, and its 224-bit security level gives more margin than any common curve, plus the deterministic design removes the nonce-randomness failure that trips up ECDSA. The concern is future quantum capability plus the reality that anything you sign now may need to stay trustworthy past the arrival of a quantum computer, so new long-lived signatures should be planned with a post-quantum path.

What’s the difference between Ed448 and Ed25519? Both are EdDSA signature schemes and both fall to Shor’s algorithm. Ed448 runs on the larger Curve448 at about 224-bit classical security, hashes with SHAKE256, and produces 57-byte keys and 114-byte signatures; Ed25519 runs on Curve25519 at about 128-bit, hashes with SHA-512, and produces 32-byte keys and 64-byte signatures. Ed448 trades size and speed for a bigger classical margin.

Why would I choose Ed448 over Ed25519? For a higher classical security margin on keys that live a long time or carry a high-assurance mandate. The cost is larger keys and signatures, slower operations, and thinner library support. If 128-bit security is enough, Ed25519 is the simpler default.

Is Ed448 approved by NIST? Yes. EdDSA with Ed448 is specified in FIPS 186-5 and RFC 8032, with the edwards448 curve parameters given in the companion SP 800-186. It remains an approved classical signature algorithm, and NIST IR 8547 sets the schedule for eventually disallowing it as post-quantum standards take over.

What is the direct replacement for Ed448? ML-DSA for general-purpose signing, with the high-assurance ML-DSA-87 set matching Ed448’s security intent; SLH-DSA for conservative long-lived roots of trust; and draft FN-DSA where compact signatures matter most.

How big are post-quantum signatures compared to Ed448? Much bigger. An Ed448 signature is a fixed 114 bytes; the smallest ML-DSA signature is over 2,400 bytes, and hash-based SLH-DSA signatures run into the thousands of bytes. That size jump is the main engineering cost of the migration, landing on artifact formats, parsers, and trust stores.

Does Ed448 need a random number for each signature? No. Like Ed25519, Ed448 derives its per-signature secret from a hash of the private key and the message, so it never consults a random source at signing and cannot fall to the nonce-reuse key recovery that has drained ECDSA keys. RFC 8032 states that a unique random number for each signature is not required.

Is Ed448 quantum-resistant because it’s the strongest EdDSA curve? No. Being the strongest classical Edwards curve makes it the hardest for a classical attacker, not for a quantum one. Shor’s algorithm recovers the private key from the public key regardless of curve size, so Ed448 needs a post-quantum replacement exactly like every other elliptic-curve signature.

---

Everything here is the map, given freely. When your team needs its own signing keys and trust workflows found, sized, and sequenced onto a post-quantum path, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.