Fact-checked by Grok 2 weeks ago

Curve448

Curve448 is an defined over the prime field GF(p) where p = 2<sup>448</sup> - 2<sup>224</sup> - 1, offering approximately 224 bits of security for cryptographic applications such as and signatures. It uses the Montgomery curve form with equation v<sup>2</sup> = u<sup>3</sup> + 156326 u<sup>2</sup> + u, enabling efficient ladder-based computations resistant to side-channel attacks, and is birationally equivalent to the Ed448 for flexible implementations. Designed by cryptographer Mike Hamburg in , Curve448—also known as the Goldilocks curve due to its field prime's relation to the for optimal performance across hardware—prioritizes high security against brute-force, quantum, and novel mathematical attacks while maintaining competitive speed on modern processors. The curve's cofactor is 4, with base point u-coordinate 5, and it supports the X448 function for Diffie-Hellman key agreement, producing 56-byte shared secrets from 56-byte inputs in constant time. Specified in RFC 7748 by the (IETF) for use in protocols like (TLS), Curve448 has been endorsed by the Internet Research Task Force's Crypto Forum Research Group (IRTF CFRG) and incorporated into NIST Special Publication 800-186 as a recommended curve for federal systems requiring at least 224-bit security strength. Its adoption extends to standards like RFC 8031 for (IKEv2) and various libraries, balancing robustness with implementation simplicity over larger NIST curves like P-521.

History and Development

Origins and Proposal

Curve448, also known as Ed448-Goldilocks, was proposed by cryptographer Mike Hamburg in 2015 as a high-security within the family of twisted Edwards curves. The design aimed to provide a robust alternative for cryptographic applications requiring enhanced security margins beyond contemporary standards. The primary motivations for Curve448's development included achieving a 224-bit level through a 448-bit prime , to conservative users seeking "overkill" protection against potential advances in . emphasized the curve's use of complete addition formulas inherent to Edwards curves, which inherently resist timing attacks by eliminating conditional branches in operations. Additionally, the curve was optimized for efficient ladder-based implementations on various platforms, including 32-bit, 64-bit, and architectures, without relying on precomputation tables, thereby supporting high-performance and signature schemes. In comparison to earlier curves like , which operates over a 256-bit field for approximately 128-bit security, Curve448 doubles the field size to offer greater longevity and resistance to long-term threats, including breakthroughs in . This larger key size positions Curve448 as a option for protocols demanding extended security horizons. The proposal was detailed in Hamburg's seminal paper, "Ed448-Goldilocks, a new ," published on the IACR ePrint archive. It later played a key role in the IETF's RFC 7748, which standardized for security, including specifications for X448 .

Standardization Process

Curve448's standardization began shortly after its proposal in 2015, with its formal specification in RFC 7748, published by the (IETF) in January 2016. Authored by Adam Langley, Mike Hamburg, and Sean Turner, this RFC defines the elliptic curve parameters for Curve448 in form and outlines its use in elliptic curve Diffie-Hellman (ECDH) , including the X448 function for high-security applications. The document emphasizes Curve448's design for 224-bit security levels, positioning it as a robust alternative to existing curves in cryptographic protocols. Building on this foundation, the National Institute of Standards and Technology (NIST) endorsed Curve448 for federal government use in Special Publication 800-186, initially drafted in October 2019 and finalized in February 2023. This recommendation confirms the curve's parameters in both (Curve448) and twisted Edwards (Ed448) forms, allowing their application in digital signature algorithms like and key agreement schemes. NIST's approval marked a key milestone, integrating Curve448 into approved cryptographic suites for U.S. government systems and influencing broader adoption. By 2020, Curve448 had seen integration into major protocols, notably through its X448 variant in (TLS) version 1.3, as specified in 8446 published in August 2018. This inclusion enables secure key exchange in web communications, with X448 listed among supported groups. The IETF further promoted its use across standards, including 8031 for version 2 (IKEv2) in January 2017 and 8410 for public key infrastructure in August 2018, facilitating adoption in VPNs, certificates, and other internet protocols. These developments solidified Curve448's role in international cryptographic standards by the early 2020s.

Mathematical Properties

Curve Parameters and Equation

Curve448 is defined over the finite prime field \mathbb{F}_p where p = 2^{448} - 2^{224} - 1. This choice of prime enables efficient modular arithmetic, including fast reduction techniques suitable for 64-bit architectures. The curve equation in Montgomery form, optimized for efficient ladder-based scalar multiplication in key exchange, is given by v^2 = u^3 + 156326 \, u^2 + u over \mathbb{F}_p, with the curve parameter A = 156326. The base point has u-coordinate equal to 5 and is ladder-friendly, meaning the v-coordinate need not be computed or stored during the fixed-base employed in the X448 . An equivalent representation for applications is the birationally related twisted Edwards form for Ed448: -x^2 + y^2 = 1 - 39081 \, x^2 y^2 over the same , where the twisting parameter d = -39081. The base point in this form has affine coordinates (x, y) specified precisely in the standard as x \equiv 224580040295924300187604334099896036246789641632564134246125461686950415467406032909029192869357953282578032075146446173674602635247710 \pmod{p} and y \equiv 298819210078481492676017930443930673437544040154080242095928241372331506189835876003536878655418784733982303233503462500531545062832660 \pmod{p}, corresponding to the image of the Montgomery base point under the birational map. The cofactor h = 4 for the Edwards indicates that the full group order is four times a large prime.

Group Structure and Order

The elliptic curve group associated with Curve448 is defined over the prime field \mathbb{F}_p where p = 2^{448} - 2^{224} - 1, and consists of the points satisfying the Montgomery curve equation along with the point at infinity. The order of this group is $4n, where n = 2^{446} - 2^{222} - 1 is a large and the cofactor is 4.$$] This prime order n for the primary subgroup is specifically chosen to have no small prime factors, ensuring a that facilitates efficient while inherently protecting against small subgroup attacks, as adversaries cannot confine computations to low-order subgroups.[$$ As a Montgomery curve, Curve448 supports complete addition and doubling formulas that are particularly well-suited to the for , allowing implementations that run in constant time without conditional branches dependent on secret data.$$] The curve's group structure also contributes to resistance against pairing-based attacks: the trace of the is neither 0 nor 1, and the embedding degree is greater than (n - 1)/100, making the problem in the embedding field computationally infeasible at the intended security level.[$$

Cryptographic Primitives

X448 Key Exchange

X448 is an elliptic curve Diffie-Hellman (ECDH) key exchange primitive defined over Curve448, utilizing a Montgomery ladder-based scalar multiplication to compute shared secrets with approximately 224 bits of security. It enables two parties to agree on a shared secret over an insecure channel by exchanging public keys derived from their private scalars. The primitive is specified in RFC 7748, which standardizes its use in protocols such as TLS for secure key agreement. The X448 function, denoted as X448(k, U), takes two 56-byte (448-bit) inputs: a private scalar k and the u-coordinate U of a public point on the Montgomery form of Curve448. It performs to output the 56-byte u-coordinate of the resulting point k · (U : 1), where the point is represented in Montgomery projective coordinates (u : v). This output serves as the raw in the ECDH exchange, with both parties computing the same value using their private scalar and the peer's public u-coordinate. The computation is implemented via a constant-time Montgomery ladder algorithm, which resists timing and side-channel attacks through 448 iterations of doublings and additions, ensuring no conditional branches depend on secret data. To enhance , the input scalar k undergoes clamping before : the two least significant bits (bits 0 and 1) of the first byte are set to 0, and the most significant bit (bit 447) of the last byte is set to 1. This results in a scalar of the form 2<sup>447</sup> + 4 × m, where m ranges from 0 to 2<sup>445</sup> - 1, ensuring it avoids small- points and lies within a safe interval relative to the . Implementations must also decode the u-coordinate input by reducing it the field prime p = 2<sup>448</sup> - 2<sup>224</sup> - 1 and masking unused high bits, while encoding the output similarly in little-endian byte order. If the output is all zeros, indicating a potential invalid point, the computation aborts to prevent compromise. In practice, the 56-byte from X448 is not used directly but serves as input to a protocol-specific (KDF) to generate symmetric keys, often incorporating additional context like nonces or labels. For instance, in TLS 1.3, it feeds into based on SHA-384 for key expansion, while other protocols may use similar extract-and-expand mechanisms. This design separates the core elliptic curve operation from higher-level security requirements, allowing flexible integration.

Ed448 Digital Signatures

Ed448 is an instantiation of the () on the , providing approximately 224 bits of security through a variant of the scheme with deterministic nonce generation to mitigate risks from poor . It was proposed as part of the Curve448 design to enable high-performance digital signatures resistant to side-channel attacks, leveraging the curve's twisted Edwards form for efficient computations. Key generation for Ed448 begins with a 57-octet (456-bit) private key , typically generated uniformly at random. This is hashed using SHAKE256 to produce a 114-octet value, from which the private scalar a is derived by pruning specific bits: the two least significant bits of the first octet are cleared, all bits of the last octet are cleared, and the most significant bit of the second-to-last octet is set to ensure the scalar lies in the range [0, L-1), where L is the curve order. The corresponding public key A is then computed as the point B on the curve, encoded in 57 octets using the y-coordinate and the least significant bit of the x-coordinate. The signing process uses a deterministic to avoid reuse vulnerabilities. To sign a M, first compute the scalar r as the integer representation of SHAKE256 applied to the of a separation (including the identifier and optional ), a 57-octet derived from the hashed private seed, and the prehashed PH(M), outputting 114 octets and pruning as for the private scalar. The point R is then B, encoded in 57 octets. Next, compute the challenge scalar k as the pruned from SHAKE256 on the concatenated with the encodings of R, A, and PH(M). The signature scalar s is s = (r + k \cdot a) \mod L, also encoded in 57 octets. The full signature is the 114-octet of the encoded R and s. Verification checks the signature without revealing the private key. Decode the signature into points R' and scalar s, and the public key into point A'. Recompute k as in signing using R', A', and PH(M). To prevent small-subgroup attacks, multiply the verification equation by the cofactor 4 and verify that $4B = 4R' + 4A' holds on the curve, where all points are decoded and operations are in the Edwards group. , including Ed448, supports batch verification of multiple signatures for efficiency, aggregating equations via random linear combinations to reduce scalar multiplications, though this is probabilistic and requires careful implementation to avoid inconsistencies. For messages longer than a few kilobytes, Ed448 uses prehashing via the Ed448ph variant, where PH(M) is SHAKE256(M, 64) to produce a fixed 64-octet digest before incorporating into and computations, enabling streaming and preventing length-extension attacks while maintaining . This prehashing is specified with a flag in the domain separation to distinguish it from plain Ed448.

Security Considerations

Security Level and Assumptions

Curve448 provides approximately 224 bits of security against generic classical attacks, such as for solving the elliptic curve discrete logarithm problem (ECDLP). This level is derived from the curve's prime-order subgroup of approximately 446 bits, where the classical attack complexity is on the order of the of the subgroup order, yielding roughly half the bit length in security. The security of Curve448 fundamentally relies on the assumed hardness of the ECDLP in its defined group, where computing the of a point with respect to a base generator is computationally infeasible for classical adversaries without exploiting structural weaknesses. The curve parameters were selected to minimize vulnerabilities, including a large complex multiplication (CM) discriminant exceeding 2<sup>100</sup> to avoid CM-related weaknesses and other structural attacks like anomalous curves or reduction, ensuring no known weak points or intentional backdoors. Against quantum adversaries using generic algorithms, Curve448 offers an estimated 112 bits of post-quantum security when Grover's algorithm accelerates Pollard's rho, reducing the classical O(√n) complexity to O(n<sup>1/4</sup>) for a subgroup order n ≈ 2<sup>446</sup>. This provides stronger resistance than 128-bit classical curves like Curve25519, which drop to approximately 64 bits under the same quantum generic attack model.

Resistance to Attacks

Curve448, encompassing both the Montgomery curve used in X448 key exchange and the twisted Edwards curve in Ed448 signatures, incorporates design features that mitigate various cryptographic attacks. The curve's cofactor of 4 allows for resistance to small subgroup attacks, where an adversary might attempt to confine computations to low-order subgroups. In X448, this is addressed by explicitly checking for an all-zero output after scalar multiplication, which detects confinement to the trivial subgroup and prevents leakage of partial information about the private key. Similarly, Ed448 requires decoding and validation of public points to ensure they lie on the correct curve and have full order, rejecting points in small subgroups and thereby thwarting such attacks. To counter timing attacks, which exploit variations in execution time based on secret data, X448 employs the complete Montgomery ladder algorithm for . This ladder performs a fixed sequence of doublings and additions regardless of the scalar bits, ensuring constant-time operation when implemented with uniform field arithmetic. For Ed448, the signing and verification processes use complete addition formulas on the , avoiding conditional branches and enabling constant-time implementations that resist timing variations. These mechanisms collectively provide robustness against timing-based side-channel disclosures. Curve448's parameters are selected to eliminate vulnerabilities to twist attacks and exceptional procedures, such as those exploiting points on the curve's twist. Both the main and its twist have a cofactor of 4, the minimal value ensuring no small subgroups exist on the twist for the prime modulus congruent to 3 4. This twist security prevents adversaries from injecting invalid points onto a related but insecure twist during or signing, as validated point checks reject such inputs. The absence of exceptional cases in the laws further avoids procedural branches that could leak information. Additional side-channel protections stem from the avoidance of precomputation tables, which could reveal scalar bits through access patterns, and the use of uniform projective coordinates for point representations. In the Montgomery ladder, points are maintained in projective form (X, Z) without affine conversions during computation, randomizing representations via scalar multiples to mask intermediate values and resist differential power analysis. Ed448 similarly leverages projective coordinates in its ladder-based scalar multiplication for signing, ensuring operations remain blind to physical measurements like power consumption. These design choices promote implementations secure against a broad class of side-channel attacks without relying on external countermeasures. Regarding invalid curve attacks, where malformed points are used to force computations off the intended , Curve448's rigorous point validation protocols provide defense. For X448, inputs are processed modulo the field prime but must yield valid outputs, with optional rejection of twist points to block exploitation. Ed448's decoding routine explicitly verifies that points satisfy the curve equation and lie within the valid coordinate range, preventing acceptance of points from invalid or degenerate curves. Analysis confirms no known invalid curve vulnerabilities due to these checks and the curve's completeness. Fault injection attacks, which induce computational errors to extract secrets, are mitigated in Ed448 and X448 through inherent design redundancies and validation. Constant-time operations reduce the efficacy of selective faulting, while post-computation —such as re-encoding points or checking signatures against known values—detects alterations. Studies on Curve448 implementations demonstrate that combining point validation with error-detecting thwarts fault-based key recovery, maintaining the curve's 224-bit level even under physical tampering attempts.

Implementations

Software Libraries

The Bouncy Castle Java cryptography library provides support for both Ed448 digital signatures and X448 starting from version 1.60 released in 2018, offering high-level APIs for key generation, signing, verification, and scalar multiplication in a constant-time manner to mitigate side-channel attacks. incorporated X448 support in version 1.1.1, released in 2018, enabling its integration into TLS 1.3 for secure with 224-bit security. The library's implementation includes EVP_PKEY interfaces for key derivation and is designed for constant-time execution, though Ed448 support was added later in version 3.0.0 for full compatibility. wolfSSL, an embedded SSL/TLS library, added native support for X448 and Ed448 in version 4.4.0 released in May 2020, with APIs for ECDH key exchange and signing optimized for resource-constrained devices and including assembly-accelerated routines for improved performance on and x86 architectures. Botan, a C++ library, has supported X448 key exchange and Ed448 signatures since version 2.3.0 released in October 2017, providing constant-time implementations suitable for TLS and other protocols with emphasis on modularity and cross-platform compatibility. Crypto++, a free C++ class library of cryptographic schemes, added support for Ed448 and X448 in version 8.0 released in June 2018, featuring high-performance, assembly-optimized routines for operations resistant to timing attacks. Implementations of Curve448 primitives are generally 4-5 times slower than equivalent operations on modern processors due to the larger 448-bit field size, but they are optimized to achieve 224-bit security levels suitable for long-term applications; for instance, on an Haswell processor, Ed448 requires approximately 166,000 cycles compared to faster benchmarks for smaller curves like P-256. The reference implementation of Curve448 and Ed448, developed by Mike Hamburg, serves as a secure baseline emphasizing resistance to timing and side-channel attacks through complete addition formulas and exception-free arithmetic, available under a permissive license for integration into other libraries.

Hardware Support

Hardware support for Curve448 operations has emerged primarily through general-purpose processor extensions and custom designs, enabling efficient computations despite the curve's larger 448-bit field size. ARMv8 processors provide partial acceleration for Curve448 via their Cryptographic Extensions, introduced in 2016, which include the PMULL instruction for polynomial multiplication that aids in modular arithmetic essential for scalar multiplications on the curve. These extensions facilitate optimized implementations, with benchmarks showing Curve448 scalar multiplications achieving competitive performance on ARMv8 cores like Cortex-A73, often leveraging SIMD for vectorized field arithmetic. On x86 architectures, processors benefit from vectorized optimizations using AVX2 instructions for high-throughput Curve448 operations, enabling four-way parallel scalar multiplications in libraries targeting modern CPUs. These implementations exploit AVX2's 256-bit vectors to accelerate ladder computations, achieving 10-30% speed improvements over scalar code in some configurations. Although extensions offer potential for further , current high-performance designs primarily utilize AVX2 for Curve448 due to broader availability and sufficient parallelism for 448-bit fields. Custom hardware designs on FPGAs and have demonstrated significant speedups for Curve448, addressing the demands of its high-security parameters. A FPGA implementation on XC7Z7020 utilized 963 logic slices and 30 DSP slices to perform X448 s, closing the performance gap noted in RFC 7748 by providing hardware-optimized Montgomery arithmetic. More recent ASIC and FPGA prototypes achieve 10-30x speedups over software baselines for point multiplications, with one design reporting 31.6x acceleration compared to CPU implementations through dedicated modular multipliers and side-channel protections. These custom accelerators prioritize low-latency and , making them suitable for and high-volume cryptographic systems. The larger 448-bit field of Curve448 poses resource challenges in hardware, requiring more LUTs, DSPs, and memory than 256-bit curves like , which increases area by up to 2-3x in FPGA designs. ePrint reports highlight that while optimizations like unified architectures for /Curve448 mitigate some overhead, the extended operand sizes demand careful pipelining to balance throughput and latency, often resulting in 20-50% higher power consumption compared to smaller curves. Curve448 is integrated into secure elements and hardware security modules (HSMs) to enhance classical security in transition phases toward , offering 224-bit resistance as a bridge solution. Thales HSM firmware version 7.8.4 added support for Curve448 and Ed448, enabling , exchange, and signing within FIPS-certified environments for applications like TLS. Similarly, some secure elements in smart cards and devices incorporate Curve448 for robust key agreement, leveraging its resistance to known classical attacks while preparing infrastructures for PQC schemes.

References

  1. [1]
    RFC 7748 - Elliptic Curves for Security - IETF Datatracker
    This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport ...
  2. [2]
    [PDF] Ed448-Goldilocks, a new elliptic curve - Cryptology ePrint Archive
    However, recently several authors have proposed elliptic curves with field sizes ranging roughly from. 336 bits to 521 bits [1, 4, 9, 21]. Here I detail the ...
  3. [3]
    https://doi.org/10.6028/NIST.SP.800-186
  4. [4]
    RFC 8031 - Curve25519 and Curve448 for the - IETF Datatracker
    This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2).
  5. [5]
    Ed448-Goldilocks, a new elliptic curve - Cryptology ePrint Archive
    Jun 30, 2015 · Here I report on the design of another strong curve, called Ed448-Goldilocks. Implementations of this curve can perform very well for its security level on ...Missing: origins | Show results with:origins
  6. [6]
    RFC 7748 - Elliptic Curves for Security - IETF Datatracker
    [goldilocks] Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", 2015, <http://eprint.iacr.org/2015/625.pdf>. [montgomery] Montgomery, P., "Speeding the ...Missing: origins | Show results with:origins
  7. [7]
    [PDF] NIST.SP.800-186.pdf
    2 for more details. 3.2.2.2. Curve448. The elliptic curve Curve448 is the Montgomery curve MA,B defined over the prime field GF(p) with p = 2448−2224−1 and ...
  8. [8]
    SP 800-186, Recommendations for Discrete Logarithm-based ...
    Feb 3, 2023 · This Recommendation specifies the set of elliptic curves recommended for US Government use. In addition to the previously recommended Weierstrass curves.Missing: Curve448 | Show results with:Curve448
  9. [9]
    RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
    RFC 8446 specifies TLS 1.3, which allows secure client/server communication over the internet, preventing eavesdropping, tampering, and forgery.Missing: Curve448 | Show results with:Curve448
  10. [10]
    RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA)
    RFC 8032 EdDSA: Ed25519 and Ed448 January 2017 This document specifies parameters resulting in the HashEdDSA variants Ed25519ph and Ed448ph and the ...
  11. [11]
    https://datatracker.ietf.org/doc/html/rfc8032#section-5.2.5
  12. [12]
    https://datatracker.ietf.org/doc/html/rfc8032#section-5.2.6
  13. [13]
    https://datatracker.ietf.org/doc/html/rfc8032#section-5.2.7
  14. [14]
    https://datatracker.ietf.org/doc/html/rfc8032#section-5.2
  15. [15]
    https://safecurves.cr.yp.to/disc.html
  16. [16]
    Rebuild of ED25519 keys with Bouncy Castle (Java) - Stack Overflow
    Dec 25, 2018 · The latest (beta) version of Bouncy Castle (bcprov-jdk15on-161b20.jar) supports ED25519 and ED448 EC cryptography for signing purposes.
  17. [17]
    New Edwards Curve Algorithms: X448 and Ed448 - wolfSSL
    Jun 16, 2020 · Curve448 can be used in TLS 1.2 and 1.3 for key exchange and certificates. Do you need higher security or is code size important? Then you must ...
  18. [18]
    [Literature Review] A High-Performance Curve25519 and Curve448 ...
    Apr 6, 2025 · It achieves record performance and energy efficiency, with Curve25519 achieving 10.38 μs and 0.72 μJ, and Curve448 achieving 54.01 μs and 3.73 ...
  19. [19]
    The Armv8.0 architecture extension - Arm Developer
    The Arm Cryptographic Extension provides instructions for the acceleration of encryption and decryption. ... multiplication of 64-bit polynomials, PMULL, PMULL2.Missing: Montgomery Curve448
  20. [20]
    Optimizing Elliptic Curve Cryptography for ARM Processors - NIH
    Feb 5, 2024 · In this article, we study and evaluate optimisations of the popular elliptic curve Curve25519 for ARM processors.
  21. [21]
    [PDF] Efficient 4-way Vectorizations of the Montgomery Ladder
    For Curve448 the outputs of the vector Hadamard transformations cannot be kept unreduced since in this case also, a size increment by at most 2 bits in the ...
  22. [22]
    [PDF] Time-Efficient Finite Field Microarchitecture Design for Curve448 ...
    Feb 10, 2023 · In this paper, we present an efficient design for both protocols based on Mont- gomery curve Curve448 and its birationally equivalent Edwards ...
  23. [23]
    [PDF] Closing the Gap in RFC 7748: Implementing Curve448 in Hardware
    3.2 Curve448 Specification. Curve448, originally introduced as Ed448-Goldilocks by Mike Hamburg [12] and specifically designed as an alternative to existing ...
  24. [24]
    Implementing the RFC 7748 Elliptic Curve448 Cryptosystem in ...
    In this work we demonstrate that Curve448 can indeed be efficiently and securely implemented in hardware. We present a novel architecture for Curve448 that can ...
  25. [25]
    [PDF] Optimized Architectures for Elliptic Curve Cryptography over Curve448
    Abstract. In this paper, we present different implementations of point multiplication over Curve448. Curve448 has recently been recommended.Missing: ISO adoption
  26. [26]
    https://eprint.iacr.org/2020/378.pdf
  27. [27]
    Supported ECC curves - Thales Docs
    The following table lists all supported Elliptic Curve Cryptography (ECC) curves and their Object Identifiers (OID, expressed in dot notation and byte format).