up:: Classical Cryptography MOC

X448

X448 is the elliptic-curve Diffie-Hellman key-agreement function defined over Curve448 in RFC 7748, used by two parties to derive an identical shared secret over an open channel without ever sending that secret across it. It’s the higher-security sibling of X25519: the same ECDH idea run over a bigger curve to hedge against future advances in elliptic-curve cryptanalysis, offering roughly 224-bit classical security in a 56-byte public key. It’s a defined key-exchange group in TLS 1.3 and the basis of an SSH key-exchange method. Its security rests on the elliptic-curve discrete logarithm problem, which Shor’s algorithm solves efficiently on a large quantum computer, so recorded X448 traffic is exposed to harvest-now-decrypt-later decryption.

The short version:

• X448 is a single standardized elliptic-curve Diffie-Hellman function (RFC 7748), the heavier-margin counterpart to X25519. It agrees a shared secret; it doesn’t encrypt data and it doesn’t sign anything.
• It runs over Curve448, the Montgomery curve over the prime field 2^448 − 2^224 − 1, and produces 56-byte public keys at roughly 224-bit classical security, double the margin X25519 targets.
• RFC 7748 provides it for designs that accept slower performance in exchange for a larger hedge against cryptanalytic progress against elliptic curves.
• It’s a defined key-exchange group in TLS 1.3 (codepoint 0x001E) and the basis of the SSH curve448-sha512 method, though X25519 is the far more common default.
• X448’s security rests on the elliptic-curve discrete logarithm problem, which Shor’s algorithm breaks in polynomial time on a large quantum computer. A bigger curve buys a wider classical margin and no quantum protection, so the successor is ML-KEM.

What is X448?

X448 is a key-agreement function: a precise, standardized way for two parties to compute the same secret value using Curve448 arithmetic, even though every message they exchange is visible to an eavesdropper. The name combines the “X” (for the x-coordinate-only scalar multiplication it uses) with 448 (the curve’s bit size). RFC 7748 defines the function down to the byte, including how scalars and coordinates are encoded, so two independent implementations interoperate exactly.

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

It helps to place X448 against its relatives. ECDH is the general method, key agreement over any elliptic curve. Curve448 is the specific curve, the math X448 runs on. X25519 is the faster, more widely deployed function built the same way over the smaller Curve25519. X448 is the concrete function that pins ECDH to Curve448 with one fixed recipe, chosen when a design wants more security margin than X25519 targets. The shared value X448 outputs is then run through a key derivation function to produce the symmetric keys that actually encrypt the conversation.

Two things X448 is not. It’s not a digital signature scheme, so it proves nothing about who you’re talking to; the signature job over this same curve family belongs to Ed448. And it’s not the cipher that encrypts your data; that’s a symmetric algorithm like AES-256. X448 only produces the secret those other pieces depend on, so it’s always paired with certificates, signatures, and a symmetric cipher to build a complete secure channel.

The everyday analogy: over-building the bridge

Two engineers are designing the same footbridge for the same daily traffic. One rates it exactly for today’s heaviest expected load plus a normal safety margin, and it’s light, cheap, and quick to build. That’s X25519. The other over-builds the identical design with thicker cables and deeper foundations, spending more material and more time, because they want the bridge to stand even if the trucks get heavier than expected or the steel turns out weaker than believed. That’s X448.

Both bridges cross the same river the same way. X448 just pours extra structure into the crossing as a hedge against a future that stresses it harder than today’s math does. It costs speed and bytes, and it buys margin. The catch that runs through this whole note: a quantum computer dissolves the ground both bridges stand on rather than pushing harder on the deck, so the extra steel changes nothing about the quantum threat.

How does X448 work?

X448 runs the Diffie-Hellman exchange over Curve448 with a tightly specified recipe. The exchange itself is short:

1. Both parties already share the fixed public parameters baked into the standard: the curve (Montgomery-form Curve448 over the field 2^448 − 2^224 − 1, with curve constant A = 156326) and the base point (u-coordinate 5). Nothing here is negotiated per session.
2. The first party takes a 56-byte private key, “clamps” it (RFC 7748 forces specific bits on and off), and computes their public key by multiplying the base point by that clamped scalar. They send their 56-byte public key.
3. The second party does the same with their own private key and sends their 56-byte public key.
4. Each party multiplies the public key they received by their own clamped private scalar. Both land on the same shared secret, because multiplying the base point by both scalars gives the same point regardless of order.
5. That shared 56-byte value is fed through a KDF to derive the symmetric session keys.

Source: RFC 7748, §5 (the X448 function) and §6.2 (the Diffie-Hellman exchange), January 2016, datatracker.ietf.org.

X448 shares X25519’s two defining engineering choices, which is why it inherits the same safety properties:

1. Single-coordinate Montgomery ladder. X448 computes using only the x-coordinate (called the u-coordinate) of curve points, via a fixed algorithm called the Montgomery ladder. This is efficient and runs in constant time naturally, which closes off timing side-channels that have historically leaked private keys from other curve implementations.
2. Scalar clamping. Every private key is normalized before use so that classes of weak or edge-case scalars can’t occur, and so implementations converge on the same behavior. Curve448’s cofactor is 4 (Curve25519’s is 8), and the clamping is set accordingly, which is a large part of why both functions are described as misuse-resistant.

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

The security rests on the same asymmetry every Diffie-Hellman scheme uses. Computing a public key from a private scalar is fast. Recovering the private scalar from the public key is the elliptic-curve discrete logarithm problem, which no classical algorithm solves efficiently for a well-chosen curve like Curve448. An eavesdropper sees both 56-byte public keys and the base point, but computing the shared secret from those without a private scalar is believed just as hard, and over the bigger Curve448 it’s harder than over Curve25519.

Why would you choose X448 over X25519?

You choose X448 when you want a larger classical security margin and you’re willing to pay for it in speed and size. RFC 7748 is explicit about the reason it’s in the standard at all: “some designs have relaxed performance requirements and wish to hedge against some amount of analytical advance against elliptic curves and thus curve448 is also provided.” The plain reading is that X448 exists as an insurance policy against the elliptic-curve math being weakened by future cryptanalysis, not because X25519 has any known problem.

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

The tradeoff is concrete on three axes:

1. Security margin. X448 targets roughly 224-bit classical security against 128-bit for X25519, so an attacker with no math breakthrough faces a vastly larger search.
2. Size. X448 public keys are 56 bytes against 32 for X25519, so every handshake carries more bytes on the wire.
3. Speed. Curve448 arithmetic is meaningfully slower than Curve25519 arithmetic, so high-volume systems pay a per-handshake cost.

For most of the internet, X25519’s 128-bit margin is already far beyond any classical threat, so X25519 wins on speed and stays the default. X448 shows up in national-security contexts, long-horizon systems, and designs that deliberately want the extra cushion. The important caveat, spelled out below, is that this whole tradeoff lives entirely in the classical world; neither curve survives a quantum computer, and picking the bigger one doesn’t change that.

Where is X448 used?

X448 shows up wherever a protocol wants a high-margin elliptic-curve key exchange as an option, though it’s chosen far less often than X25519. The two standardized homes:

1. TLS 1.3. X448 is a defined key-exchange group in TLS 1.3, listed in the NamedGroup enum as x448(0x001E) alongside x25519(0x001D). It’s available for negotiation, but it’s optional: RFC 8446 mandates only secp256r1 support (MUST) and recommends X25519 (SHOULD), and does not require X448. So a compliant TLS 1.3 stack may offer X448, and many do, but it’s rarely the group a handshake actually lands on.
2. SSH. RFC 8731 defines the curve448-sha512 key-exchange method, which runs the Diffie-Hellman exchange using the X448 function and hashes with SHA-512, sitting beside the more common curve25519-sha256 method.

Sources: for TLS 1.3, E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, §4.2.7 and §9.1, August 2018, datatracker.ietf.org; for SSH, A. Adamantiadis, S. Josefsson, M. Baushke, “Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448,” RFC 8731, §3, February 2020, datatracker.ietf.org.

The practical read: X448 is the higher-margin alternative that’s standardized and available across TLS 1.3 and SSH, kept in reserve for parties who want the extra hedge, while X25519 carries the overwhelming majority of real key-exchange traffic.

Is X448 quantum-vulnerable?

Yes, and completely. X448 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 X448’s entire security rests on that problem being hard, a capable quantum computer recovers the private scalar from a public key, reconstructs the shared secret, and reads the session. Moving from Curve25519 to the bigger Curve448 raises the classical margin and does nothing against Shor’s algorithm, whose cost grows only polynomially with the curve size.

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.

The quantum cost of breaking X448 is higher than X25519’s, but not by enough to matter. Resource estimates give the logical-qubit count for an n-bit curve as roughly 9n + 2⌈log₂ n⌉ + 10, which comes to about 2,330 logical qubits for a 256-bit curve and about 4,060 for Curve448’s 448-bit field. That’s more qubits than X25519 needs, and still far fewer than factoring an RSA modulus of comparable classical strength, because elliptic curves pack strong security into a small number a quantum computer has less to chew through. So “we chose X448 for the extra margin” is a stronger classical position and not a meaningfully safer quantum one.

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: X448 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 is the one that ends public-key schemes like X448 outright.

Why is X448 a harvest-now-decrypt-later exposure?

Because X448 protects confidentiality and its failure is retroactive. An adversary can record encrypted traffic today, store the two 56-byte public keys and the rest of the handshake, and wait. Once a cryptographically relevant quantum computer exists, they run Shor’s algorithm against the recorded X448 exchange, recover the session secret, and decrypt everything that session carried. This is harvest-now-decrypt-later, and the larger curve provides no defense, because the recording and the future decryption don’t care how wide the classical margin was.

The exposure is a function of how long your data must stay secret, with the arrival of quantum computers setting only the moment recovery becomes possible. There’s a specific trap with X448: it tends to protect exactly the long-lived, high-assurance traffic that most needs decades of confidentiality, which is the traffic HNDL hits hardest. This is Mosca’s inequality made concrete: if the time your data must stay confidential plus the time to migrate your systems is greater than the time until a quantum computer exists, then data you’re transmitting right now over X448 is already at risk, and the very systems that chose X448 for its margin are often the ones with the longest secrecy horizons.

What replaces X448?

The replacement is ML-KEM, the NIST-standardized, module-lattice key-encapsulation mechanism finalized in August 2024. ML-KEM does the same job X448 did, establishing a shared secret over an open channel, but it rests on a lattice problem that no known quantum algorithm solves efficiently. Because X448 targets a high classical security level, its natural counterpart is the top ML-KEM parameter set, ML-KEM-1024, which sits at NIST’s highest security category. Switching to a bigger classical curve never helps; every classical elliptic curve rests on the same discrete-log problem Shor’s algorithm breaks.

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

In practice the transition is happening in hybrid form, running a classical key exchange and ML-KEM together and deriving the session secret from both, so the connection stays safe as long as either one holds. There’s an honest wrinkle worth stating plainly: the leading TLS 1.3 hybrids don’t pair X448 with ML-KEM. The IETF’s ECDHE-MLKEM draft defines three groups, X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, and its highest-security group pairs ML-KEM-1024 with NIST P-384 rather than with X448. So an X448 deployment migrating to a standardized TLS hybrid generally moves to a P-384-based group at the matching security level, or to a pure ML-KEM path, rather than to an “X448 plus ML-KEM” combination.

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.

Hybrid is the pragmatic default for two reasons. It hedges the newer lattice math against any surprise cryptanalysis, because a battle-tested classical component still protects you if ML-KEM is later weakened. And it eases interoperability while the ecosystem catches up. That hedging instinct is the same one that put X448 in the standard in the first place, which is why hybrid cryptography and crypto-agility are the operating model for the migration.

How does X448 compare to X25519 and other curves?

X448 and X25519 are built the same way and differ almost entirely in margin, size, and speed. The table places them against the other common key-exchange curves so the tradeoffs are visible, and it shows the one line that matters: every purely classical row falls to the same quantum attack.

Function	Underlying curve	Curve family	Classical security	Public key size	Primary source
X25519	Curve25519	Montgomery	~128-bit	32 bytes	RFC 7748
X448	Curve448	Montgomery	~224-bit	56 bytes	RFC 7748
ECDH P-256	secp256r1	NIST prime	~128-bit	65 bytes (uncompressed)	SP 800-186
ECDH P-384	secp384r1	NIST prime	~192-bit	96 bytes	SP 800-186
SecP384r1MLKEM1024 (hybrid)	secp384r1 + ML-KEM-1024	NIST prime + lattice	~192-bit classical + post-quantum	~1,700 bytes (client share)	draft-ietf-tls-ecdhe-mlkem

Sources: A. Langley, M. Hamburg, S. Turner, RFC 7748, January 2016, datatracker.ietf.org; NIST, “Recommendations for Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters,” SP 800-186, February 2023, csrc.nist.gov; draft-ietf-tls-ecdhe-mlkem, datatracker.ietf.org.

Two things stand out. X448 buys its extra classical margin over X25519 with 56-byte keys against 32 and slower arithmetic, which is why it’s the reserve option rather than the default. And every classical row, X25519, X448, P-256, P-384 alike, rests on the elliptic-curve discrete logarithm problem, so every one falls to Shor’s algorithm. Only the hybrid row, with its ML-KEM component, adds post-quantum protection, and it does so at a much larger key size, which is the real cost teams plan around.

Common misconceptions

1. “X448 is more quantum-resistant than X25519 because it’s bigger.” It’s not. Both fall to Shor’s algorithm outright; the larger curve only raises the classical margin and the quantum qubit count, never crossing into quantum-safe territory.
2. “X448 is the standard upgrade path from X25519 for post-quantum safety.” The post-quantum path is ML-KEM, usually deployed as a hybrid. Moving from X25519 to X448 is a bigger-classical-curve change, and it provides zero quantum protection.
3. “X448 encrypts my data more strongly.” X448 doesn’t encrypt anything. It only agrees the secret; a symmetric cipher like AES-256 does the encrypting, and its strength is set by that cipher, not by the curve.
4. “If TLS 1.3 defines X448, handshakes must be using it.” X448 is a defined but optional group. RFC 8446 mandates only secp256r1 and recommends X25519, so most TLS 1.3 handshakes negotiate X25519 or a NIST curve, and X448 is rarely the group actually chosen.
5. “X448 and Ed448 are the same thing.” They share the Curve448 design family, but X448 is key agreement (confidentiality) and Ed448 is signatures (authenticity). They play different roles and carry different post-quantum replacements, ML-KEM for X448 and a post-quantum signature scheme for Ed448.
6. “Choosing X448 was wasted effort once quantum arrives.” Its extra margin is real and useful against classical attackers today, which is its whole job. The quantum exposure it shares with every classical curve is a reason to add ML-KEM on top, not a reason X448 failed at what it was built for.

Questions people ask

Is X448 safe to use today? Yes, against every classical attacker, X448 is secure and offers a wider margin than X25519. The risk is entirely future and retroactive: traffic you protect with X448 now can be decrypted later once a quantum computer exists, so long-lived confidential data is the real concern.

What’s the difference between X448 and X25519? Both are the same elliptic-curve Diffie-Hellman function from RFC 7748, built the same way. X448 runs over the larger Curve448 for roughly 224-bit classical security in a 56-byte key, while X25519 runs over Curve25519 for roughly 128-bit security in a 32-byte key and is faster. X25519 is the common default; X448 is the higher-margin reserve option.

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

Does TLS 1.3 use X448? It can. X448 is a defined key-exchange group in TLS 1.3 (codepoint 0x001E), so a compliant stack may offer it, but it’s optional. RFC 8446 requires secp256r1 and recommends X25519, and in practice X448 is rarely the group a handshake lands on.

What replaces X448, and is it ready? ML-KEM (FIPS 203, finalized 2024) is the standardized replacement, and it’s ready. Because X448 targets a high security level, its natural match is ML-KEM-1024. In TLS the standardized high-security hybrid pairs ML-KEM-1024 with NIST P-384 rather than with X448, so an X448 deployment typically migrates to that hybrid or to a pure ML-KEM path.

Do I have to replace X448? Eventually, yes, for anything with a long confidentiality lifetime, and X448 often protects exactly that kind of long-lived traffic. The path is to add ML-KEM through a hybrid or pure post-quantum key exchange, since the bigger classical curve gives no quantum protection on its own.

Why does X448 exist if X25519 is already strong enough for the internet? RFC 7748 provides it for designs that accept slower performance to hedge against future advances in elliptic-curve cryptanalysis. It’s an insurance policy: if the math behind elliptic curves is ever weakened, the wider Curve448 margin gives more room before a break becomes practical.

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 is already exposed, which pushes X448-protected long-lived confidential traffic to the front of the queue.

---

Everything here is the map, given freely. When your team needs its own key-exchange 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.