X448: Security and TLS Elliptic Curve Support
Learn what X448 does, how TLS 1.3 uses it, how its security compares with X25519, and what to check for compatibility.
X448 is a Diffie–Hellman key-agreement function based on the Curve448 Montgomery curve. It lets two parties derive a shared secret from their private scalar and the other party’s public value. TLS 1.3 supports X448 as a key-exchange group. RFC 7748 assigns Curve448 an approximate classical security level of 224 bits, compared with about 128 bits for Curve25519. X448 is not a signature algorithm, a cipher suite, or protection against sufficiently capable quantum computers.
That distinction matters operationally: a library may implement X448 while a particular TLS connection still negotiates another group. Both peers, their TLS implementations, and their configuration determine which group is selected. To verify a deployment, inspect the actual negotiated group for the connection you care about.
1. What are Curve448 and X448?
Curve448 is the elliptic curve. X448 is the function that performs scalar multiplication on its Montgomery form for Diffie–Hellman key agreement. The names are related, but they are not interchangeable: Curve448 identifies the curve, while X448 names the operation and its specified encoding and scalar processing.
In a simplified exchange, Alice uses her private scalar with the curve’s base point to produce a public value. Bob does the same. Each then applies their own private scalar to the other party’s public value. The resulting shared value is the same when both calculations use valid, interoperable inputs. A protocol such as TLS uses that shared value as input to its key schedule; it does not use the raw value directly as an application traffic key.
RFC 7748 specifies X448 inputs and outputs as 56-byte strings. The Curve448 base-point u-coordinate is 5. These byte-level rules are part of interoperability: code that uses a different encoding or scalar-processing rule may not agree with a conforming implementation.
2. Is X448 more secure than X25519?
In the RFC’s classical security estimates, Curve448 offers approximately 224-bit security and Curve25519 approximately 128-bit security. That gives Curve448 a larger classical security margin. It does not mean every system using X448 is automatically “more secure”: authentication, implementation quality, key handling, protocol configuration, and the threat model still matter.
| Question | X448 / Curve448 | X25519 / Curve25519 |
|---|---|---|
| Approximate classical security level in RFC 7748 | 224 bits | 128 bits |
| Typical practical trade-off | Larger security margin; can have a higher performance cost depending on implementation and platform | Lower stated security level; often selected where performance and compatibility matter |
| Quantum resistance | No | No |
| TLS 1.3 support | Defined as a supported group | Defined as a supported group |
Do not infer a performance ratio from the security figures. Measure the relevant implementations on your target hardware if the cost matters to your service. Also check the peers you need to interoperate with: standards support does not establish that every product enables or offers either group.
3. Does X448 protect against quantum computers?
No. RFC 7748 explicitly notes that sufficiently large quantum computers would break both Curve25519 and Curve448. X448 is a classical elliptic-curve Diffie–Hellman function, not a post-quantum key exchange. Its larger classical security estimate should not be presented as a quantum-safety claim.
If your design has a post-quantum requirement, evaluate the protocol and key-establishment mechanisms that meet that requirement, using current standards and implementation guidance. X448 alone does not meet it.
4. How TLS 1.3 uses X448
TLS 1.3 identifies X448 as a supported named group. During the handshake, peers can exchange X448 public values in key shares and derive a shared secret. The TLS key schedule then derives traffic keys from handshake inputs.
Keep three handshake responsibilities separate:
- Key agreement: X448 can contribute the shared secret.
- Authentication: certificates and the handshake signature authenticate the server (and, when configured, the client). X448 does not identify the peer.
- Record protection: the negotiated symmetric cipher suite protects TLS application data. X448 is not that cipher suite.
Consequently, seeing X448 support in a crypto library does not prove a TLS connection will use it. TLS group selection depends on both endpoints and their configuration, as well as the groups available to the particular connection. Test the negotiated group in the environment that matters instead of assuming that a provider’s algorithm list predicts every handshake.
5. Check X448 support with OpenSSL
OpenSSL 3.1 documentation lists X448 key types and says X25519 and X448 key types are implemented in its default and FIPS providers. That is evidence for that documented release, not a guarantee about every OpenSSL build, operating system, TLS application, or remote server. First check which version you are running:
openssl versionThen ask the local OpenSSL command-line tool to list supported public-key algorithms and filter for X448:
openssl list -public-key-algorithms | grep -i x448This is a local capability check, not a live TLS negotiation test. It also assumes a Unix-like shell with grep. On another platform, inspect the command output manually or use that platform’s search utility. Consult the documentation for your installed version and provider configuration; the result can differ from the OpenSSL 3.1 documentation cited here.
Primary references: RFC 7748, Elliptic Curves for Security; RFC 8446, TLS 1.3; and OpenSSL 3.1 X25519 and X448 documentation.
6. X448 encoding, validation, and protocol integration
X448 consumes and returns 56-byte strings under the RFC’s specified rules. Use a maintained cryptographic library’s X448 API rather than inventing your own scalar multiplication or byte encoding. Do not truncate, pad, or reinterpret values to fit another API’s format unless that API’s specification explicitly calls for it.
RFC 7748 discusses checking whether a shared result is all zero. An implementation may abort when it gets that value, without leaking additional information about the shared value. The RFC also warns protocol designers not to assume that these Diffie–Hellman functions provide contributory behavior by themselves. In practical terms, do not treat a successful function call as proof that the other party is authenticated or that every peer input contributes as your protocol expects.
Follow the protocol’s validation and error-handling requirements, and use the high-level TLS or key-agreement interface provided by your cryptographic library. X448 is a primitive; the application still needs sound authentication, key derivation, and protocol composition.
7. Performance, reliability, and deployment choices
Performance
Curve448’s larger classical security margin comes with a performance trade-off. The actual impact depends on the library, provider, CPU, and workload. Benchmark the complete operation in the deployment environment if handshake latency or CPU usage is important; the dossier’s security figures do not imply a fixed slowdown.
Reliability and interoperability
Check both ends. Confirm the local TLS library and build support the group, confirm local configuration permits it, and then inspect a real handshake to see what was negotiated. OpenSSL’s documented support is useful evidence about that release, but does not establish universal deployment. For an interoperability issue, test against the actual peer and inspect its TLS implementation and policy.
Choosing X448 or X25519
Base the choice on the classical security level you require, measured performance on your target platform, and support and negotiation behavior of your peers. Avoid reducing the decision to “X448 is more secure” without including those costs. Where a protocol offers multiple groups, understand the configured preference and fallback behavior in the specific TLS stack.
8. Troubleshooting X448 support
| Symptom | Likely cause | What to check |
|---|---|---|
| X448 is missing from a local algorithm listing | The installed version, build, provider, or configuration does not expose it | Check the exact version and provider documentation; compare with the documented OpenSSL release rather than assuming all builds match. |
| A TLS connection succeeds but does not use X448 | The peer pair or their settings selected another supported group | Inspect the negotiated group and the group configuration on both endpoints. Local library support alone does not force selection. |
| Handshake fails after restricting groups to X448 | The other peer may not offer X448, or a policy/build may exclude it | Review both peers’ capabilities and configuration. Avoid an X448-only restriction until the required peer set is verified. |
| Two implementations derive different values | Input encoding, scalar processing, or API expectations may not match | Use RFC 7748-compliant library APIs and 56-byte X448 inputs/outputs. Do not adapt encodings by guesswork. |
| An all-zero shared result is returned | The input and protocol context need to be handled under the RFC and higher-level protocol rules | Apply the implementation’s specified all-zero handling and abort policy. Do not treat the value as authenticated key material. |
| Assumption that X448 authenticates a server | Key agreement was confused with identity authentication | Verify the TLS certificate and handshake authentication separately; X448 only provides key agreement. |
| A claim that X448 is quantum-safe | Classical security strength was confused with post-quantum security | Correct the design assumptions: sufficiently capable quantum computers break both X448 and X25519. |
9. Or skip the browser setup
If you need screenshots of pages that explain or document your TLS deployment, ScreenshotNeo can capture them through one API call. It is a website screenshot API and MCP server from ScreenshotNeo. Its cookie-banner, popup, and chat-widget cleanup happens before capture; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 shots a month with no card, and paid plans start at $5 for 3,000. See the API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpSign up for 1,000 free screenshots a month, no card required.
10. FAQ
Is X448 an encryption algorithm?
No. It is a key-agreement function. TLS uses derived secrets with its key schedule and negotiated symmetric cipher to protect application data.
Does using OpenSSL mean my application negotiates X448?
No. OpenSSL capability is only one part of the path. The application configuration and remote peer also affect group negotiation.
Does X448 replace certificates?
No. Key agreement and authentication are distinct. TLS certificates and handshake authentication establish identity; X448 can establish shared key material.
Is X448 interchangeable with X25519?
They are related Diffie–Hellman functions with different curves and encodings. Both are standardized for TLS 1.3, but protocol configuration and peer support determine whether either is usable on a given connection.
