up:: Classical Cryptography MOC

Curve448

Curve448 is a high-security elliptic curve, designed by Mike Hamburg and standardized in RFC 7748, that serves as the mathematical foundation for the X448 key-exchange function and, in an Edwards form, the Ed448 signature scheme. It’s a Montgomery-form curve over the prime field of 2^448 − 2^224 − 1, chosen to deliver about 224-bit classical security, a much larger margin than its widely deployed sibling Curve25519. Hamburg’s design is often called “Ed448-Goldilocks,” and the whole family sits inside elliptic-curve cryptography. Its security rests on the elliptic-curve discrete logarithm problem, so despite that generous classical margin, Curve448 falls to Shor’s algorithm on a large quantum computer exactly the way every other elliptic-curve system does, and its bigger key buys it nothing against a quantum attacker.

The short version:

• Curve448 is a specific elliptic curve, not a protocol or an algorithm you run directly. It’s the curve; X448 and Ed448 are the constructions built on it.
• Mike Hamburg designed it and it was standardized in RFC 7748 as a Montgomery curve over the prime field of 2^448 − 2^224 − 1, at roughly the 224-bit classical security level.
• It’s the higher-security sibling of Curve25519. Teams reach for Curve448 when they want a larger safety margin than the ~128-bit 25519 family, and they pay for it with bigger keys and slower operations.
• X448 uses Curve448 for key agreement (confidentiality); Ed448 uses an Edwards form of the same curve for signatures (authenticity).
• Curve448’s security is the elliptic-curve discrete logarithm problem, which Shor’s algorithm solves in polynomial time on a large quantum computer. That’s a full structural break, and the extra classical headroom does nothing to stop it.

What is Curve448?

Curve448 is a single, specific elliptic curve over a finite field, the mathematical object that a small family of public-key algorithms performs their arithmetic on. It is not a complete cryptographic protocol like TLS, and on its own it performs no key exchange and signs nothing. It’s the curve; the useful constructions are built on top of it.

Mike Hamburg introduced the curve in his 2015 paper “Ed448-Goldilocks, a new elliptic curve,” and the IETF standardized it in RFC 7748 alongside Curve25519. Concretely, RFC 7748 defines it as a Montgomery-form elliptic curve

v^2 = u^3 + 156326·u^2 + u

over the prime field with p = 2^448 − 2^224 − 1. That prime is the source of the “448” in the name, and it has a tidy structure: modulo p, 2^448 is congruent to 2^224 + 1, so the value 2^224 satisfies x^2 = x + 1, the defining equation of the golden ratio. That “golden” prime is where the “Goldilocks” nickname comes from. The curve has cofactor 4, base-point u-coordinate 5, and its useful points live in a large prime-order subgroup, which is what the cryptography actually operates in.

Sources: M. Hamburg, “Ed448-Goldilocks, a new elliptic curve,” IACR ePrint 2015/625, eprint.iacr.org;

A. Langley, M. Hamburg, S. Turner, “Elliptic Curves for Security,” RFC 7748, §4.2, January 2016, datatracker.ietf.org.

The name “Curve448” gets used loosely, so it helps to keep three meanings straight:

1. The curve itself, the Montgomery curve above. That’s the strict, correct meaning and the subject of this note.
2. X448, the Diffie-Hellman key-agreement function that runs on the curve. A lot of writing says “Curve448” when it means X448 key exchange, the same way people say “Curve25519” when they mean X25519.
3. The broader Goldilocks family, meaning the design that also includes Ed448 signatures over the equivalent Edwards curve.

NIST also recognizes the curve. SP 800-186 specifies it as “Curve448” (Montgomery form), lists the birationally related Edwards form “Edwards448,” and places all of them at the 224-bit security strength row of its recommended-curve table.

Source: NIST, “Recommendations for Discrete Logarithm-Based Cryptography, Elliptic Curve Domain Parameters,” SP 800-186, §3.2.2.2 and Table 1, February 2023, csrc.nist.gov.

The everyday analogy: a vault door built two sizes thicker

Think of Curve448 as the same kind of vault door as Curve25519, built two sizes thicker. The 25519 door is already rated far beyond what any safecracker alive could ever get through, and it’s light enough to swing fast. The 448 door is heavier, slower to open, and rated for a threat nobody has, but a security officer who wants the fattest margin on the drawing spec picks it anyway. Both doors are excellent against a human with a drill. Neither one helps when the attacker stops drilling and simply reads the combination off the lock, which is what a quantum computer does to every elliptic curve. The thicker door and the thinner door open just the same once the combination is known.

How does Curve448 work?

Curve448 provides a set of points and one operation, and every construction built on it relies on that operation being easy in one direction and infeasible to reverse.

1. The points and the group. The solutions to the curve equation over the field of 2^448 − 2^224 − 1, plus a special point at infinity, form a mathematical group. You can “add” two points to get a third point on the curve, and adding a point to itself repeatedly is called scalar multiplication.
2. The base point. RFC 7748 fixes a specific starting point, the base point, whose u-coordinate is 5 in the single-coordinate form the standard uses. Everyone uses the same base point.
3. The one-way operation. A private key is a large secret number (a scalar). The matching public key is the base point multiplied by that scalar. Computing the public key from the private key is fast. Recovering the private scalar from the public key means solving the elliptic-curve discrete logarithm problem, which has no efficient classical solution for a well-chosen curve like this one.
4. What the higher layers do with it. X448 uses this to let two parties reach a shared secret (each multiplies the other’s public point by their own private scalar and lands on the same value). Ed448 uses a mathematically equivalent Edwards form of the curve to produce and verify signatures.

Source: RFC 7748, §4.2 and §5, January 2016, datatracker.ietf.org.

Two design features carry over from the 25519 family and explain why Curve448 was built the way it was:

1. Montgomery form and single-coordinate arithmetic. The curve is written in Montgomery form, which supports the fast, simple Montgomery-ladder scalar multiplication that uses only the u-coordinate of points. That method runs in constant time naturally, which closes off the timing side-channels that have leaked private keys out of clumsier curve implementations.
2. The cofactor-4 structure. The curve’s cofactor is 4, and RFC 7748’s scalar handling for X448 is written so that small-subgroup and edge-case pitfalls tied to that cofactor are neutralized in practice, which is a big part of why the Goldilocks family is described as misuse-resistant.

Source: RFC 7748, §4.2 and §5, January 2016, datatracker.ietf.org.

Why would you choose Curve448 over Curve25519?

You choose Curve448 when you want a larger classical security margin than Curve25519 gives, and you accept slower operations and bigger keys to get it. The two curves are built on the same principles by overlapping designers; the difference is the size of the field and, with it, the security level.

1. A bigger margin. Curve25519 targets about 128-bit classical security. Curve448 targets about 224-bit. Both numbers are already far beyond what any classical attacker can reach, so the extra headroom is a hedge for very long-lived data or for conservative, high-assurance environments that want maximum distance from the edge.
2. Rigidity and misuse resistance carry over. Like Curve25519, Curve448’s parameters follow a public procedure with little room for a hidden weak choice, and its constant-time single-coordinate ladder removes categories of implementation mistake. You don’t give up those properties by choosing the bigger curve.
3. The cost is real. The 448-bit field means public keys and computations are roughly twice the size and slower than the compact 32-byte 25519 keys. For high-volume systems that added cost is why Curve25519, not Curve448, became the default.

Source: RFC 7748, §3 and §4, January 2016, datatracker.ietf.org.

One caution about all of that margin: it’s a classical margin only. The jump from 128-bit to 224-bit classical security raises the bar for a classical attacker enormously, and it does nothing against a quantum one, because Shor’s algorithm breaks the discrete-log problem regardless of the curve’s size.

Where does Curve448 show up, and what is it used for?

Curve448 appears in the same protocols and libraries as Curve25519, offered as the higher-security option rather than the default, so you meet it less often but in the same places. It reaches real systems through the constructions built on it:

1. X448 key agreement. This is the main use. RFC 7748 defines X448 as an ECDH-style key-agreement function, and it appears in TLS, SSH (curve448-sha512), and other protocols as a stronger-margin alternative to X25519.
2. Ed448 signatures. The Edwards form of the same curve backs Ed448, the higher-security EdDSA signature scheme defined in RFC 8032, used where a signer wants a larger margin than Ed25519.
3. High-assurance and conservative deployments. Because it carries a 224-bit classical margin and NIST-recommended status, Curve448 tends to show up in environments that deliberately choose maximum classical headroom over speed.

Sources: for SSH, A. Adamantiadis, S. Josefsson, M. Baushke, “Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448,” RFC 8731, February 2020, datatracker.ietf.org;

for EdDSA over the curve, S. Josefsson and I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, §5.2, January 2017, datatracker.ietf.org.

The practical takeaway is that wherever Curve448 is deployed, it sits underneath the same jobs Curve25519 does (the confidentiality of a channel and the authenticity of a signature), just with a heavier curve. That also means it inherits the same quantum exposure, because the security still rests on elliptic-curve discrete logarithms.

How does Curve448 relate to X448, Ed448, and Curve25519?

Curve448 is the shared foundation, and the algorithm names around it describe different jobs done on that foundation, while Curve25519 is the same idea at a smaller size. Keeping them straight matters, because they carry different risks and different post-quantum replacements.

1. X448 is the Diffie-Hellman key-agreement function over Curve448. Its job is confidentiality (setting up an encrypted channel), so its quantum risk is harvest-now-decrypt-later decryption of recorded traffic.
2. Ed448 is the EdDSA signature scheme over edwards448, an Edwards curve related to Curve448 (mathematically the same underlying curve in a signature-friendly form). Its job is authenticity, so its quantum risk is signature forgery.
3. Curve25519 is the smaller, faster, ~128-bit sibling, also standardized in RFC 7748. It backs X25519 for key agreement and Ed25519 for signatures, and it’s the common default; Curve448 is the higher-margin option for teams that want more headroom.

Sources: RFC 7748, §4.1 and §4.2, January 2016, datatracker.ietf.org;

RFC 8032, §5.1 and §5.2, January 2017, datatracker.ietf.org.

The relationship in one line: Curve448 is the curve, X448 and Ed448 are the algorithms that run on it, and Curve25519 with X25519 and Ed25519 is the same design scaled down for speed. All of them rest on the elliptic-curve discrete logarithm problem, so all of them share the same quantum fate.

Is Curve448 quantum-vulnerable?

Yes, completely. Every construction built on Curve448 is broken by Shor’s algorithm, which solves the elliptic-curve discrete logarithm problem in polynomial time on a large fault-tolerant quantum computer. Because the whole security story of Curve448 is “recovering the private scalar from the public key is infeasible,” and Shor’s algorithm does exactly that recovery efficiently, a capable quantum computer reads the private key straight off the public one. The 224-bit classical margin doesn’t change the outcome.

Source: P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997, arxiv.org.

There’s an important point about that big classical margin. Against a classical attacker, going from Curve25519’s ~128-bit level to Curve448’s ~224-bit level is an astronomical increase in difficulty. Against a quantum attacker, the cost of Shor’s algorithm grows only polynomially with the curve size, so the larger field raises the number of qubits and operations needed by a modest amount rather than putting the curve out of reach. Resource estimates for breaking a 256-bit elliptic curve land around 2,330 logical qubits; a 448-bit curve needs more, but it stays in the same regime as RSA and the smaller curves, not beyond it. “We chose the strongest curve” is not the safe position against quantum that it sounds like.

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

To be exact about which quantum attack matters: Curve448 is threatened by Shor’s algorithm, not Grover’s algorithm. Grover’s only speeds up brute-force search and merely dents symmetric ciphers and hashes like AES-256 and SHA-256, which survive with larger parameters. Shor’s algorithm is the one that ends public-key math like Curve448’s outright. What the failure looks like depends on the construction: through X448 it’s a confidentiality break (recorded sessions get decrypted), and through Ed448 it’s a trust break (signatures get forged).

What replaces Curve448?

There isn’t a “post-quantum Curve448,” because the fix is to leave the elliptic-curve family entirely, not to pick a bigger curve. Curve448 is already the bigger curve, and it’s still broken. The replacement depends on the job the curve was doing:

1. For key agreement (the X448 role), the standardized replacement is ML-KEM, the module-lattice key-encapsulation mechanism NIST finalized in 2024. It agrees a shared secret like X448 did, but rests on a lattice problem no known quantum algorithm solves efficiently.
2. For signatures (the Ed448 role), the standardized replacements are ML-DSA and the hash-based SLH-DSA.

Sources: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, csrc.nist.gov;

NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, csrc.nist.gov;

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

In practice the transition is happening in hybrid form for confidentiality, where a classical curve runs alongside ML-KEM so the connection stays safe as long as either component holds. Most of that hybrid deployment pairs the faster Curve25519 with ML-KEM (the widely deployed X25519MLKEM768 combination) rather than Curve448, because the classical half is there for defense-in-depth during the changeover, and speed wins for the classical component. Getting from a Curve448 estate to post-quantum cleanly is what crypto-agility is for.

Source: K. Kwiatkowski et al., “Post-quantum hybrid key agreement X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 for TLS 1.3,” draft-ietf-tls-ecdhe-mlkem, datatracker.ietf.org.

What are Curve448’s parameters?

Curve448 has one fixed parameter set, part of the same appeal as Curve25519: nothing is negotiated and there are no sizes to choose. The first table gives the curve’s own defining values from RFC 7748; the second places it against its smaller sibling so the roles and the tradeoff are visible.

Parameter	Value	Source
Curve form	Montgomery, v^2 = u^3 + 156326·u^2 + u	RFC 7748 §4.2
Prime field	p = 2^448 − 2^224 − 1	RFC 7748 §4.2
Cofactor	4	RFC 7748 §4.2
Base point (u-coordinate)	5	RFC 7748 §4.2
Classical security level	~224-bit	RFC 7748 §4.2 / NIST SP 800-186 Table 1
Designer / year	Mike Hamburg, 2015	Hamburg, ePrint 2015/625

Curve	Field size	Classical security	Key-agreement function	Signature scheme	Typical use
Curve25519	2^255 − 19 (~32-byte keys)	~128-bit	X25519	Ed25519	The fast, common default
Curve448	2^448 − 2^224 − 1 (~56-byte keys)	~224-bit	X448	Ed448	The higher-margin option

Both rows rest entirely on the elliptic-curve discrete logarithm problem, so both fall to Shor’s algorithm. Choosing Curve448 over Curve25519 buys a larger classical margin and a higher quantum cost, and no post-quantum protection at all.

Sources: RFC 7748, §4.1 and §4.2, January 2016, datatracker.ietf.org;

NIST SP 800-186, Table 1, February 2023, csrc.nist.gov.

Common misconceptions

1. “Curve448 is a protocol or an algorithm I run.” It’s a curve, the math object. The things you actually run are X448 for key exchange and Ed448 for signatures, both built on Curve448.
2. “Curve448 is quantum-safe because it’s the high-security curve.” Its 224-bit rating is a classical margin. Shor’s algorithm breaks the underlying discrete-log problem regardless of curve size, so Curve448 is as quantum-vulnerable as any elliptic curve.
3. “Curve448 is quantum-resistant, and Curve25519 isn’t.” Both rest on the same elliptic-curve discrete logarithm problem and both fall to Shor’s algorithm. Curve448 is stronger only against classical attackers.
4. “Moving from Curve25519 to Curve448 is a step toward post-quantum security.” It isn’t a step toward post-quantum anything. It’s a bigger classical margin on the same broken foundation; the actual move is to ML-KEM and the PQC signature standards.
5. “Ed448-Goldilocks is a different thing from Curve448.” They name the same design. “Ed448-Goldilocks” is Hamburg’s name for the curve and its Edwards signature form; RFC 7748 standardizes the Montgomery form as “Curve448.”
6. “Curve448 encrypts data or signs things by itself.” It does neither on its own. It supplies the point arithmetic that X448 and Ed448 use; a symmetric cipher like AES does the bulk encryption.

Questions people ask

Is Curve448 still safe to use today? Yes, against every classical attacker it’s very strong, with an even larger margin than Curve25519. The exposure is entirely future and, for key agreement, retroactive: traffic protected by X448 today can be decrypted later once a quantum computer exists, so long-lived confidential data is the real concern.

What’s the difference between Curve448 and Curve25519? Both are Montgomery elliptic curves from RFC 7748 built on the same principles. Curve25519 uses a 255-bit field for about 128-bit classical security and compact, fast 32-byte keys, and it’s the default. Curve448 uses a 448-bit field for about 224-bit classical security with larger, slower keys, and it’s the higher-margin option. Both are broken by a quantum computer.

What’s the difference between Curve448 and X448? Curve448 is the elliptic curve, the underlying math. X448 is the specific Diffie-Hellman key-agreement function that runs on that curve, defined in RFC 7748. People often say “Curve448” when they mean X448 key exchange, but strictly, one is the curve and the other is the function on it.

Why is it called Ed448-Goldilocks? Mike Hamburg named it that in his 2015 paper. The “Goldilocks” nickname comes from the golden-ratio structure of the prime 2^448 − 2^224 − 1, where 2^224 behaves like the golden ratio (it satisfies x^2 = x + 1 modulo the prime), which makes the field arithmetic efficient.

Who designed Curve448, and when? Mike Hamburg designed it and published it in his 2015 paper “Ed448-Goldilocks, a new elliptic curve.” The IETF standardized it in RFC 7748 (2016), which specifies both Curve448 and Curve25519, and NIST later added it to SP 800-186 (2023).

Does a quantum computer really break Curve448? Yes. Shor’s algorithm solves the elliptic-curve discrete logarithm problem in polynomial time on a large quantum computer, which is precisely the problem Curve448’s security depends on. Its bigger field raises the quantum cost somewhat, and never enough to make it safe.

Do I have to replace Curve448? Eventually, for anything with a long confidentiality or trust lifetime. For key agreement the replacement is ML-KEM, and for signatures it’s ML-DSA or SLH-DSA. Staying on a big curve like Curve448 is not a fix.

Should I pick Curve448 over Curve25519 for new systems? For most systems Curve25519 is the pragmatic default because it’s fast and its ~128-bit margin is already ample. Curve448 makes sense where policy or very long data lifetimes call for the largest classical margin. Either way, the durable move is planning the shift to post-quantum standards, since both curves share the same quantum exposure.

How urgent is this for my organization? It depends on how long your data must stay secret. Apply Mosca’s inequality: if secrecy-lifetime plus migration-time exceeds the time until a quantum computer arrives, data you send today over a Curve448-based channel is already exposed, which pushes long-lived confidential traffic to the front of the queue.

---

Everything here is the map, given freely. When your team needs its own elliptic-curve exposure found, prioritized, and sequenced onto a real migration plan, that’s what an alignment briefing is for.

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